Agreed jfrog has the more in-depth exploration in this case. Still, James Kettle from Portswigger has donegood work in this area; I'd recommend anyone who's not familiar with HTTP request smuggling read https://portswigger.net/research/http-desync-attacks-request...
It can be mitigated without needing to upgrade. The post includes a simple mitigation by adding two rules to each front end that block request/responses trying to exploit this vulnerability.
Perhaps interesting to note that this vulnerability and the HTTP/2 one before it, do not affect earlier versions of haproxy like 1.7. This one was part of HTX, something that was added in later versions. HTX was a solution to accomodate HTTP/2, 3 and whatever the online ad services company comes up with next to accomodate its online advertiser customers. Complexity. HTX wasnt necessary for HTTP/0.9, 1.0 or 1.1.
> The vulnerability was fixed [...] by adding size checks for the name and value lengths.
Would it make sense in this case to review the entire codebase for valid size checks? Genuinely curious. Not interested in debating one language VS another this time, merely, the best practices for the language specific to this codebase.
Despite what language it's written in, HAProxy has a very responsive team and it was great to work with them when we had discovered a security issue in it a bit ago.
It took quite a few emails back and forth with them to understand some very subtle interactions in AWS ALB->HAProxy->Backend, and after they issued a fix they even got on a call with us and AWS to discuss the ALB's behavior (although AWS did not change anything sadly).
Amusingly, like 1vuio0pswjnm7's comment, we also temporarily patched it with a HAProxy ACL.
HAProxy is written in C, which has no GC by default. Also, we are talking about "team responsiveness" which sounds more like it is the time that the team needs to react on a bug being reported. So GC pauses can't be what iancaroll meant.
I can be detailed when I have a keyboard, but as example let's say the orm using active recordss and mixing db concern with business logic, or the simplistic "controllers" or lack of DI solutions, enough?
> “In our case, however, the attack was made possible by utilizing an integer overflow vulnerability that allowed reaching an unexpected state in HAProxy while parsing an HTTP request – specifically – in the logic that deals with Content-Length headers.”
> The vulnerability was fixed in HAProxy versions 2.0.25, 2.2.17, 2.3.14, and 2.4.4 by adding size checks for the name and value lengths.
Does anyone remember when HaProxy’s tag line was” Security - Not even one vulnerability in 10 years”. I loved that product.
Before they took all that money. Before they added all the crap people want but don’t need. It’s hard to do the fundamentals, especially when you take your eye off the ball.
I see what you are saying but it could also be for example:
1) over time more inherent complexity has accrued, making vulnerabilities more likely to occur
2) vulnerability analysis has improved, meaning that vulnerabilities are being found today where in the past certain vulnerabilities (either same or different ones) were present without being found
and we don’t know that things are being added that’s “not needed”, or that they are “taking the eyes off the ball”.
Do we even know that they would be able to stay relevant without taking money? Taking money seems, in isolation, a good thing to me.
I didn't know that used to be their tagline though. That this changed is an interesting perspective.
And as for point #2 specifically, detection improved as well so it's not as if attackers are clearly winning with better attacks on larger attach surfaces. There was a talk recently (can't remember which conference) optimistically wondering if we might be succeeding more than we're failing, since the impactful bugs are getting much harder to find. We're very clearly not there yet, but try to get an exploit on a phone now and compare that to 2011 or 2001. There is a trend there and it's not the same one as GP claims HAProxy is going in. Though your point #1 might adequately explain that, in my head they're still just a proxy (I don't work with the product from a sysadmin perspective) so I wouldn't have known of it if it hadn't come up.
Please link the original jfrog blog post with in depth analysis:
https://jfrog.com/blog/critical-vulnerability-in-haproxy-cve...