OpenBSD Journal

Patch your webservers! mod_rewrite patch

Contributed by sean on from the patching the apache dept.

Trevlig reminds us:
Patch your webservers! I was at first not really aware that this issue includes OpenBSD httpd.

From Secunias advisory: [SA21197] Apache mod_rewrite Off-By-One Buffer Overflow Vulnerability

The vulnerability is caused by a off-by-one error in mod_rewrite and
can be exploited to cause a one-byte buffer overflow.

Successful exploitation may crash the web server process or allow
execution of arbitrary code. However, this depends on the manner
which Apache HTTP Server was compiled and also requires the
following:
  • Certain types of Rewrite rules are used where the beginning of the rewritten URL is controlled.
  • The RewriteRule flags do not include the Forbidden (F), Gone (G),
    or NoEscape (NE) flag.

The vulnerability affects Apache 1.3 since 1.3.28, 2.0 since 2.0.46, and 2.2 since 2.2.0.

Patch is availble (link for 3.9 posted below):
ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.9/common/004_httpd.patch

(Comments are closed)

Comments

  1. By gwyllion (134.58.253.113) on

    From errata.html:

    httpd(8) 's mod_rewrite has a potentially exploitable off-by-one buffer overflow. The buffer overflow may result in a vulnerability which, in combination with certain types of Rewrite rules in the web server configuration files, could be triggered remotely. The default install is not affected by the buffer overflow. CVE-2006-3747

    Comments

    1. By Anonymous Coward (84.62.37.118) on

      > From errata.html:
      >
      > httpd(8) 's mod_rewrite has a potentially exploitable off-by-one buffer overflow. The buffer overflow may result in a vulnerability which, in combination with certain types of Rewrite rules in the web server configuration files, could be triggered remotely. The default install is not affected by the buffer overflow. CVE-2006-3747

      yes, that's right. but if you start httpd and use certain rewrite rules, you are caught. to avoid this, use the patch :)

      Comments

      1. By Anonymous Coward (87.78.88.170) on

        > > From errata.html:
        > >
        > > httpd(8) 's mod_rewrite has a potentially exploitable off-by-one buffer overflow. The buffer overflow may result in a vulnerability which, in combination with certain types of Rewrite rules in the web server configuration files, could be triggered remotely. The default install is not affected by the buffer overflow. CVE-2006-3747
        >
        > yes, that's right. but if you start httpd and use certain rewrite rules, you are caught. to avoid this, use the patch :)

        to use rewrite rules, you have to enable mod_rewrite in your httpd.conf.
        default install has that option disabled.

  2. By Anonymous Coward (65.15.132.19) on

    An outside security scanning company that my company is forced to use has been pushing that I start using mod_rewrite to fix an http_trace issue that they are finding. So far I have resisted because of just such an occurance as this. The reading I have done into the http_trace issue suggests that it is a non-issue and shouldn't be worried about. Does anyone have any thoughts on this that will educate and overworked new sys-admin.

    ps. I go with OpenBSD for ANYTHING I attach to the Internet, it's the only way I can sleep at night. A special thanks to the people who make it all happen.

    Comments

    1. By tedu (69.12.168.114) on

      > An outside security scanning company that my company is forced to use has been pushing that I start using mod_rewrite to fix an http_trace issue that they are finding. So far I have resisted because of just such an occurance as this. The reading I have done into the http_trace issue suggests that it is a non-issue and shouldn't be worried about. Does anyone have any thoughts on this that will educate and overworked new sys-admin.

      are you talking about the trace code that was disabled 8 months ago?
      http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/src/main/http_protocol.c

      Comments

      1. By Anonymous Coward (65.15.132.19) on

        > > An outside security scanning company that my company is forced to use has been pushing that I start using mod_rewrite to fix an http_trace issue that they are finding. So far I have resisted because of just such an occurance as this. The reading I have done into the http_trace issue suggests that it is a non-issue and shouldn't be worried about. Does anyone have any thoughts on this that will educate and overworked new sys-admin.
        >
        > are you talking about the trace code that was disabled 8 months ago?
        > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/src/main/http_protocol.c

        Yes, I have an older box that is awaiting an upgrade to 3.9. I guess I should work a few extra hours this weekend and get that done.

        Comments

        1. By Anonymous Coward (87.78.88.170) on

          > > > An outside security scanning company that my company is forced to use has been pushing that I start using mod_rewrite to fix an http_trace issue that they are finding. So far I have resisted because of just such an occurance as this. The reading I have done into the http_trace issue suggests that it is a non-issue and shouldn't be worried about. Does anyone have any thoughts on this that will educate and overworked new sys-admin.
          > >
          > > are you talking about the trace code that was disabled 8 months ago?
          > > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/src/main/http_protocol.c
          >
          > Yes, I have an older box that is awaiting an upgrade to 3.9. I guess I should work a few extra hours this weekend and get that done.

          way to go!

  3. By Shane (72.166.150.37) scastle@co.boulder.co.us on

    It would help if the patch was posted to the 3.9 errata page.

    Comments

    1. By Shane (72.166.150.37) on

      > It would help if the patch was posted to the 3.9 errata page.

      Never mind! (web caches can be so annoying)

  4. By sunny (63.81.254.99) on

    I'd have to say this answers the critics of speed of patches. I saw the commit message in the cvs logs last week, so the paranoid could have patched even earlier.

    Maybe what we need is a donation drive to assist the creation of the high profile latest packages ie Firefox. Don't get me wrong, I'm not whining, but if it were like it was to get some developer a current Mac a while ago, by getting movement by donation, I'm in.

    Comments

    1. By Anonymous Coward (87.78.88.170) on

      > I'd have to say this answers the critics of speed of patches. I saw the commit message in the cvs logs last week, so the paranoid could have patched even earlier.
      >
      > Maybe what we need is a donation drive to assist the creation of the high profile latest packages ie Firefox. Don't get me wrong, I'm not whining, but if it were like it was to get some developer a current Mac a while ago, by getting movement by donation, I'm in.

      OK, Firefox it is:

      - Release of 1.5.0.5 was on 2006-07-27.
      - bernd@ (Danke!) commited the update to the port on 2006-07-31.

      I think that's a good timeframe if you consider the time it takes to port the changes and nessasary time for testing-reports to get back to him.
      (Don't have to mention the RL-factor in this equation.. Over the weekend between (possibly) being drunk and cuddling it's very respectable work.)

      Comments

      1. By Anonymous Coward (62.141.24.73) on

        get systrace work with firefox and you can be more safe with buggy browser :) am i right?

        > OK, Firefox it is:
        >
        > - Release of 1.5.0.5 was on 2006-07-27.
        > - bernd@ (Danke!) commited the update to the port on 2006-07-31.
        >
        > I think that's a good timeframe if you consider the time it takes to port the changes and nessasary time for testing-reports to get back to him.
        > (Don't have to mention the RL-factor in this equation.. Over the weekend between (possibly) being drunk and cuddling it's very respectable work.)
        >

        Comments

        1. By Anonymous Coward (66.39.191.42) on

          > get systrace work with firefox and you can be more safe with buggy browser :) am i right?
          >

          Possibly. Firefox probably requires access to quite a bit of your system, especially for features like being able to browse through your local directory tree and upload files and for many other parts of the browser. I'm sure that creating a systrace file for it wouldn't be terribly useful unless you were willing to live with more limited browser functionality.

  5. By Jim (198.62.124.245) on

    If it's good enough for undeadly, it's good enough for me!

    Comments

    1. By Anonymous Coward (87.78.88.170) on

      > If it's good enough for undeadly, it's good enough for me!

      as with any community driven projects, keep the submissions comming!

    2. By Anonymous Coward (70.27.15.123) on

      > If it's good enough for undeadly, it's good enough for me!

      That's a pretty dumb statement if you think about it. This error is in mod_rewrite, which is a very complex module. If thttpd (which has nothing like mod_rewrite) meets your needs, then you wouldn't have to worry about this using apache either, since you wouldn't be using mod_rewrite.

    3. By Anonymous Coward (62.252.32.11) on

      > If it's good enough for undeadly, it's good enough for me!

      lighttpd.net is also something worth looking into!

      Comments

      1. By Anonymous Coward (24.46.21.229) on

        > > If it's good enough for undeadly, it's good enough for me!
        >
        > lighttpd.net is also something worth looking into!
        >

        I couldn't agree more; I was using both apache & thttpd here for the business ( apache for pages/cgi/apps, thttpd for static content & internal crap). I must say that I am rather impressed with lighttpd; rather easy to configure FastCGI w/ PHP, decent VHOST & Rewrites, lightweight, fast & slick. Def. worth a try

        Comments

        1. By Anonymous Coward (66.11.66.41) on

          > I couldn't agree more; I was using both apache & thttpd here for the business ( apache for pages/cgi/apps, thttpd for static content & internal crap). I must say that I am rather impressed with lighttpd; rather easy to configure FastCGI w/ PHP, decent VHOST & Rewrites, lightweight, fast & slick. Def. worth a try

          Plus, its had quite a few security problems, a few of which have been VERY basic stupid things. And as an added bonus, the authors like to fix things like buffer overflows without mentioning them to users. I guess "security" means "hiding our security holes" to them.

          Comments

          1. By SH (82.182.103.172) on

            > > I couldn't agree more; I was using both apache & thttpd here for the business ( apache for pages/cgi/apps, thttpd for static content & internal crap). I must say that I am rather impressed with lighttpd; rather easy to configure FastCGI w/ PHP, decent VHOST & Rewrites, lightweight, fast & slick. Def. worth a try
            >
            > Plus, its had quite a few security problems, a few of which have been VERY basic stupid things. And as an added bonus, the authors like to fix things like buffer overflows without mentioning them to users. I guess "security" means "hiding our security holes" to them.

            Ypu have any references to this?

            Comments

            1. By Anonymous Coward (66.11.66.41) on

              > > Plus, its had quite a few security problems, a few of which have been VERY basic stupid things. And as an added bonus, the authors like to fix things like buffer overflows without mentioning them to users. I guess "security" means "hiding our security holes" to them.
              >
              > Ypu have any references to this?

              Which part, the really obviously stupid security holes:
              http://lighttpd.net/news/

              Or the fixing overflows without bothering to tell anyone:
              http://trac.lighttpd.net/trac/changeset/871

    4. By Anonymous Coward (213.118.74.206) on

      > If it's good enough for undeadly, it's good enough for me!

      thttpd is, in my opinion, a better choice than Apache for static content: the main pages of your website, images, ...

      On the other hand, Apache has some advantages for the dynamic content (forking CGI's is slow...), as well as being much more flexible (although unavoidably much more complex aswell).

      They each have their place. So use them both!

      Comments

      1. By Anonymous Coward (24.46.21.20) on

        > > If it's good enough for undeadly, it's good enough for me!
        >
        > thttpd is, in my opinion, a better choice than Apache for static content: the main pages of your website, images, ...
        >
        > On the other hand, Apache has some advantages for the dynamic content (forking CGI's is slow...), as well as being much more flexible (although unavoidably much more complex aswell).
        >
        > They each have their place. So use them both!
        >
        It would be nice however if thttpd has a decent FastCGI/SCGI implementation... it's been on my todo list, but alas that is five miles long

  6. By Anonymous Coward (85.178.72.81) on

    Maybe this gives Henning another argument to make something with his openhttpd.org-Domain? :-)

    I know developers are rare but investing the time to realy check out/clean/expand the current "apache"-src (and renaming it? a domain would be avaiable ;-)) ) would maybe something good?
    Then we wouldn`t be "that" affected by those Apache-Bugs.

    Let me remind OpenSSH wich wasn`t Bug free too but we didn`t got some issues other vendors had. But SSH has another priority. ;-)


    Keep up posting such stuff (and maybe even informing the community earlier) :-)

    Comments

    1. By Chris (194.193.52.253) chriswareham@chriswareham.demon.co.uk on http://www.chriswareham.demon.co.uk/

      > Maybe this gives Henning another argument to make something with his openhttpd.org-Domain? :-)
      >

      Rather than rework Apache, maybe a cleaner HTTPD daemon could be written specifically for OpenBSD. Ports to other systems could then be handled in the same way as OpenSSH, while the core remains clean of much of the gloop that enables Apache to be portable. Many of the Apache modules are of limited use to most people, so a reasonable userbase could be established amongst those users without having to support every feature of Apache straight away. For instance, many people use Apache as a simple proxy to another machine running a Java web container. OpenBSD would be a great solution for the web proxies, which typically sit in the DMZ and forward requests over a single port to the web container machines that sit behind a second firewall.

      Chris

      Comments

      1. By Anonymous Coward (85.178.90.189) on

        > > Maybe this gives Henning another argument to make something with his openhttpd.org-Domain? :-)
        > >
        >
        > Rather than rework Apache, maybe a cleaner HTTPD daemon could be written specifically for OpenBSD. Ports to other systems could then be handled in the same way as OpenSSH, while the core remains clean of much of the gloop that enables Apache to be portable. Many of the Apache modules are of limited use to most people, so a reasonable userbase could be established amongst those users without having to support every feature of Apache straight away. For instance, many people use Apache as a simple proxy to another machine running a Java web container. OpenBSD would be a great solution for the web proxies, which typically sit in the DMZ and forward requests over a single port to the web container machines that sit behind a second firewall.
        >
        > Chris

        Well with a cleaner httpD you get also some troubles.
        Sure you could include stuff like the apache mod_gzip so that the server provides it by default but some users also use mod_perl and php...
        Cleaning up Apache may provide the advantage that existing modules don`t have to get changed to work on the new Daemon (everythign is totaly in theory).

        I personaly use the OpenBSD httpD as simple Webserver for my xhtmls but I know guys using oBSD and also PHP/mod_perl.
        This may cover the needs of ~90% of the peoples. *my oppinion*

        Sure a new httpD would be smaler, much better (cleaner code) but it also needs more manpower.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]