15-03-2017, 12:00 noon, London Time.
Intro:
quality on trustline:
on RCL, every users has the right to set a "Quality_In" property on his/her outgoing trustline, so that the issuance he received over a line can be valued higher/lower than its face value.
e.g. if Alice trust Bob for some USD, and has set the "quality_in" at 50% level, then for Alice to received an amount she valued at USD 1.00, Bob has to sent out USD 2.00 along the trustline.
Hot-Cold wallet structure & Transfer_Fee:
Most gateways on RCL today are operating in a "vanilla" hot-cold-wallet structure. With this setting, if the issuing address charge a transfer fee, then every out-going payment from its hotwallets are subjected to the charge too, hence each txn has to be set with a SendMax > Amount to compensate for the fee.
the correct way of doing this, as described in https://ripple.com/build/gateway-guide/ ... -customers, is to set SendMax exactly same as Amount * (1 + transfer rate).
The Problem:
Some gateways on RCL now, are sending out their IOU from hotwallets with a SendMax higher than what's neccessary. hence, if a destination account had set a quality_in < 100% on its receiving trustline, then it could received an amount slightly higher than what's (the gateway) expected.
Although the profit might be very small (less than 1%) for a single transaction, it's easy to repeat the trick many times and stay un-noticed for a long period of time.
A Quick Fix:
for all the outgoing payment from hotwallet, make sure that the SendMax is always exactly = Amount * (1 + transfer rate).
period.
For more complete fix, the quality_in of receiving trustline should be taken into calculation when constructing a txn, else payments to those trustlines(quality != 100%) will fail and need to be handled manually.
An example of "Attack":
Background: the issuing account of GatehubFifth has set a transfer_fee = 0.3%, But each transaction leaving its Hotwallet has its SendMax set 0.5% higher than Amount. A user feels that ETH issued by GatehubFifth should worth less than its face value (for whatever reason), so he has set quality_in = 99.81% on the trustline. As a result, for every 1ETH he deposited from Ethereum to GatehubFifth, he received ~1.002ETH on RCL from GatehubFifth's hotwallet. he could pocket 0.2% profit right away if he withdraw the fund immediately.
Some demo-examples from GatehubFifth Hotwallet:
txn1: CBFBC79B4000BED937B4F872E4A4C045E59BAB4900F55ADDE736DC1970859F18
txn2: 5AA6E91B7B7CA5B46A0ADE2DE04FD362980A16921AE7E7C1DE063DEA7EBA1CC2
(balance changed on receiving account is ~0.2% higher than Amount)
Disclosure:
Above txns were performed with prior notice to Gatehub operator. He was aware and agreed that a demo-hack could be done upon his gateway. But to be fair to everybody else, he had not been given any information about the detail of how this trick could be performed.
My Personal Comment: (feel free to skip this part)
Exploitability:
There won't be any financial profit when using the trick on any IOUs that's charging a (deposit + withdrawal) fee higher than the exploitable %, which would be the case for most IOUs issued by most (major) gateways currently operating on RCL. (That's the reason I said with high certainty that the "vulnerability" can only bring very limited harm).
Anyway, there's still an incentive for users to apply the trick, to reduce the fees charged on them (also means reducing profit for gateways).
The profit/incentive to use this trick will be very much higher on IOUs that's charge zero-ish fee (which is true for many cryptos); If the deposit-withdraw process were fully automated and a cycle can be completed within minutes (e.g. Ripple - Stellar), and if the issuer doesn't have a good mechanism to detect suspecious balance change, its hotwallet will risk being drained to empty.
Special case at Ripplefox:
Ripplefox had been charging 0% transfer fee on its IOUs, so there's really no need to include a SendMax field when sending payment from hotwallet. Yet, some of its deposit txns (e.g. BTS) were leaving its hotwallet with a 1% slipage. So there should be a 1% exploitable profit for users. However, there's a special "two step transfer" logic in RippleFox's deposit handling process (Ripple fox use this for ensuring txn Idempotency), that's indirectly save it from the exploitation.
Debatable Legitimacy:
IMO, we have some difficulty in defining the nature of this exploitation.
Some might say it's a kind of attack, but it's not wrong to say it's legit.
Though poorly documented, trustline's qualities are among the advance-features of RCL that's exist since its very first days.Thus the feature should have been well understood by all competant gateway-operators. (The "Quality_in" and "Quality_out" of trustlines are accessible via Gatehub Wallet)
Since the gateway operator has set a txn's SendMax on their own free will (though higher than neccesary), it's an explicit instruction that he is ready/willing to pay that amount. He might have done this intentionally, for any reasons, e.g.:
- the operator doesn't mind lossing those 0.xx%,
- he likes to give his customers some reward/bonus.
- it might be a well-planned marketing strategy,
- he probably just want to be generous,
- etc.
Effect on ordinary users:
The "trick" can be used on any transaction, including payments between normal users. Some old wallet-clients had always set a 1% slipage when making payment, So, by adjusting the quality_in accordingly, a receiver can receive a slightly higher amount from sender.
But I think most people will have little concern, if any, about that 0.x% "loss".
Again, since the sender explicitly agree on the slipage, I'm not sure whether we could call this a steal.
cross-posting:
https://www.xrpchat.com/topic/3243-disc ... -gateways/
