Bug 1490344 - (CVE-2017-9798, Optionsbleed) CVE-2017-9798 httpd: Use-after-free by limiting unregistered HTTP method (Optionsbleed)
CVE-2017-9798 httpd: Use-after-free by limiting unregistered HTTP method (Opt...
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20170918,repor...
: Security
Depends On: 1491674 1492886 1493060 1493065 1490947 1491675 1491676 1493061 1493064 1508877 1510060 1510061 1510062
Blocks: 1509003 1490345 1507692 1513244 1524240
  Show dependency treegraph
 
Reported: 2017-09-11 07:46 EDT by Andrej Nemec
Modified: 2017-12-15 17:37 EST (History)
54 users (show)

See Also:
Fixed In Version: httpd 2.4.28, httpd 2.2.35
Doc Type: If docs needed, set a value
Doc Text:
A use-after-free flaw was found in the way httpd handled invalid and previously unregistered HTTP methods specified in the Limit directive used in an .htaccess file. A remote attacker could possibly use this flaw to disclose portions of the server memory, or cause httpd child process to crash.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrej Nemec 2017-09-11 07:46:03 EDT
A use-after free vulnerability was found in apache httpd. There's an apache configuration directive <Limit> that can be used to restrict access to certain HTTP methods. If one sets this inside an .htaccess file with an HTTP method that's not registered in the server the bug happens (e.g. set <Limit INVALID></Limit> in .htaccess). The reason is that at that point the variables used to build up the "Allow" header have already been freed, as it's not expecting any more changes to it.

Note that the bug only appears with OPTIONS requests to a specific path, not with "*" OPTIONS requests.

An attacker on a shared hosting could could deliberately create an .htaccess file triggering the bug and subsequently try to exfiltrate data pieces from the global apache process that may contain secrets like password hashes.

Upstream patch:

https://svn.apache.org/viewvc?view=revision&revision=1807754
Comment 1 Andrej Nemec 2017-09-11 07:46:23 EDT
Acknowledgments:

Name: Hanno Böck
Comment 7 Adam Mariš 2017-09-18 16:58:03 EDT
Created httpd tracking bugs for this issue:

Affects: fedora-all [bug 1492886]
Comment 11 Stefan Cornelius 2017-09-19 06:11:27 EDT
Statement:

This issue affects the versions of httpd as shipped with Red Hat Enterprise Linux 5, 6, and 7. This issue affects the versions of httpd24-httpd as shipped with Red Hat Software Collections. Product Security has rated this issue as having Moderate security impact.

In order to be vulnerable, .htaccess files need to contain an invalid or not globally registered HTTP method in a "Limit" directive.
Comment 14 Tomas Hoger 2017-09-19 08:39:11 EDT
The original reporter decided to brand this vulnerability and named it "Optionsbleed".
Comment 15 Tomas Hoger 2017-09-19 08:44:32 EDT
The original reporter also made a test script for this issue publicly available:

https://github.com/hannob/optionsbleed
Comment 18 Tomas Hoger 2017-09-19 09:29:52 EDT
As previously noted, this flaw may affect configurations where <Limit> or <LimitExcept> directives are used in .htaccess file (the file name depends on the AccessFileName setting, .htaccess is the default name).  The problem occurs when the specified HTTP method or methods are invalid or not already registered via global configuration.

This problem can be avoided by moving the required <Limit> and <LimitExcept> configuration directives to the global configuration file.

The httpd server may be configured to allow non-administrative users to alter httpd configuration for certain directories via .htaccess files.  Configuration directives that can be used in .htaccess are controlled via AllowOverride directive (and in httpd 2.4 further refined by AllowOverrideList) specified in a <Directory> section.  The ability to use <Limit> is granted via 'AllowOverride Limit' or 'AllowOverride All'.  If httpd needs to serve content from users that are not fully trusted, either use 'AllowOverride None' or explicitly specify directive types other than Limit which should be accessible to users.  Consult the httpd manual for further information about the AllowOverride configuration directive:

https://httpd.apache.org/docs/2.4/mod/core.html#allowoverride
https://httpd.apache.org/docs/2.2/mod/core.html#allowoverride

Note that there's a difference in the default value of AllowOverride between httpd versions 2.2 and 2.4.  The default for 2.2 (and earlier) is All, while it's None for 2.4.

The default configuration of httpd packages as shipped in Red Hat Enterprise Linux 5, 6, and 7, and Red Hat Software Collections explicitly sets 'AllowOverride None' for all directories.  The only exception is for /home/*/public_html directories, where Limit is included in AllowOverride.  However, the UserDir feature is disabled by default, so that setting only becomes effective after changing the default of 'UserDir disabled' to 'UserDir public_html' as suggested by the example included in the packaged httpd configuration file.  In Red Hat Enterprise Linux 5 and 6, AllowOverride Limit setting for public_html directories is only include as commented-out example, that needs to be uncommented in addition to enabling UserDir to make it effective.
Comment 24 Jeroen van Meeuwen 2017-09-21 13:26:32 EDT
This affects deployments of Red Hat Enterprise Linux 5, 6 and 7, as well as Fedora 24, 25, 26, 27 and Rawhide, that employ any of a long list of supplemental management system for "hosting", or DIY'd their situation with an FTP DocumentRoot.
Comment 25 Fedora Update System 2017-09-22 14:52:37 EDT
httpd-2.4.27-3.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
Comment 26 Stefan Cornelius 2017-09-25 08:57:55 EDT
Mitigation:

This issue can be mitigated by configuring httpd to disallow the use of the "Limit" configuration directive in .htaccess files. The set of directives that can be used in .htaccess files is configured using the "AllowOverride" directive. Refer to Red Hat Bugzilla bug 1490344 for further details:
https://bugzilla.redhat.com/show_bug.cgi?id=1490344#c18
Comment 28 Fedora Update System 2017-09-30 02:47:30 EDT
httpd-2.4.27-8.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
Comment 29 errata-xmlrpc 2017-10-11 11:58:50 EDT
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2017:2882 https://access.redhat.com/errata/RHSA-2017:2882
Comment 30 ownodastgfree 2017-10-13 03:59:49 EDT
Hi,

Based on my checking on rhel support website, there is no httpd 2.4.28 version available. The latest one is httpd-2.4.6-67.el7_4.5.x86_64. Kindly please advise. Thank you .
Comment 31 Clifford Perry 2017-10-13 05:39:29 EDT
(In reply to ownodastgfree from comment #30)
> Hi,
> 
> Based on my checking on rhel support website, there is no httpd 2.4.28
> version available. The latest one is httpd-2.4.6-67.el7_4.5.x86_64. Kindly
> please advise. Thank you .

Hi, please monitor:

https://access.redhat.com/security/cve/CVE-2017-9798

We have already released fixed packages for RHEL 7
 - https://access.redhat.com/errata/RHSA-2017:2882
 - httpd-2.4.6-67.el7_4.5

Red Hat does not rebase to newer versions to fix, instead we will backport the fix into our supported products. More information on this can be found here - https://access.redhat.com/security/updates/backporting

IF you have further questions, please do contact us directly at secalert@redhat.com 

Regards,
Cliff
Comment 32 Leon Fauster 2017-10-13 10:43:14 EDT
What about RHEL 6?
Comment 34 errata-xmlrpc 2017-10-19 11:27:32 EDT
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2017:2972 https://access.redhat.com/errata/RHSA-2017:2972
Comment 35 Chris Kottaridis 2017-10-19 12:26:34 EDT
Is this the appropriate place to ask about availability of Apache 2.4.28 for Fedora 25 ? If so when will Apache 2.4.28 be available for Fedora 25 ?
Comment 36 Greg Smith 2017-10-19 20:34:58 EDT
I see that Red Hat JBoss EWS 2 is Affected, is their a way to track the progress of that patch or do I just have to keep monitoring the primary CVE page? https://access.redhat.com/security/cve/cve-2017-9798

I wasn't entirely sure how to keep up with JBoss EWS 2 patches.
Comment 37 Wade Mealing 2017-10-20 00:48:11 EDT
Gday Greg,

Product Security does not actively watch this as a support forum (and thefore has no SLA, if you need a response please contact The Red Hat Support team)

But you can log into the portal, then visit:

https://access.redhat.com/security/security-updates/#/security-advisories

Click on "Notification Preferences" and customize it to your needs.  You may need to do additional filtering on your client to cut down what you dont need.

Thanks,

Wade Mealing
Red Hat Product Security (Kernel)
Comment 39 errata-xmlrpc 2017-10-24 05:51:19 EDT
This issue has been addressed in the following products:

  Red Hat Software Collections for Red Hat Enterprise Linux 7
  Red Hat Software Collections for Red Hat Enterprise Linux 7.3 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 6
  Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7.4 EUS

Via RHSA-2017:3018 https://access.redhat.com/errata/RHSA-2017:3018
Comment 40 errata-xmlrpc 2017-11-02 15:08:14 EDT
This issue has been addressed in the following products:

  Red Hat JBoss Web Server

Via RHSA-2017:3114 https://access.redhat.com/errata/RHSA-2017:3114
Comment 41 errata-xmlrpc 2017-11-02 15:17:18 EDT
This issue has been addressed in the following products:

  Red Hat JBoss Enterprise Web Server 2 for RHEL 6
  Red Hat JBoss Enterprise Web Server 2 for RHEL 7

Via RHSA-2017:3113 https://access.redhat.com/errata/RHSA-2017:3113
Comment 44 errata-xmlrpc 2017-11-13 12:38:10 EST
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7.2 Extended Update Support

Via RHSA-2017:3193 https://access.redhat.com/errata/RHSA-2017:3193
Comment 45 errata-xmlrpc 2017-11-13 12:40:01 EST
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6.7 Extended Update Support

Via RHSA-2017:3195 https://access.redhat.com/errata/RHSA-2017:3195
Comment 46 errata-xmlrpc 2017-11-13 12:42:02 EST
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7.3 Extended Update Support

Via RHSA-2017:3194 https://access.redhat.com/errata/RHSA-2017:3194
Comment 47 errata-xmlrpc 2017-11-16 14:11:17 EST
This issue has been addressed in the following products:

  Red Hat JBoss Enterprise Application Platform

Via RHSA-2017:3239 https://access.redhat.com/errata/RHSA-2017:3239
Comment 48 errata-xmlrpc 2017-11-16 14:28:53 EST
This issue has been addressed in the following products:

  Red Hat JBoss Enterprise Application Platform 6.4 for RHEL 6
  Red Hat JBoss Enterprise Application Platform 6.4 for RHEL 7

Via RHSA-2017:3240 https://access.redhat.com/errata/RHSA-2017:3240
Comment 49 errata-xmlrpc 2017-12-15 17:24:25 EST
This issue has been addressed in the following products:

  Red Hat JBoss Core Services

Via RHSA-2017:3475 https://access.redhat.com/errata/RHSA-2017:3475
Comment 50 errata-xmlrpc 2017-12-15 17:36:00 EST
This issue has been addressed in the following products:

  JBoss Core Services on RHEL 7

Via RHSA-2017:3476 https://access.redhat.com/errata/RHSA-2017:3476
Comment 51 errata-xmlrpc 2017-12-15 17:37:42 EST
This issue has been addressed in the following products:

  JBoss Core Services on RHEL 6

Via RHSA-2017:3477 https://access.redhat.com/errata/RHSA-2017:3477

Note You need to log in before you can comment on or make changes to this bug.