[HN Gopher] HAProxy vulnerability enables HTTP request smuggling...
       ___________________________________________________________________
        
       HAProxy vulnerability enables HTTP request smuggling attacks
        
       Author : feross
       Score  : 71 points
       Date   : 2021-09-09 15:48 UTC (7 hours ago)
        
 (HTM) web link (portswigger.net)
 (TXT) w3m dump (portswigger.net)
        
       | kmos17 wrote:
       | This is the official haproxy notice on this:
       | 
       | https://www.haproxy.com/blog/september-2021-duplicate-conten...
       | 
       | 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.
        
       | andrewguy9 wrote:
       | 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.
        
         | codetrotter wrote:
         | 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.
        
       | pjmlp wrote:
       | For the TL;DR; folks
       | 
       | > "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.
       | 
       | Usual story with C "secure" software.
        
         | citrin_ru wrote:
         | Wrapping on unsigned integer overflow is not specific to C at
         | all and exists in most languages (unlike signed overflow which
         | is UB in C).
        
           | orthecreedence wrote:
           | Common lisp wins again... ;)
        
       | [deleted]
        
       | lnxg33k1 wrote:
       | I don't really understand this fuss about Django, coming from
       | PHP, in terms of web enabling products, python stuff look like
       | toys
        
         | type0 wrote:
         | care to elaborate why you think that?
        
           | lnxg33k1 wrote:
           | 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?
        
         | mtmail wrote:
         | Did you mean to comment on a different thread, maybe the 'Show
         | HN: Heroku Alternative for Python/Django apps' one?
        
       | vgb2k18 wrote:
       | > 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.
        
       | nezirus wrote:
       | The article is really poor and not original, doesn't link to
       | haproxy or jfrog web pages or haproxy git repo.
       | 
       | Please link the original jfrog blog post with in depth analysis:
       | 
       | https://jfrog.com/blog/critical-vulnerability-in-haproxy-cve...
        
         | sciurus wrote:
         | 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...
        
       | iancarroll wrote:
       | 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.
        
         | iso8859-1 wrote:
         | Why would the language they use make them less responsive?
        
       ___________________________________________________________________
       (page generated 2021-09-09 23:00 UTC)