Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
===========================================================================
AUSCERT External Security Bulletin Redistribution
ESB-2020.3149.2
The BIG-IP system may not interpret an HTTP request the same
way the target web server interprets it
25 January 2021
===========================================================================
AusCERT Security Bulletin Summary
---------------------------------
Product: BIG-IP
Publisher: F5 Networks
Operating System: Network Appliance
Impact/Access: Reduced Security -- Unknown/Unspecified
Resolution: Mitigation
Original Bulletin:
https://support.f5.com/csp/article/K27551003
Revision History: January 25 2021: Vendor updated security advisory status
September 15 2020: Initial Release
- --------------------------BEGIN INCLUDED TEXT--------------------
K27551003: The BIG-IP system may not interpret an HTTP request the same way the
target web server interprets it
Original Publication Date: 24 Jun, 2020
Latest Publication Date: 22 Jan, 2021
Security Advisory Description
This issue occurs when all of the following conditions are met:
o A virtual server is associated with an HTTP profile.
o An iRule or LTM policy that uses HTTP header information is associated with
the virtual server.
o The BIG-IP system receives a specially crafted HTTP request.
Impact
Customers should evaluate whether this behavior is in line with how their
application processes this traffic, especially when using iRules or Local
Traffic Policies in a security context such as determining ACL or selecting ASM
policies based on request content.
Symptoms
As a result of this issue, you may encounter one or more of the following
symptoms:
o The BIG-IP HTTP parser may not parse requests in the same manner as a web
server.
o The following examples illustrate how the BIG-IP system interprets the
different HTTP requests:
Interpretation of non-encoded white spaces in HTTP URIs
Interpretation of HTTP/0.9 requests that include HTTP headers beyond
the method, URI, and version
Interpretation of white space in HTTP headers between the header name
and the separating colon
Interpretation of multiple HTTP Host headers
Interpretation of absolute URIs containing Host information
Interpretation of non-encoded white spaces in HTTP URIs
Review the following request:
GET /file.txt foo/file2.txt HTTP/1.1\r\n
Host: www.example.com\r\n
Connection: close\r\n\r\n
The following is true about the previous request:
The request is sent to the server as previously noted (without any
changes).
An iRule or Local Traffic Policy extracting the path/URL captures the
string up to the first white space.
For example:
[HTTP::path] = /file.txt
[HTTP::uri] = /file.txt
Note: You can configure the BIG-IP ASM system to block such requests by
ensuring the Bad HTTP Version violation within the HTTP Protocol
Compliance Failed category is enabled.
F5 has assigned ID858285 to the requirement to have an option to reject
such requests within the BIG-IP LTM HTTP profile configuration.
Interpretation of HTTP/0.9 requests that include HTTP headers beyond
the method, URI, and version
Review the following request:
GET /file.txt HTTP/0.9
Host: www.example.com
The following is true about the previous request:
The request is sent to the server as previously noted (without any
changes).
An iRule or Local Traffic Policy extracting the HTTP Host header
returns an empty result.
Per RFC 1945, HTTP/0.9 Simple-Requests do not contain any headers or
information beyond the URI requested. The BIG-IP LTM ignores all data
beyond the URI and passes it to the target pool member unmodified and
without additional inspection or parsing.
For example:
[HTTP::host] = <blank>
Note: You can configure the BIG-IP ASM system to block requests that
lack an explicitly defined HTTP version (for example, 0.9 requests)
through the HTTP Protocol Compliance Failed violation. If you want to
block all HTTP/0.9 requests, including those with a version explicitly
defined, consider entering a simple iRule such as the following:
when HTTP_REQUEST {
if {[HTTP::version] eq "0.9"} {
reject
}
}
Interpretation of white space in HTTP headers between the header name
and the separating colon
Review the following request:
GET /file.txt HTTP/1.0
Host : www.example.com
Connection: close
The following is true about the previous request:
The request is sent to the server as previously noted (without any
changes).
The BIG-IP system ignores any additional white space between the header
name and the separating colon, processes the HTTP headers as
normal, and makes the values available to iRules and Local Traffic
Policies with the additional white space removed.
For example:
[HTTP::header names] = Host Connection
[HTTP::host] = www.example.com
[HTTP::header value Host] = www.example.com
The HTTP RFCs do not define white space characters between HTTP header
names and the separating colon (see RFC 2616 section 4.2 and RFC 7230
section 3.2.3). For BIG-IP versions with the fix for ID 858289, the
system incorrectly drops and sends a TCP reset for requests with white
space between HTTP header names and separating colons. F5 assigned ID
967353 to the requirement for a proxy to remove any such white space
from a response message before the system forwards the message (see RFC
7230 section 3.2.4).
In addition to addressing ID 967353, also evaluate how your application
handles such white space.
Interpretation of multiple HTTP Host headers
Review the following request:
GET /file.txt HTTP/1.0
Host: host1.example.com
Host: host2.example.com
Connection: close
The following is true about the previous request:
The request is sent to the server as previously noted (without any
changes).
An iRule or Local Traffic Policy extracting the HTTP Host header
returns only the last header value, per the documentation for
HTTP::header (https://clouddocs.f5.com/api/irules/HTTP__header.html)
and HTTP::host (https://clouddocs.f5.com/api/irules/HTTP__host.html).
For example:
[HTTP::header names] = Host Host Connection
[HTTP::host] = host2.example.com
[HTTP::header value Host] = host2.example.com
[HTTP::header values Host] = host1.example.com host2.example.com
Note: You can configure the BIG-IP ASM system to block requests with
multiple Host headers by enabling the Multiple Host Headers violation
within the HTTP Protocol Compliance Failed violation category.
Additionally, the following iRule example concatenates multiple Host
header values together before examining them:
when HTTP_REQUEST {
if { [HTTP::header values "Host"] eq "www.example.com" } then {
# A single Host-header was received containing www.example.com
}
}
F5 has assigned ID858297 to the requirement to have an option to reject
such requests within the BIG-IP LTM HTTP profile configuration.
Interpretation of absolute URIs containing Host information
Review the following request:
GET http://www.bar.com/file.txt HTTP/1.1
Host: www.example.com
Connection: close
The following is true about the previous request:
The request is sent to the server as previously noted (without any
changes).
An iRule or Local Traffic Policy extracting the HTTP Host header
returns only the host information contained in the Host header and not
the information contained in the absolute URI.
For example:
[HTTP::host] = www.example.com
[HTTP::header value Host] = www.example.com
If the target application complies with RFC 2616 section 5.2 or RFC
7230 section 5.5, then it may honor the host portion of the Absolute
URI and may, therefore, interpret the request in a different manner
than the BIG-IP system does.
F5 has assigned ID858301 to the requirement to have the BIG-IP LTM HTTP
profile handle such Absolute-URI requests per the guidance in RFC 7230.
Security Advisory Status
F5 Product Development has assigned IDs 858285, 858289, 858297, and 858301 to
this issue. F5 has confirmed that this issue exists in the products listed in
the Applies to (see versions) box, located in the upper-right corner of this
article. For information about releases, point releases, or hotfixes that
resolve this issue, refer to the following table.
+------------------+-----------------+----------------------------------------+
|Type of fix |Fixes introduced |Related articles |
| |in | |
+------------------+-----------------+----------------------------------------+
|Release |16.0.0 |K2200: Most recent versions of F5 |
| | |software |
+------------------+-----------------+----------------------------------------+
| |15.1.2.1 | |
|Point release/ |15.0.1.4 |K9502: BIG-IP hotfix and point release |
|hotfix |13.1.3.4 |matrix |
| |12.1.5.2^1 | |
+------------------+-----------------+----------------------------------------+
^1In addition to the versions listed in the Fixes introduced in column, fixes
for ID 858297 and ID 858301 were also introduced in the 12.1.5.2 point release.
Security Advisory Recommended Actions
Workaround
On BIG-IP versions that include mitigations for the IDs discussed in this
article, note that enforcing RFC Compliance is achieved differently depending
on the version, per the following table.
+--------+--------------------------------------------------------------------+
|BIG-IP |Mitigations |
|versions| |
+--------+--------------------------------------------------------------------+
| |The Enforce RFC Compliance checkbox is available in the Enforcement |
| |section of the HTTP profile. To fix the issue described in this |
|15.1.0 |article, you must select this checkbox in the HTTP profile for the |
|or later|affected BIG-IP virtual server. Selecting this checkbox causes the |
| |system to silently drop HTTP requests that do not conform to HTTP |
| |RFCs as described in this article. |
+--------+--------------------------------------------------------------------+
Important: If either HTTP PSM or ASM are configured on a virtual server, the
state of the "Enforce RFC Compliance" check box (15.1.0+) is ignored on that
virtual server. Requests will be allowed or blocked based on the configured ASM
or PSM policy.
Alternatively, to avoid this issue, customers should evaluate how their
application interprets HTTP requests in accordance with published RFCs and how
any customer-defined conditional traffic handling (for example, iRules or Local
Traffic Policies) interprets the same HTTP requests to ensure that the
application stack behaves consistently.
Acknowledgements
F5 would like to acknowledge the F5 DevCentral MVP Kai Wilke of itacs GmbH for
bringing this issue to our attention, and for following the highest standards
of responsible disclosure.
Supplemental Information
o K51812227: Understanding Security Advisory versioning
o K41942608: Overview of AskF5 Security Advisory articles
o K4602: Overview of the F5 security vulnerability response policy
o K4918: Overview of the F5 critical issue hotfix policy
o K9502: BIG-IP hotfix and point release matrix
o K13123: Managing BIG-IP product hotfixes (11.x - 16.x)
o K48955220: Installing an OPSWAT Endpoint Security update on BIG-IP APM
systems (11.4.x and later)
o K167: Downloading software and firmware from F5
o K9970: Subscribing to email notifications regarding F5 products
o K9957: Creating a custom RSS feed to view new and updated documents
- --------------------------END INCLUDED TEXT--------------------
You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.
NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
https://www.auscert.org.au/bulletins/
===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072
Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967
iQIVAwUBYA4fPeNLKJtyKPYoAQhvjhAAmXdiGuGTPWyciVlHrnC1WP2NY2mpcX2+
+P2UAqwkcQYdYgbw0OXsMvT+AjnwcoynoLTYZbNeMZPiABeXaKaiW5iEcrAa9/om
AoJdXYF/eFHIToh+Q2gTUrw9KwaYrweazTqFTsBZPpI3shLwaAs7Y6bP1eLzRTpW
rljozXQIhttZP9tbeSSSxUcMGEHLvRNxpMLnoHXZtuLWHkikQBABcjw19KrhMIxV
7fpOzP9V42DgysGIuWnSQvXQpEsjzvl01/n67YHrMwouHaUz1O4fAShgwSnGH7Iq
MdamB9MqL8QHfwvyVz2ekdcAco/ZRvOPnyKZLi8OoCbk5CHZ1NMwGp4Xm8IlO6PP
CUYralnq9wxixZlAKzseHkQIpPNY5//DOwIaNRiwRxrP0KhMkjLl+5VR0qNjKR6g
EjDV9130tP+aSAOSpDu+FY82/aKNK9RJZBZcz8AsbH7/O60peZjdJ2NI9diApFKc
cFwOHJUHYI+2VcmYiAjUm8EcYP/oddbazccHNJPkihSuT8QQZJTRmC9H9S9lwibk
5WvunrltrXLgs7erzdXCm1CndegiViiH19hMEtVevoRVW0ORg29TAP+YGiqFQE1G
otBGIhQtJigGvEFNdJil1K+DiUlAg7GD/HN2JxF3+CBDE5xnD11e0wCnKjvrRa2P
PHx/BkOnKk8=
=f6/6
-----END PGP SIGNATURE-----