HAProxy is a open source load balancer sever that is used for high traffic web sites. Considering it is used by many large companies, it is a good target to find a vulnerability in.
With HAProxy, the HTTP request needs to be processed and forwarded on to the next server in the chain. When processing requests, there are two main phases:
- Initial parsing. The
Content-Length is taken out to be used later. It should be noted that the request is translated into its own internal structure to parse.
- The internal structure is processed, that was created in the initial parsing.
Within HAProxy, there is an integer overflow on header length. The size is only 8 bits and unsigned, this overflow can be triggered without crashing the application instantly. For instance, a header of size 270 would overflow to a size of 14. Why is this can issue?
In phase 1 of grabbing the Content-Length will be stored. This grabs all of the content for our payload. After the integer overflow occurs in stage 2, the location in the string to parse is now confused! Hence, we can change the expected Content-Length header of the request.
With the parsing confused, we can confuse the queue to continue parsing at the end of the request with our fake Content-Length header. What does this allow? HTTP Smuggling! This allows for an ACL bypass, WAF bypass and many other issues. This is an incredible impactful vulnerability.
I really appreciate when memory corruption vulnerabilities are not simply left as "pwn it now". This was not taken to code execution but turned a small overflow into an actual impactful attack.