I don’t fully understand the failure here. It’s it that the load balancer has some sort of underflow / overflow bug that leaks traffic? I’m thinking of wall bleed and cloud bleed
It's not a memory safety problem; it's incorrect protocol implementation.
AFAICT from reading the article, Discord rolled their own HTTP proxy that takes client requests and coalesces them into a few persistent connections to another HTTP server on GCP.
i.e.,
client <----> discord custom proxy <----> gcp
That proxy forwards requests without sufficient validation, which opens the door to a bunch of fun attacks.
For example, a malicious client can send a partial request like this:
POST /whatever HTTP/1.1\r\n
Host: discord.storage.googleapis.com\r\n
Content-Length: 1000\r\n
\r\n
and instead of waiting for the remaining 1000 bytes, the proxy will forward that request fragment as though it's a complete request. GCP, on the other side of the proxy, will then consider the next 1000 bytes on the connection (i.e., the next few clients' requests) to be part of the malicious client's request body. If the POST request creates a resource accessible to the malicious client, then they can see the contents of the other clients' requests.
I gave a talk on this a while ago that explains it pretty well (I think). See here.
The blog links the PortSwigger write-up on HTTP desync attacks that goes into detail. Their HTTP Request Smuggling document shows the request flow more at the protocol level.
kenballus | 6 hours ago
You'd be surprised! I have seen this exact bug many times.
GCP's classic application load balancer used to be full of these bugs until pretty recently. Same with AWS CloudFront. Might still be :)
vaguelytagged | 5 hours ago
I don’t fully understand the failure here. It’s it that the load balancer has some sort of underflow / overflow bug that leaks traffic? I’m thinking of wall bleed and cloud bleed
kenballus | 4 hours ago
It's not a memory safety problem; it's incorrect protocol implementation.
AFAICT from reading the article, Discord rolled their own HTTP proxy that takes client requests and coalesces them into a few persistent connections to another HTTP server on GCP.
i.e.,
That proxy forwards requests without sufficient validation, which opens the door to a bunch of fun attacks.
For example, a malicious client can send a partial request like this:
and instead of waiting for the remaining 1000 bytes, the proxy will forward that request fragment as though it's a complete request. GCP, on the other side of the proxy, will then consider the next 1000 bytes on the connection (i.e., the next few clients' requests) to be part of the malicious client's request body. If the POST request creates a resource accessible to the malicious client, then they can see the contents of the other clients' requests.
I gave a talk on this a while ago that explains it pretty well (I think). See here.
vaguelytagged | 3 hours ago
awesome thanks!
poptart | 5 hours ago
The blog links the PortSwigger write-up on HTTP desync attacks that goes into detail. Their HTTP Request Smuggling document shows the request flow more at the protocol level.