Re: Review: http://www.ietf.org/id/draft-mbelshe-httpbis-spdy-00.txt

Putting on a black hat for today ...

On 3/03/2012 10:45 a.m., Mike Belshe wrote:
>
>
> On Fri, Mar 2, 2012 at 6:11 AM, Willy Tarreau <w@1wt.eu 
> <mailto:w@1wt.eu>> wrote:
>
>     Hi Mike,
>
>     [ sorry to bother you while you're traveling ]
>
>     On Fri, Mar 02, 2012 at 04:01:43AM -0800, Mike Belshe wrote:
>
<snip>
>
>
>     This is the point where I disagree, because as long as the
>     requests are
>     valid you uhave no reason to drop anything. For instance, if I
>     send the
>     following 72 bytes :
>
>      78 f9 e3 c6 a7 c2 43 24  d3 aa 01 f3 02 5a 26 80
>      95 4d 17 e9 90 be 41 d9  08 96 bd f8 36 d1 c1 c2
>      51 2b 46 ad 18 b5 62 d4  8a 51 2b 46 ad 18 b5 62
>      d4 8a 51 2b 46 ad 18 b5  62 d4 8a 51 2b 46 ad 20
>      a7 ff 0a 00 4f b2 66 6f
>
>     they decompress to a (hopefully) valid 4032 bytes request which barely
>     looks like the SPDY encoding of :
>
>      get
>     /html,image/png,image/jpg,image/gif,application/xml,application/xhtml+xml,text/plain,text/javascript,publicprivatemax-age
>     HTTP/1.1
>      host:
>     origin100101201202205206300302303304305306307402405406407408409410411412413414415416417502504505203
>      cookie: origin... repeated 38 times
>
>     Adding the 18 bytes header to this, this means that I can produce
>     4032 bytes
>     of request to parse with only 90 bytes of input stream (ratio of
>     45x). The
>     ratio even increases a lot if larger requests are accepted by the
>     recipient
>     (eg: 94x for common 8kB buffer).
>
>
> Sure, but this would have easily tripped the fraud checks I enumerated.

You missed the point. The above is a valid request. It SHOULD NOT 
trigger any of the fraud checks.

Little nasty black-hat will come complaining to you about some report 
auto-generator not working through your proxy. Cookies are from partner 
sites, and the URL is a valid input parameter to the report generator. 
GET is more appropriate here then POST to get caching, it is a static 
response for 23 hrs and 59 min of each day.

>
>     Since these requests are valid, the connection has no reason for being
>     dropped. The attacker will simply emit a stream of many such requests
>     and will receive a stream of "404 not found" for instance. At one
>     megabit
>     of upstream bandwidth, I can then make and intermediary gateway
>     have to :
>      - decompress 1 Mbps (cheap)
>      - parse and process 94 Mbps of headers (expensive)
>      - recompress 94 Mbps of headers (expensive)
>
>     And in fact it's even worse than that because only the first
>     request takes
>     spaces, the next ones benefit from the updated dictionary and are much
>     smaller. I've checked I can compress 10 8kB requests into 200
>     bytes, meaning
>     that each next request takes 13 bytes (+ 18 of header = 31 bytes).
>     So after
>     the first request, the http-to-wire ratio is more like 264 for 8kB
>     requests
>     (8190/31) or 122 for 4kB request (4032/33).
>
>
> Not exactly - now you're getting into concurrent stream DoS attacks. 
>  Here you'll run into a new limit, which is the max concurrent streams 
> limit.  I don't believe it is contentious that servers will want to 
> have a cap on the number of streams they'll simultaneously process, 
> and the protocol even allows for communicating this limit to the client.

How does SPDY deal with the "drop" action then;
   entire TCP connection and every channel inside it,
   or just the one channel/session the attack was sighted on?

If the former, you get a single request from client A terminating a 
connection shared with N other clients.

   Black-hat: free amplification. woohoo!

If the latter,  the compression dictionary has just been seeded. A 
second-stage attack request can make use of that, concurrency is not 
required.

   Black-hat: so I just open two SPDY connections. done!


corollary:  if you try protecting seeding with a per-channel/session 
dictionary you end up consuming RAM resouces with N dictionaries per TCP 
connection.

   Black-hat: more baseline RAM loading. Lower threshold to push it over!


>
>     At 264, you just need 4 ADSL lines to make a SPDY-to-HTTP gateway
>     fill its
>     gigabit link to the servers.
>
>     Another concern with this high compression ratio coupled with
>     pipelining is
>     that it becomes easier to send a huge number of requests to a
>     server in just
>     a few bytes. With the example above, we're saying that both the
>     gateway and
>     the server may have to process 10000 8kB requests per second from
>     a single
>     ADSL line. As of today, doing this for an attacker still requires
>     at least
>     260 Mbps of upstream bandwidth.
>
>
> Concurrent stream limits.

Black-hat: Multiple IPs. Check!

Black-hat: plus serial streams from other IPs to add more setup/teardown 
overheads. check!


(White-hat me wonders if this thread is leading towards a current 0-day 
for SPDY servers?)

>
>     > All in all, to get our SPDY server to process 1KB of amplified
>     data on your
>     > 100B sent, you had to do a full 3 way handshake, plus a full SSL
>     handshake
>     > (with PK op on your *client*, and we got to pick which type of
>     PK op -
>     > 8192bit RSA anyone?).  Mice nuts!
>
>     That's assuming that requests are identified as undesirable and
>     also that
>     the site only runs over SSL. Attackers select the easiest way to
>     take a
>     site down, not the hardest one :-)
>
>
>     > You'd be better off attacking with
>     > legitimate requests - most servers will use far more resources
>     trying to
>     > process legit requests than deflating that extraneous 1KB of data.
>
>     Yes... that was precisely my point, sorry if that wasn't clear from my
>     examples. An attack is always an optimization of the harm vs cost
>     ratio.
>     Sometimes it can take long to establish, but once the weak points are
>     found, they're smartly exploited.
>
>
> As Roy suggests, I think the concern is worthy, and you've made a good 
> note of it.  We're probably going to disagree on the magnitude of this 
> and will have to sort that part out later.

I hope that happens still while it is in Draft and deep issues can be 
changed.

AYJ

Received on Saturday, 3 March 2012 02:49:55 UTC