New year, new vulnerability: HAProxy critical security update

The Christmas tree is still up, you’ve barely swept away the used party poppers and champagne corks from your New Year celebrations - and already, there’s a new security issue to be aware of.

A vulnerability has been found which could enable a hacker to crash HAProxy when an incorrect frame length check is performed on HEADERS frame having the PRIORITY flag, possibly resulting in a read-past-bound which can cause a crash depending on how the frame is crafted. This isn’t a data security issue, but downtime is obviously bad news for any business, including the big players who are using HAProxy for their sites.

Be reassured that most of our customers won’t be affected.

This bug will only be an issue for users who’ve already upgraded to HTTP/2. If we think you might be vulnerable, we will already have notified you.

Ahead of the curve

Although the issue has only just been announced, we already have a fix available. You can request the patch through our support by emailing support@loadbalancer.org if you want it now, or wait until we put out v8.3.6 in a few weeks. Our release schedule, complete with thorough testing, hasn’t been disrupted.

How can we stay ahead of the curve like this? Because we’re part of the open-source inner circle, we’re always among the first to get the call from HAProxy when something goes wrong. This means that we’re always on top of bugs before they become a problem.

Applying the patch

We’ve taken the time to test out HAProxy’s patch - here are the steps:

• Extract the HAProxy archive within /usr/local/src and cd to the haproxy-1* source directory

• Apply the patch 0001-BUG-CRITICAL-mux-h2-re-check-the-frame-length-when-P.patch

• The mux_h2.c file has now been patched with the original’s name appended with mux_h2.c.orig

• After compiling patched HAProxy.1.8.14, run a quick test to ensure that the service is active and functioning correctly.

And that’s it! Major kudos to Willy and the HAProxy team for putting in the hours on this over the festive period.

Don’t be next

Last year saw big names including Marriot Hotels, Quora, British Airways, YouTube and more experience security breaches. Who will be next in 2019?

If you’d rather not be hitting the headlines for this less than pleasant reason, a WAF is absolutely the best way to stay secure. Loadbalancer.org recommends that you consider a market-leading WAF such as CloudFlare or Incapsula. If you’re already using our load balancer for your applications, though, you’ve got the extra firepower of a built-in WAF.

Since a customer once joked that ‘taming a dragon would be easier than configuring a WAF,’ we’ve also provided some guidance on how to use it with as little pain as possible.

UPDATE: July 2019, new vulnerability (HTX)

Six months later and summer is upon us: the barbecue is out, summer holidays are here, and a new vulnerability has been found in HAProxy.

The good news is that all Loadbalancer.org appliances are immune to the new vulnerability.

A problem was found in HAProxy’s new native HTTP representation, known as HTX. Designed as a future-proof way of handling HTTP data efficiently, HTX was introduced in HAProxy 1.9 and became enabled by default in HAProxy 2.0.

As of the date of writing, Loadbalancer.org appliances (version 8.3.8) use the mature HAProxy 1.8, which does not include the HTX feature and is therefore completely immune.

Fixes have already been written, tested, and released by the HAProxy project, working with the original bug reporter in the best traditions of free and open-source software. For the curious, the original bug report can be found here, and anyone running their own instance of HAProxy 1.9 or 2.0 is advised to update to 1.9.9 or 2.0.3 to receive the fix.

If you have any questions about HAProxy security, please don't hesitate to get in touch with us by either leaving a comment below or clicking here.