8 ms·

Optionsbleed – HTTP OPTIONS method can leak Apache's server memory

142 points by hannob 9y ago

inetknght 9y ago
> Does it have a CVE? > CVE-2017-9798. -> https://nvd.nist.gov/vuln/detail/CVE-2017-9798 https://nvd.nist.gov/vuln/detail/CVE-2017-9798 The CVE is still in RESERVED state. I'm frequently concerned about "responsible disclosure" in such cases.
- hannob 9y ago
  It's normal that CVEs aren't filled directly after a disclosure. Takes some time till the database gets updated. Not sure how that makes you concerned about responsible disclosure. As you can read in the bug report the apache security team was informed (actually it was one of their devs figuring out the details of the bug, I just saw it "in the wild", but at first was unable to reproduce it locally). I had also informed the distros mailing list a week in advance. I'm aware responsible disclosure is a weakly defined term, but if you have any concerns that I did something irresponsible I'd like to know.
  - inetknght 9y ago
    In my mind (biased) responsible disclosure includes ensuring that a respected database for tracking security issues has the issue described and publicly available either before or at the same time that a blog publicly discusses it. Otherwise the impression is that the blog is discussing a security issue before it's been addressed by interested parties. That's just my opinion. Whether or not that's the "definition" of responsibility is of course up for discussion.
    - patcheudor 9y ago
      I've got two and three year old vulnerabilities I've disclosed which have CVE's which are still not populated. This is very common. No one waits for the CVE to be populated before going public.
      - inetknght 9y ago
        I understand and that's quite unfortunate. Nonetheless, my opinion is my own and I see nothing to change it so far.
        justinclift 9y ago
        The delay seems like it's caused by the people who update the database just not having the time to get it done. Or alternatively, just not prioritising it for the time they have. Either way of looking at it, delaying release of vuln info to wait for the above to happen seems like it would let vulns keep in-the-wild-and-unknown for much longer. That being said, if you're able to assist with or fix the not-enough-time-to-get-things-done problem, it wouldn't hurt. :)
ericfrederich 9y ago
1997 called... it wants its http server back?
kodfodrasz 9y ago
Is anybody still using Apache? I'm really iterested on the whys (in addition to the obvious legacy reasons).
- tyingq 9y ago
  One driver is popular software that depends on the .htaccess construct. WordPress, for example. It can run on other servers, but their own docs call out the issue..."Since Nginx does not have .htaccess-type capability and WordPress cannot automatically modify the server configuration for you, it cannot generate the rewrite rules for you"
  - pmlnr 9y ago
    ... and this is why WP has it's own rewrite engine, which works perfectly with nginx.
    - tyingq 9y ago
      The quoted text is from their docs, and does not read that way. Some more: "With Nginx there is no directory-level configuration file like Apache's .htaccess or IIS's web.config files. All configuration has to be done at the server level by an administrator, and WordPress cannot modify the configuration, like it can with Apache or IIS"
      - pmlnr 9y ago
        https://codex.wordpress.org/Rewrite_API https://codex.wordpress.org/Rewrite_API What you are saying is, on it's own, true. It's also a solved problem for WP.
        solnyshok 9y ago
        does it work with all plugins too?
        9y ago
pmlnr 9y ago
I'm astonished how many shared hosting provider still using apache 2.4. Yes, there are a few things apache is remarkable about - the npm-itk engine could run as user processes, which was nice for shared hosting - but all the problems with it - slowloris, anyone? - simply outweights the benefits. Shared hosting should be containerised or vm-ised instead and run on nginx/lighttpd/cherookee/etc + php-fpm 7.0 which will save you a lot of headaches and CPU cycles. .htaccess can be just as much a benefit as a curse. (Note: WordPress is completely nginx + php-fpm friendly.)
- toomuchtodo 9y ago
  Lots of shared hosting uses tooling like cPanel shared hosting automation, which if I recall is still defaulting to Apache. Nginx is surely the first choice if you're rolling your own shared hosting infrastructure, but most legacy commercial shared hosting automation frameworks still use Apache and customers don't care what the underlying tech is serving their bits over HTTP.
