Jump to content
ripplerm

Disclosure of "vulnerability" on some gateways

Recommended Posts

This is very interesting and thorough report. The quality feature on a trust line is really powerful, but also somewhat esoteric. This is a good proof of that.

As you said, there's nothing wrong with the core protocol, and only gateways that use a SendMax greater than the amount they deliver are affected.

I still believe that the reporting should have been handled differently: by contacting Ripple and/or gateways in private, giving them time to fix this, instead of just "unleashing" this and presuming to know how fast they can react and deploy changes. But it's out now and I'm sure that gateways will move fast to ensure that this is addressed.

I urge you and everyone to consider using Ripple's bug bounty program for future submissions of bugs involving the Ripple protocol, and similar programs that gateways may have, to responsibly disclose issues that you discover.

Share this post


Link to post
Share on other sites

Three thoughts:

1) You really do have to carefully set the "SendMax" field. You should always assume possible hostile ledger changes between when you form a transaction and when the transaction executes. So even checking the trust line is not sufficient to protect you.

2) This shows how any "that would be cool" feature can become a huge problem in the future. When considering a feature on a public ledger, you have to give some weight to the complexity created by the fact that everyone who uses the ledger may have to interact with the feature.

3) This does show two quirks of how issuers are reported and used by RCL. The issuer in the Amount field of a payment just specifies the trust line to deliver funds on, it does not lock the amount. And the issuer in the delivered_amount just reports the trust line the funds were delivered on, it does not lock the amount. So if you see, for example, "10/ETH/Gatehub" as the delivered_amount, that doesn't mean 10 ETH/Gatehub was delivered. It means ETH was delivered on the Gatehub trust line that the recipient agreed to value at 10 ETH. Same for an Amount of 10 ETH/Gatehub. That doesn't mean to deliver 10 ETH/Gatehub, but to deliver ETH on the recipient's Gatehub trust line that the recipient has agreed to value at 10 ETH.

Share this post


Link to post
Share on other sites

Extra thought:

I had always think that a Hot-Cold-wallet in "Bank Paradigm" (as describe here: https://wiki.ripple.com/index.php?title=Hot_%26_cold_wallet_setup&oldid=9015#Bank_Wallet_Construction) should be a better choice for gateway operation.

there are at least two benefits:

1. you don't need to take care about transfer fee when sending fund from hotwallet to customer.

2. balance on that single trustline between hot-cold wallet will show u the total issued amount of an IOU. If you are checking you total issuance frequently, this setting might help to reduce some load on server.

Share this post


Link to post
Share on other sites

Thank you for a thorough report @ripplerm!

A patch has been applied to our processing services and this exploit will not be possible anymore.

No user has been affected by this issue.

In the future we would prefer that vulnerabilities are reported to GateHub before public disclosure. We have an ongoing whitehat program available here: https://gatehub.net/whitehat

 

Share this post


Link to post
Share on other sites

Thank you @ripplerm

Our BTC gateway was not affected by that issue. We may try to fine tune it even more. In our experience, setting the exact transfer fee as a slippage to calculate sendmax made us prone to tecpathdry error, so we have set it a liiiittle higher than our transfer fee.

Our BRL deposits are handled manually so we can be faster than banks' automated communications. Indirectly, this practice allows us to deal with strange behaviors in a real time manner.

BTW, our webpage is translated to english and we are accepting international applications for Rippex accounts - a proper announcement will be made but if you don't want to wait....

Share this post


Link to post
Share on other sites
Guest Vinnie

Once again: XRP unaffected by this.

Share this post


Link to post
Share on other sites

Why set SendMax to a value that you're not intending to fully send anyways?!

 

On 3/12/2017 at 6:35 PM, enej said:

All GateHub's issuing addresses has been setup according to best practices and security guidelines written by Ripple.

 

@enej - where in the best practices and security guidelines is a SendMax value set above Amount + Fee recommended? To me it seems more like a copy-paste error from the documentation, which uses a 0.5% fee.

Share this post


Link to post
Share on other sites
5 hours ago, Sukrim said:

Why set SendMax to a value that you're not intending to fully send anyways?!

We have always recommended that you not set the SendMax any higher than the most you want the transaction to cost you. Setting it to absolutely, precisely the expected amount can be a bit of a problem if rounding bites you.

Say your transfer fee multiplier is 1.002. That has four digits. So you have 11 left over to stay within ripple's 15 digit precision and avoid a rounding problem. A dollar gateway will have no issue, but a BTC gateway might see, say, 1412.40537215 BTC, which has 12 digits. Multiplying that by 1.002 will give a number with more digits than ripple can represent for the SendMax. You will want to round that up. You could use 1.0020000001 as the multiplier, but that will give all your numbers lots of digits even where that's not needed.

If you want to be fancy, you could use the following algorithm:

1) If the withdrawal amount has 8 digits or fewer, multiply by 1.002

2) Otherwise, multiply by 1.0020000001 and truncate the result to 15 digits.

Or:

1) Multiply the withdrawal amount by 1.002

2) If the result has fewer than 16 digits, use it

3) Otherwise, round the result up to the nearest 15 digit number

 

Share this post


Link to post
Share on other sites
On 15/03/2017 at 0:54 PM, enej said:

Thank you for a thorough report @ripplerm!

A patch has been applied to our processing services and this exploit will not be possible anymore.

No user has been affected by this issue.

In the future we would prefer that vulnerabilities are reported to GateHub before public disclosure. We have an ongoing whitehat program available here: https://gatehub.net/whitehat

 

Well, it seems I was one of the lucky guys who was affected... happy, if you look at my private inmail, where I described things in more detail.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...