[robocat]

This is incredible and it looks like it could affect massive numbers of sites - unfortunately the article doesn't summarise the problem very well.

The vector is subtle differences in HTTP header parsing between your front end (reverse proxy, load balancer etc) and your back end (web server).

"New Relic deployed a hotfix and diagnosed the root cause as a weakness in an F5 gateway. As far as I'm aware there's no patch available, meaning this is still a zeroday at the time of writing.".

Edit: other major companies he revealed were affected were: PayPal, Trello, Redhat.

[sciurus]

When a security engineer I know learned about this, they described it as "the next heartbleed" and it's hard not to concur. The scope and impact of this class of attack is much bigger than anyone realized prior to this research.

[robocat]

Heartbleed again - yep. Maybe there's not much discussion yet because it doesn't have some cool marketing, or perhaps everyone is scrambling to mitigate the issue for their infrastructure?

There are a few reasons your company might be safe:

1. All your sites serve https directly from web servers (no https termination and passthrough as internal http traffic)

2. You use Cloudflare and you cannot reach your sites directly (article says that Cloudflare rewrites all headers so probably avoids problem)

3. Your front end is properly hardened and it prevents malformed or duplicate headers

4. Your front end does not reuse connections to your web server (maybe the quickest emergency bandage?)

5. Your front/back end do not allow chunking (or pipelining).

This is going to affect so many major sites, and requires patches to critical infrastructure: pass me the popcorn so I can watch this horror show unfold.

[albinowax_]

Hi, I'm the author of the article.

Regarding point 5, the front-end doesn't need to support pipelining at all, and the back-end doesn't require it either in most cases. Regarding chunk support, yeah you could patch this by disabling chunked requests on both systems, but if only one system disables it that pretty much just makes the situation worse.

I think your first point could be misread. If you have a front-end and a back-end, and they talk to eachother using HTTPS, that's exploitable. What's not exploitable is when you don't have a frontend at all, or your frontend isn't doing any kind of request parsing (ie it's a network load balancer).

[lhuser123]

> What's not exploitable is when you don't have a frontend at all, or your frontend isn't doing any kind of request parsing

I think that’s exactly what he was trying to say in the first point. Anyway thanks for stressing that, it helped me understand better what is happening.

[cryptonector]

Disabling chunking is often not an option.

EDIT: Basically, chunked transfer encoding is not an option for any front-end systems (reverse proxies / load balancers of any kind). Also note that because there exist apps that associate authentication state with connections (though they're not supposed to), one should generally avoid mixing traffic from different users onto one connection.

[albinowax_]

Glad you like the research! I'll look into emphasising the vector though I'm personally coming to the viewpoint that the root cause is a design flaw in HTTP/1.1, and HTTP/2 is the only truly reliable fix.

[robocat]

Thanks for the comments.

I don't see that using HTTP/2 is realistic.

(a) Are you saying that using HTTP/2 from the browser makes headers in your infrastructure secure?

(b) Some of our enterprise clients use security proxies (e.g. Cisco WSA) which do not support HTTP/2 and force connections from the browser to use HTTP1.1. Aside: Cisco WSA is super crappy: we have recorded a repeatable corruption that passed information between HTTPS sessions (It was a obsolete device so we didn't report it to Cisco or the client - but I would bet good money there are plentiful major security flaws with Cisco WSA).

(c) If you are suggesting using HTTP/2 between frontend and backend, that seems unrealistic to implement.

From other thread:

> If you have a front-end and a back-end, and they talk to eachother using HTTPS, that's exploitable

I couldn't understand how - surely packets would be completely broken (how can you append a valid packet to an HTTPS request, or get a valid HTTPS reply to an another connection?)

Perhaps a spiffy name, an icon, and a cool website would give this more visibility HAHA!

PS: I am surprised this isn't getting more attention on HN - it seems like a really fatal security issue that will affect heaps of sites - oh well.

[albinowax_]

I'm suggesting using HTTP/2 between the frontend and backend. I'm saying this is the only reliable fix, not that it's easy to implement.

Regarding HTTPS between the frontend and backend, remember that's just HTTP over a TLS stream instead of TCP. As long as the frontend still reuses these TLS streams, it's exploitable. To be clear, this is in a scenario where the front-end terminates the HTTPS connection from the client then routes requests over a pool of persistent HTTPS connections to the backend. Does that make sense? Since I've been exploiting this from a black-box perspective, I can't really tell for sure whether I've successfully exploited any websites actually doing this.

And yeah it would have been nice of this had done better on HN but between presenting it at two major security conferences and adding automated detection to a popular web scanner, it ought to achieve decent awareness over the next few months. Hopefully.