- jimjag 9y ago
  "all the problems" are really old, old news, long ago addressed and resolved. In fact, such statements are more FUD than anything else. Certainly you MUST know that Apache httpd supports PHP-FPM, for example.
  - user5994461 9y ago
    The old problems are not solved and not resolved at all. I am working on a critical apache setup at the moment and the software is rigged with weird corner cases and bugs. This shit doesn't happen with haproxy and nginx.
    - stephenr 9y ago
      You know you can use HAProxy with apache too right? I never understand these arguments that basically pit Apache2 on its own/with modules against a completely modular arrangement of tls/cache/web/app as different layers. If you use apache as the "web" in that setup, it needs relatively few modules loaded and when configured correctly can be blazing fast.
wielebny 9y ago
I was able to reproduce this issue on Apache 2.2.22 with a legitimate method: <LIMIT GET> Allow from x.y.z.v Deny from all </LIMIT> for I in `seq 1 100`; do curl -sI -X OPTIONS http://myhost/ | grep ^Allow; done | uniq Allow: ,GET,HEAD,POST,OPTIONS Allow: GET,HEAD,POST,OPTIONS Allow: ,GET,HEAD,POST,OPTIONS Allow: GET,HEAD,POST,OPTIONS
- abjorn 9y ago
  This doesn't quite look like the same bug described in the article. Maybe the inconsistency with the comma separator is a separate bug?
  - wielebny 9y ago
    Most certainly something is leaking: l-lbiegaj ~ -> curl -sI -X OPTIONS http://mysite/ | grep ^Allow Allow: allow,HEAD,GET,HEAD,POST,OPTIONS Value returned in 'Allow' changes with every apache2 restart, but I haven't yet seen any parts of the config or something other than extraneous commans or 'allow' string.
    - justinclift 9y ago
      Interesting. Maybe see if it still leaks with the patch jimjag points out below? http://svn.apache.org/viewvc?view=revision&revision=1807754 http://svn.apache.org/viewvc?view=revision&revision=1807754
  - wielebny 9y ago
    After many repeated tests with multiple LIMIT sections in .htaccess (and without restarting apache2) i've managed to get a leak of part of config file: Allow: �E2�~,HEAD,,ex.html/,OPTIONS,POST,,HEAD,,HEAD,Pek�~,HEAD,,,ex.html/,GET,HEAD
