Disclosure of "vulnerability" on some gateways

Disclosure of "vulnerability" on some gateways

Postby ripplerm » Tue Mar 14, 2017 8:24 am

Full Content of this post will be updated after:
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/
ripplerm
 
Posts: 260
Joined: Tue Jan 21, 2014 4:10 am

Re: Disclosure of "vulnerability" on some gateways

Postby JoelKatz » Wed Mar 15, 2017 12:40 pm

Thanks for finding and reporting this. I'm saddened and puzzled that you didn't trust us enough to report this to us in advance of disclosing it to the public.
User avatar
JoelKatz
Ripple
Ripple
 
Posts: 1845
Joined: Sun Dec 23, 2012 3:45 pm
Location: Oakland, CA

Re: Disclosure of "vulnerability" on some gateways

Postby ripplerm » Thu Mar 16, 2017 6:56 am

JoelKatz wrote:Thanks for finding and reporting this. I'm saddened and puzzled that you didn't trust us enough to report this to us in advance of disclosing it to the public.

First, for this issue there's nothing to do at protocol level, hence there's no need for RL to step in.
Secondly, even if i trusted RL, it shouldn't get involved in this too, cause in will incur Conflict of Interest.

For this issue, it's not just about trusting or not.... but we should always strike our best to avoid Conflict of Interest.

That's it.

==========================================

But since you mentioned about trust.

We trusted RL, that our fund would be safe and protected when NO_RIpple=true was set on all trustlines.
RL disappointed us, yet there's no sign of willingness to take the responsibility, not even heard an apology.

No single employee dare to answer the simple question here:
https://www.xrpchat.com/topic/3232-shou ... ling-bugs/

why should RL deserved trust/respect from us?
ripplerm
 
Posts: 260
Joined: Tue Jan 21, 2014 4:10 am

Re: Disclosure of "vulnerability" on some gateways

Postby JoelKatz » Fri Mar 17, 2017 10:29 am

ripplerm wrote:First, for this issue there's nothing to do at protocol level, hence there's no need for RL to step in.

It's not about need. It's about sanity.

Secondly, even if i trusted RL, it shouldn't get involved in this too, cause in will incur Conflict of Interest.

Whose interests conflict with whose? What in the world are you talking about?

For this issue, it's not just about trusting or not.... but we should always strike our best to avoid Conflict of Interest.

Right, so what conflict of interest are you talking about? Ripple wants all gateways to succeed.

But since you mentioned about trust.

We trusted RL, that our fund would be safe and protected when NO_RIpple=true was set on all trustlines.
RL disappointed us, yet there's no sign of willingness to take the responsibility, not even heard an apology.

This was our mistake, no doubt about it. We should have caught it in 2015 when we worked on a similar bug.

No single employee dare to answer the simple question here:
https://www.xrpchat.com/topic/3232-shou ... ling-bugs/

There's really not much for us to say. We're very clear that others must evaluate RCL to determine if it meets their needs and that all we promise is that we'll do our best. All software of any complexity will have bugs. We haven't received any requests for compensation related to this bug yet, but we do evaluate those kinds of things on a case-by-case basis.

why should RL deserved trust/respect from us?

You seem like the kind of person who is impossible to satisfy. Despite our active engagement all around this issue, the fact that we haven't apologized is what you mention. We haven't rejected a single request for compensation, but our failure to compensate people is what you mention. You think we have some kind of conflict of interest but you haven't mention anyone whose interest differ from ours.

There must be a lot of information, possibly incorrect, possibly correct, that you have that I don't. That, or we see the world very differently for some reason. You're obviously a very smart guy whose very interested in this technology. It's unfortunate that we can't seem to see more eye to eye. If you're even the San Francisco area, let me know, we'll have a beer or a coffee and maybe build some trust person to person.
User avatar
JoelKatz
Ripple
Ripple
 
Posts: 1845
Joined: Sun Dec 23, 2012 3:45 pm
Location: Oakland, CA


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 1 guest
cron