Bug 1214102 (CVE-2023-40225) - VUL-0: CVE-2023-40225: haproxy: reject any empty content-length header value
Summary: VUL-0: CVE-2023-40225: haproxy: reject any empty content-length header value
Status: RESOLVED FIXED
Alias: CVE-2023-40225
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Security Team bot
QA Contact: Security Team bot
URL: https://smash.suse.de/issue/374765/
Whiteboard: CVSSv3.1:SUSE:CVE-2023-40225:5.9:(AV:...
Keywords:
Depends on:
Blocks:
 
Reported: 2023-08-09 07:50 UTC by Robert Frohl
Modified: 2024-05-03 14:58 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Robert Frohl 2023-08-09 09:57:12 UTC
The content-length header parser has its dedicated function, in order
to take extreme care about invalid, unparsable, or conflicting values.
But there's a corner case in it, by which it stops comparing values
when reaching the end of the header. This has for a side effect that
an empty value or a value that ends with a comma does not deserve
further analysis, and it acts as if the header was absent.

While this is not necessarily a problem for the value ending with a
comma as it will be cause a header folding and will disappear, it is a
problem for the first isolated empty header because this one will not
be recontructed when next ones are seen, and will be passed as-is to the
backend server. A vulnerable HTTP/1 server hosted behind haproxy that
would just use this first value as "0" and ignore the valid one would
then not be protected by haproxy and could be attacked this way, taking
the payload for an extra request.

In field the risk depends on the server. Most commonly used servers
already have safe content-length parsers, but users relying on haproxy
to protect a known-vulnerable server might be at risk (and the risk of
a bug even in a reputable server should never be dismissed).

A configuration-based work-around consists in adding the following rule
in the frontend, to explicitly reject requests featuring an empty
content-length header that would have not be folded into an existing
one:

    http-request deny if { hdr_len(content-length) 0 }

The real fix consists in adjusting the parser so that it always expects a
value at the beginning of the header or after a comma. It will now reject
requests and responses having empty values anywhere in the C-L header.

This needs to be backported to all supported versions. Note that the
modification was made to functions h1_parse_cont_len_header() and
http_parse_cont_len_header(). Prior to 2.8 the latter was in
h2_parse_cont_len_header(). One day the two should be refused but the
former is also used by Lua.

The HTTP messaging reg-tests were completed to test these cases.

Thanks to Ben Kallus of Dartmouth College and Narf Industries for
reporting this! (this is in GH #2237).

http://git.haproxy.org/?p=haproxy.git;a=commitdiff;h=6492f1f29d738457ea9f382aca54537f35f9d856
Comment 3 OBSbugzilla Bot 2023-08-09 13:05:02 UTC
This is an autogenerated message for OBS integration:
This bug (1214102) was mentioned in
https://build.opensuse.org/request/show/1103151 Factory / haproxy
Comment 10 Maintenance Automation 2023-08-29 08:57:12 UTC
SUSE-SU-2023:3469-1: An update that solves one vulnerability can now be installed.

Category: security (moderate)
Bug References: 1214102
CVE References: CVE-2023-40225
Sources used:
openSUSE Leap 15.5 (src): haproxy-2.4.22+git0.f8e3218e2-150400.3.16.1
SUSE Linux Enterprise Micro for Rancher 5.3 (src): haproxy-2.4.22+git0.f8e3218e2-150400.3.16.1
SUSE Linux Enterprise Micro 5.3 (src): haproxy-2.4.22+git0.f8e3218e2-150400.3.16.1
SUSE Linux Enterprise Micro for Rancher 5.4 (src): haproxy-2.4.22+git0.f8e3218e2-150400.3.16.1
SUSE Linux Enterprise Micro 5.4 (src): haproxy-2.4.22+git0.f8e3218e2-150400.3.16.1
SUSE Linux Enterprise High Availability Extension 15 SP4 (src): haproxy-2.4.22+git0.f8e3218e2-150400.3.16.1
SUSE Linux Enterprise High Availability Extension 15 SP5 (src): haproxy-2.4.22+git0.f8e3218e2-150400.3.16.1
openSUSE Leap 15.4 (src): haproxy-2.4.22+git0.f8e3218e2-150400.3.16.1
openSUSE Leap Micro 5.3 (src): haproxy-2.4.22+git0.f8e3218e2-150400.3.16.1
openSUSE Leap Micro 5.4 (src): haproxy-2.4.22+git0.f8e3218e2-150400.3.16.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 11 Maintenance Automation 2023-08-30 16:30:08 UTC
SUSE-SU-2023:3490-1: An update that solves one vulnerability can now be installed.

Category: security (moderate)
Bug References: 1214102
CVE References: CVE-2023-40225
Sources used:
SUSE Linux Enterprise High Availability Extension 15 SP2 (src): haproxy-2.0.31-150200.11.23.1
SUSE Linux Enterprise High Availability Extension 15 SP3 (src): haproxy-2.0.31-150200.11.23.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 13 Maintenance Automation 2023-12-06 16:31:08 UTC
SUSE-SU-2023:4646-1: An update that solves two vulnerabilities can now be installed.

Category: security (moderate)
Bug References: 1214102, 1217653
CVE References: CVE-2023-40225, CVE-2023-45539
Sources used:
SUSE Linux Enterprise High Availability Extension 15 SP1 (src): haproxy-2.0.31-150100.8.34.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 14 Robert Frohl 2024-05-03 14:58:41 UTC
done, closing