
A very valuable vulnerability - cperciva
http://www.daemonology.net/blog/2016-10-28-A-very-valuable-vulnerability.html
======
ChuckMcM
From the article ...

 _" Isaac Asimov's remark that in science 'Eureka!' is less exciting than
'That's funny...' applies equally to security vulnerabilities."_

That should be on a poster in every security engineer's view. I cannot count
the number of times a really big problem was uncovered by a very small, yet
unexpected, anomaly. It was also the core of Cliff Stoll's quest to find the
hacker who hit UC Berkeley. Bottom line, never let that sort of observation go
until you fully understand why it happened.

~~~
HillRat
Many years ago, that's how I found a vendor-managed (but not vendor-patched)
system had been compromised; I went from "why the hell is that multi-pipe
command segfaulting?"to "why the hell aren't the system binaries stripped?" to
" _how_ long has this thing been compromised?"

~~~
shshhdhs
What is binary stripping?

~~~
Buge
Compiled programs sometimes contain the names of the functions.

To reduce binary size and/or discourage reverse engineering, the names can be
stripped out.

~~~
cperciva
Not just names of functions; also names of variables and potentially a great
many other things.

Stripping binaries generally refers to removing debugging information of all
sorts.

~~~
HillRat
Exactly. In this case -- working from antique memory here -- Solaris binaries
were normally stripped, while the compromised versions placed by the hacker
weren't, which was an immediate red flag. The system was compromised as part
of a very large-scale, probably North Korean, attack that exploited an
OpenWindows buffer overflow bug that was fixed many patch-revs ago by the time
I saw the system (and shouldn't have been exploitable over the Internet
anyway, but the firewall was also not properly set up at the time of
compromise). Drive-by hacking, in other words. Luckily their compromised
binaries -- specifically a 'ps' that filtered out the hackers' background
attack processes -- weren't particularly robust to arbitrary input.

------
nowarninglabel
Great job of laying this out. It highlights how important the edge cases are.
People wonder, why do we spend so much time on our financial code even though
the base case is simple. It's that the amount of edge cases is insane.

~~~
cperciva
It's not just that there are a lot of edge cases; it's also that a single edge
case could allow someone to extract _an effectively unlimited amount of money_
from you.

~~~
sovietmudkipz
That's exactly what hit etherium in its early days. A bad actor programmed a
contract that vaccuumed all VC money attached to the system. There was/is(?) a
great debate on wether to invalidate the transaction (defeating the stated
goal of "no central authority" in the system) or letting it ride, and allowing
the bad actor his spoils.

It happens; gotta look out for those edge cases.

~~~
adrianN
I still don't think that it was a bad actor. The Etherium guys explicitely
said that the code _is_ the contract. If the code allows you to get all the
money, then it's not malicious to do so.

It's like the tax code. Leaving your profits in a foreign country to avoid
paying higher taxes at home is not malicious, it's just the best way for you
to comply with the law.

------
tedunangst
I wonder if there's still a small arbitrage window here. The ten minute lockin
is essentially a short lived option. If you lockin a rate at $101 and the
price drops to $100 over the next nine minutes, buy bitcoin and complete the
transfer, then request refund. If the price goes up, let the option expire.

~~~
smallnamespace
The peak daily volatility of bitcoin is in the ~10% a day range [1], varying a
lot month to month. The implied 10-minute volatility is 10% / sqrt(24 * 6) ~=
0.83%, assuming independence of successive 10-minute windows. This is likely
an underestimate, because most financial time series display mean reversion.

The Black-Scholes price of an at-the-money option is very approximately
1/sqrt(2pi) * vol to maturity, so the option is worth somewhere around 0.3% of
the notional price on a high-volatility Bitcoin day, somewhat less than the
0.8% transaction charge.

However, the charge is only paid if you go through with the transaction, so
really this is an option that's 0.8% out of the money. With that assumption,
the value of the option is just 0.08%.

[1] [https://btcvol.info/](https://btcvol.info/)

~~~
tedunangst
It's not much, but if somebody puts a button on the internet that gives me 8
cents every time I push it, I might try pushing it a few million times. :)

~~~
smallnamespace
Yeah, the real barrier stopping you is being able to trade Bitcoins against
USD on demand, which I suspect costs a _lot_ more than 0.08%.

~~~
stouset
Plus you have to get refunded over and over and over.

------
lol768
> they merely need to find a merchant which uses Stripe for bitcoin payments
> [...] > or even better, set up to automatically refund bitcoin overpayments

Any idea what proportion of merchants using Stripe's bitcoin handling actually
do this automatic refunding?

It's a very interesting vulnerability and I enjoyed reading the write-up and
thought process, but I'm not sure how practical it is if it requires
interaction from the merchant to perform the refund. I think an overpayment
and refund request weeks after the initial payment (when coincidentally the
BTC value has reduced) would definitely ring some alarm bells - hopefully with
both the merchant and the team at Stripe.

I guess you could spread out your overpayments amongst different merchants and
try and limit the time between the initial purchase and the refund requests
but the entire thing seems a bit convoluted to pull off.

In any case, kudos to the author for the responsible disclosure and for Stripe
for handling this professionally.

~~~
elnado
I don't know the proportion, but coincidentally enough, I work at a startup
that uses Stripe and we used to support bitcoin transactions (and thus
refunds). I just asked a friend who's been here longer why we're not
supporting bitcoins anymore and his response was "exchange rates were a huge
pain" haha so yeah it is indeed convoluted to do refunds with bitcoins, but if
we are to attempt to use them as regular currency for goods and services, we
can't not support refunds. so we dropped bitcoin support altogether.

~~~
cperciva
Was that bitcoin support manual, or through stripe? I would never want to deal
with bitcoin payments manually due to the exchange rate issue; but taking them
through stripe works wonderfully.

~~~
elnado
Hmm digging through our old code looks like we never tried to use Stripe, for
reasons unknown to me (maybe their support/requirements were different back
then, maybe it didn't work for our product, idk). But yeah, especially after
reading this article, handling bitcoin payments and dealing with the exchange
rate sounds unfavorable lol :) glad we're not doing that.

~~~
cperciva
That's my point - with stripe, you don't have to deal with the exchange rate.
You say "I want $X" and magic happens. Stripe takes care of the messy details
of fluctuating exchange rates.

~~~
elnado
So that's not entirely true depending on how you use the product. We were
attempting to use Stripe for a contract-like setup, e.g. person A pays person
B, but person B doesn't get paid until some event occurs, and we hold on to
the funds until that happens since that expiration of that event isn't
guaranteed to be under 10 min.