jimjag 9y ago
Those interested in patching their local machines, while 2.4.28 is being buttoned-up, review the following link: http://svn.apache.org/viewvc?view=revision&revision=1807754 http://svn.apache.org/viewvc?view=revision&revision=1807754
mikeash 9y ago
For those who come straight to the comments, it should be noted that most Apache installs won't be affected and this is a relatively low-impact vulnerability, although for those who are affected it could be pretty bad. The flaw only occurs if you have a "Limit" configuration that specifies an invalid HTTP method. For some unknown reason, this causes the leak. A "Limit" with a valid method, or no "Limit" at all, will not provoke the bug. I have to imagine that most Apache setups either don't configure this or configure it only with valid methods. The article points out that shared hosting setups which allow individual users to customize settings through .htaccess would be vulnerable, since anyone on the machine could set an invalid configuration and then use the vulnerability to potentially get data from other users. Obviously you should patch it when you can, but it is probably not time for most of us to panic.
deleted 9y ago
[deleted]
shiftoutbox 9y ago
STOP USING STUPID NAMES FOR EACH EXPLOIT
ibnesayeed 9y ago
I will leave here the link of our 2014 paper, "Support for Various HTTP Methods on the Web" (https://arxiv.org/pdf/1405.2330.pdf https://arxiv.org/pdf/1405.2330.pdf) for the reference. The issue is described in section 5.3 of the paper.

142 points by hannob 9y ago

> Does it have a CVE? > CVE-2017-9798. -> https://nvd.nist.gov/vuln/detail/CVE-2017-9798 https://nvd.nist.gov/vuln/detail/CVE-2017-9798 The CVE is still in RESERVED state. I'm frequently concerned about "responsible disclosure" in such cases.

hannob 9y ago
It's normal that CVEs aren't filled directly after a disclosure. Takes some time till the database gets updated. Not sure how that makes you concerned about responsible disclosure. As you can read in the bug report the apache security team was informed (actually it was one of their devs figuring out the details of the bug, I just saw it "in the wild", but at first was unable to reproduce it locally). I had also informed the distros mailing list a week in advance. I'm aware responsible disclosure is a weakly defined term, but if you have any concerns that I did something irresponsible I'd like to know.
- inetknght 9y ago
  In my mind (biased) responsible disclosure includes ensuring that a respected database for tracking security issues has the issue described and publicly available either before or at the same time that a blog publicly discusses it. Otherwise the impression is that the blog is discussing a security issue before it's been addressed by interested parties. That's just my opinion. Whether or not that's the "definition" of responsibility is of course up for discussion.
  - patcheudor 9y ago
    I've got two and three year old vulnerabilities I've disclosed which have CVE's which are still not populated. This is very common. No one waits for the CVE to be populated before going public.
    - inetknght 9y ago
      I understand and that's quite unfortunate. Nonetheless, my opinion is my own and I see nothing to change it so far.
      - justinclift 9y ago
        The delay seems like it's caused by the people who update the database just not having the time to get it done. Or alternatively, just not prioritising it for the time they have. Either way of looking at it, delaying release of vuln info to wait for the above to happen seems like it would let vulns keep in-the-wild-and-unknown for much longer. That being said, if you're able to assist with or fix the not-enough-time-to-get-things-done problem, it wouldn't hurt. :)

ericfrederich 9y ago

1997 called... it wants its http server back?

kodfodrasz 9y ago

Is anybody still using Apache? I'm really iterested on the whys (in addition to the obvious legacy reasons).

tyingq 9y ago
One driver is popular software that depends on the .htaccess construct. WordPress, for example. It can run on other servers, but their own docs call out the issue..."Since Nginx does not have .htaccess-type capability and WordPress cannot automatically modify the server configuration for you, it cannot generate the rewrite rules for you"
- pmlnr 9y ago
  ... and this is why WP has it's own rewrite engine, which works perfectly with nginx.
  - tyingq 9y ago
    The quoted text is from their docs, and does not read that way. Some more: "With Nginx there is no directory-level configuration file like Apache's .htaccess or IIS's web.config files. All configuration has to be done at the server level by an administrator, and WordPress cannot modify the configuration, like it can with Apache or IIS"
    - pmlnr 9y ago
      https://codex.wordpress.org/Rewrite_API https://codex.wordpress.org/Rewrite_API What you are saying is, on it's own, true. It's also a solved problem for WP.
      - solnyshok 9y ago
        does it work with all plugins too?
        9y ago

pmlnr 9y ago

I'm astonished how many shared hosting provider still using apache 2.4. Yes, there are a few things apache is remarkable about - the npm-itk engine could run as user processes, which was nice for shared hosting - but all the problems with it - slowloris, anyone? - simply outweights the benefits. Shared hosting should be containerised or vm-ised instead and run on nginx/lighttpd/cherookee/etc + php-fpm 7.0 which will save you a lot of headaches and CPU cycles. .htaccess can be just as much a benefit as a curse. (Note: WordPress is completely nginx + php-fpm friendly.)

toomuchtodo 9y ago
Lots of shared hosting uses tooling like cPanel shared hosting automation, which if I recall is still defaulting to Apache. Nginx is surely the first choice if you're rolling your own shared hosting infrastructure, but most legacy commercial shared hosting automation frameworks still use Apache and customers don't care what the underlying tech is serving their bits over HTTP.
jimjag 9y ago
"all the problems" are really old, old news, long ago addressed and resolved. In fact, such statements are more FUD than anything else. Certainly you MUST know that Apache httpd supports PHP-FPM, for example.
- user5994461 9y ago
  The old problems are not solved and not resolved at all. I am working on a critical apache setup at the moment and the software is rigged with weird corner cases and bugs. This shit doesn't happen with haproxy and nginx.
  - stephenr 9y ago
    You know you can use HAProxy with apache too right? I never understand these arguments that basically pit Apache2 on its own/with modules against a completely modular arrangement of tls/cache/web/app as different layers. If you use apache as the "web" in that setup, it needs relatively few modules loaded and when configured correctly can be blazing fast.

wielebny 9y ago

I was able to reproduce this issue on Apache 2.2.22 with a legitimate method: <LIMIT GET> Allow from x.y.z.v Deny from all </LIMIT> for I in `seq 1 100`; do curl -sI -X OPTIONS http://myhost/ | grep ^Allow; done | uniq Allow: ,GET,HEAD,POST,OPTIONS Allow: GET,HEAD,POST,OPTIONS Allow: ,GET,HEAD,POST,OPTIONS Allow: GET,HEAD,POST,OPTIONS

abjorn 9y ago
This doesn't quite look like the same bug described in the article. Maybe the inconsistency with the comma separator is a separate bug?
- wielebny 9y ago
  Most certainly something is leaking: l-lbiegaj ~ -> curl -sI -X OPTIONS http://mysite/ | grep ^Allow Allow: allow,HEAD,GET,HEAD,POST,OPTIONS Value returned in 'Allow' changes with every apache2 restart, but I haven't yet seen any parts of the config or something other than extraneous commans or 'allow' string.
  - justinclift 9y ago
    Interesting. Maybe see if it still leaks with the patch jimjag points out below? http://svn.apache.org/viewvc?view=revision&revision=1807754 http://svn.apache.org/viewvc?view=revision&revision=1807754
- wielebny 9y ago
  After many repeated tests with multiple LIMIT sections in .htaccess (and without restarting apache2) i've managed to get a leak of part of config file: Allow: �E2�~,HEAD,,ex.html/,OPTIONS,POST,,HEAD,,HEAD,Pek�~,HEAD,,,ex.html/,GET,HEAD

jimjag 9y ago

Those interested in patching their local machines, while 2.4.28 is being buttoned-up, review the following link: http://svn.apache.org/viewvc?view=revision&revision=1807754 http://svn.apache.org/viewvc?view=revision&revision=1807754

mikeash 9y ago

For those who come straight to the comments, it should be noted that most Apache installs won't be affected and this is a relatively low-impact vulnerability, although for those who are affected it could be pretty bad. The flaw only occurs if you have a "Limit" configuration that specifies an invalid HTTP method. For some unknown reason, this causes the leak. A "Limit" with a valid method, or no "Limit" at all, will not provoke the bug. I have to imagine that most Apache setups either don't configure this or configure it only with valid methods. The article points out that shared hosting setups which allow individual users to customize settings through .htaccess would be vulnerable, since anyone on the machine could set an invalid configuration and then use the vulnerability to potentially get data from other users. Obviously you should patch it when you can, but it is probably not time for most of us to panic.

deleted 9y ago

[deleted]

shiftoutbox 9y ago

STOP USING STUPID NAMES FOR EACH EXPLOIT

ibnesayeed 9y ago

I will leave here the link of our 2014 paper, "Support for Various HTTP Methods on the Web" (https://arxiv.org/pdf/1405.2330.pdf https://arxiv.org/pdf/1405.2330.pdf) for the reference. The issue is described in section 5.3 of the paper.