HAProxy through 2.0.2 allows attackers to cause a denial of service (ha_panic) via vectors related to htx_manage_client_side_cookies in proto_htx.c.

This update for haproxy to version 2.0.5+git0.d905f49a fixes the following issues :

Security issue fixed :

  - CVE-2019-14241: Fixed a cookie memory corruption     problem. (bsc#1142529)

The update to 2.0.5 brings lots of features and bugfixes :

  - new internal native HTTP representation called HTX, was     already in 1.9 and is now enabled by default in 2.0

  - end-to-end HTTP/2 support including trailers and     continuation frames, as needed for gRPC ; HTTP/2 may     also be upgraded from HTTP/1.1 using the H2 preface;

  - server connection pooling and more advanced reuse, with     ALPN protocol negotiation (already in 1.9)

  - layer 7 retries, allowing to use 0-RTT and TCP Fast Open     to the servers as well as on the frontend

  - much more scalable multi-threading, which is even     enabled by default on platforms where it was     successfully tested ; by default, as many threads are     started as the number of CPUs haproxy is allowed to run     on. This removes a lot of configuration burden in VMs     and containers

  - automatic maxconn setting for the process and the     frontends, directly based on the number of available FDs     (easier configuration in containers and with systemd)

  - logging to stdout for use in containers and systemd     (already in 1.9). Logs can now provide micro-second     resolution for some events

  - peers now support SSL, declaration of multiple     stick-tables directly in the peers section, and     synchronization of server names, not just IDs

  - In master-worker mode, the master process now exposes     its own CLI and can communicate with all other processes     (including the stopping ones), even allowing to connect     to their CLI and check their state. It is also possible     to start some sidecar programs and monitor them from the     master, and the master can automatically kill old     processes that survived too many reloads

  - the incoming connections are load-balanced between all     threads depending on their load to minimize the     processing time and maximize the capacity (already in     1.9)

  - the SPOE connection load-balancing was significantly     improved in order to reduce high percentiles of SPOA     response time (already in 1.9)

  - the 'random' load balancing algorithm and a     power-of-two-choices variant were introduced

  - statistics improvements with per-thread counters for     certain things, and a prometheus exporter for all our     statistics;

  - lots of debugging help, it's easier to produce a core     dump, there are new commands on the CLI to control     various things, there is a watchdog to fail cleanly when     a thread deadlock or a spinning task are detected, so     overall it should provide a better experience in field     and less round trips between users and developers (hence     less stress during an incident).

  - all 3 device detection engines are now compatible with     multi-threading and can be build-tested without any     external dependencies

  - 'do-resolve' http-request action to perform a DNS     resolution on any, sample, and resolvers now support     relying on /etc/resolv.conf to match the local resolver

  - log sampling and balancing : it's now possible to send 1     log every 10 to a server, or to spread the logging load     over multiple log servers;

  - a new SPOA agent (spoa_server) allows to interface     haproxy with Python and Lua programs

  - support for Solaris' event ports (equivalent of kqueue     or epoll) which will significantly improve the     performance there when dealing with numerous connections

  - some warnings are now reported for some deprecated     options that will be removed in 2.1. Since 2.0 is long     term supported, there's no emergency to convert them,     however if you see these warnings, you need to     understand that you're among their extremely rare users     and just because of this you may be taking risks by     keeping them

  - A new SOCKS4 server-side layer was provided ; it allows     outgoing connections to be forwarded through a SOCKS4     proxy (such as ssh -D).

  - priority- and latency- aware server queues : it is     possible now to assign priorities to certain requests     and/or to give them a time bonus or penalty to refine     control of the traffic and be able to engage on SLAs.

  - internally the architecture was significantly redesigned     to allow to further improve performance and make it     easier to implement protocols that span over multiple     layers (such as QUIC). This work started in 1.9 and will     continue with 2.1.

  - the I/O, applets and tasks now share the same     multi-threaded scheduler, giving a much better     responsiveness and fairness between all tasks as is     visible with the CLI which always responds instantly     even under extreme loads (started in 1.9)

  - the internal buffers were redesigned to ease zero-copy     operations, so that it is possible to sustain a high     bandwidth even when forwarding HTTP/1 to/from HTTP/2     (already in 1.9)

This update was imported from the SUSE:SLE-15-SP1:Update update project.

This update for haproxy to version 2.0.5+git0.d905f49a fixes the following issues :

Security issue fixed :

  - CVE-2019-14241: Fixed a cookie memory corruption     problem. (bsc#1142529)

The update to 2.0.5 brings lots of features and bugfixes :

  - new internal native HTTP representation called HTX, was     already in 1.9 and is now enabled by default in 2.0

  - end-to-end HTTP/2 support including trailers and     continuation frames, as needed for gRPC ; HTTP/2 may     also be upgraded from HTTP/1.1 using the H2 preface;

  - server connection pooling and more advanced reuse, with     ALPN protocol negotiation (already in 1.9)

  - layer 7 retries, allowing to use 0-RTT and TCP Fast Open     to the servers as well as on the frontend

  - much more scalable multi-threading, which is even     enabled by default on platforms where it was     successfully tested ; by default, as many threads are     started as the number of CPUs haproxy is allowed to run     on. This removes a lot of configuration burden in VMs     and containers

  - automatic maxconn setting for the process and the     frontends, directly based on the number of available FDs     (easier configuration in containers and with systemd)

  - logging to stdout for use in containers and systemd     (already in 1.9). Logs can now provide micro-second     resolution for some events

  - peers now support SSL, declaration of multiple     stick-tables directly in the peers section, and     synchronization of server names, not just IDs

  - In master-worker mode, the master process now exposes     its own CLI and can communicate with all other processes     (including the stopping ones), even allowing to connect     to their CLI and check their state. It is also possible     to start some sidecar programs and monitor them from the     master, and the master can automatically kill old     processes that survived too many reloads

  - the incoming connections are load-balanced between all     threads depending on their load to minimize the     processing time and maximize the capacity (already in     1.9)

  - the SPOE connection load-balancing was significantly     improved in order to reduce high percentiles of SPOA     response time (already in 1.9)

  - the 'random' load balancing algorithm and a     power-of-two-choices variant were introduced

  - statistics improvements with per-thread counters for     certain things, and a prometheus exporter for all our     statistics;

  - lots of debugging help, it's easier to produce a core     dump, there are new commands on the CLI to control     various things, there is a watchdog to fail cleanly when     a thread deadlock or a spinning task are detected, so     overall it should provide a better experience in field     and less round trips between users and developers (hence     less stress during an incident).

  - all 3 device detection engines are now compatible with     multi-threading and can be build-tested without any     external dependencies

  - 'do-resolve' http-request action to perform a DNS     resolution on any, sample, and resolvers now support     relying on /etc/resolv.conf to match the local resolver

  - log sampling and balancing : it's now possible to send 1     log every 10 to a server, or to spread the logging load     over multiple log servers;

  - a new SPOA agent (spoa_server) allows to interface     haproxy with Python and Lua programs

  - support for Solaris' event ports (equivalent of kqueue     or epoll) which will significantly improve the     performance there when dealing with numerous connections

  - some warnings are now reported for some deprecated     options that will be removed in 2.1. Since 2.0 is long     term supported, there's no emergency to convert them,     however if you see these warnings, you need to     understand that you're among their extremely rare users     and just because of this you may be taking risks by     keeping them

  - A new SOCKS4 server-side layer was provided ; it allows     outgoing connections to be forwarded through a SOCKS4     proxy (such as ssh -D).

  - priority- and latency- aware server queues : it is     possible now to assign priorities to certain requests     and/or to give them a time bonus or penalty to refine     control of the traffic and be able to engage on SLAs.

  - internally the architecture was significantly redesigned     to allow to further improve performance and make it     easier to implement protocols that span over multiple     layers (such as QUIC). This work started in 1.9 and will     continue with 2.1.

  - the I/O, applets and tasks now share the same     multi-threaded scheduler, giving a much better     responsiveness and fairness between all tasks as is     visible with the CLI which always responds instantly     even under extreme loads (started in 1.9)

  - the internal buffers were redesigned to ease zero-copy     operations, so that it is possible to sustain a high     bandwidth even when forwarding HTTP/1 to/from HTTP/2     (already in 1.9)

This update was imported from the SUSE:SLE-15:Update update project.

An update of the haproxy package has been released.

ID	Name	Product	Family	Severity
131281	openSUSE Security Update : haproxy (openSUSE-2019-2556)	Nessus	SuSE Local Security Checks	high
131280	openSUSE Security Update : haproxy (openSUSE-2019-2555)	Nessus	SuSE Local Security Checks	high
128731	Photon OS 3.0: Haproxy PHSA-2019-3.0-0026	Nessus	PhotonOS Local Security Checks	high
128726	Photon OS 1.0: Haproxy PHSA-2019-1.0-0249	Nessus	PhotonOS Local Security Checks	high

Detections

Analytics

CVE-2019-14241

high

Tenable Plugins

high

high

high

high