-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

===========================================================================
             AUSCERT External Security Bulletin Redistribution

                               ESB-2020.3149
       The BIG-IP system may not interpret an HTTP request the same
                  way the target web server interprets it
                             15 September 2020

===========================================================================

        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

- --------------------------BEGIN INCLUDED TEXT--------------------

K27551003:The BIG-IP system may not interpret an HTTP request the same way the 
target web server interprets it

Security Advisory

Original Publication Date: 24 Jun, 2020

Latest   Publication Date: 15 Sep, 2020

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) and you should evaluate how your application handles
        such white space.

        F5 has assigned ID858289 to the requirement to have an option to reject
        such requests within the BIG-IP LTM HTTP profile configuration.
         

       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                                |
+------------------+-----------------+----------------------------------------+
|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.                                  |
+--------+--------------------------------------------------------------------+
|15.0.1.1|The system database variable tmm.http.rfc.enforcement is available. |
|or later|To fix the issue described in this article, you must enable this    |
|14.1.2.4|database variable by entering the following command:                |
|or later|tmsh modify sys db tmm.http.rfc.enforcement value enable            |
+--------+--------------------------------------------------------------------+

Important: If either HTTP PSM or ASM are configured on a virtual server, the
state of the tmm.http.rfc.enforcement variable or 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

iQIVAwUBX1/s4eNLKJtyKPYoAQhY2w/+KRXiFFHnx6IBi3QW7//d0oREu6/KY5C7
QQI3G36Mmu+wKoadimHHZoly5VdRmszD2Swm6JIJB+L26HkNDhllK0ABDr44dQ5n
0lemzmbTDeITEhPncHlpf0KAJsQYCrHw2zvBhxYw00lms1qS6SDMD5COSLERF5aN
34H2KRZPIiuht7GwMERhBEHSd05khtLSp3RfOQGUhXWtkdjicbZA5rfeDkaiiZvn
CYYY/TU9faL4onu6E7DrwO4O7QUPLorLlUq7soymhkWTfGHg4hoQQPlUiooU9Yf9
iR9fTceD+cRCeDTm5mp1Waik/aEWOaJdGMUM15+rMhlFPrBAjJxhOC/7GF8xxlJg
Uw9XwQ5wJ1lRMYgmfrgMqfPlwIyItBC3IeTOjQtc5b+sZYsIa7yhFaN+qZwj/maf
FXIFCxS1dk1U/BtPyg7Iz0jk8cMf1ZLYPBag1/P4EXt1bkoUwnBXsOqNB5vxqjCr
TxjCq7EGe7GXjet+jh2u6vjO11/xMp1ssPb0ImKyjR7+6nfAhrmlIrxDrcxjfZlb
ozsZGRvD3jjvFTZtLwntN+p3ZF8pMEmtXhI5UzCCHHOnCK1aoPmjtc8vbQeNulKg
KYLX3ScykdvYh5QzuHeBCFvho14N+5wLhvsRePkTkBe0KpiIoILr8Aq3nTjXZ1JZ
cXffNCExMJc=
=EYJL
-----END PGP SIGNATURE-----