OpenBSD Journal

a Apache Security fix

Contributed by Dengue on from the errata dept.

You'd have to live under a rock to have missed the Apache chunked encoding vulnerability . Rock or not, Patch 005 has been released to correct the issue. From errata.html :
"A buffer overflow can occur during the interpretation of chunked encoding in the http daemon, leading to possible remote crash."
Many thanks to ViPER - DMRT for reminding me to post this.

(Comments are closed)

Comments

  1. By Anonymous Coward () on

    beware for the sploit released by GOBBLES on bugtraq@ and vuln-dev@

    Comments

    1. By Anonymous Coward () on

      Apache drops privs to user www, web-content is supposed to be owned by a diff user. not much can be done unless there is another known vuln. in OpenBSD.

    2. By Cabal () on

      I read that on Bugtraq and succesfully used the exploit. So much for the 5 year record, that's a shame. Glad the fix got through, nonetheless.

      Comments

      1. By Anonymous Coward () on

        apache is not enabled by default.

        Comments

        1. By Anonymous Coward () on

          Ya, too bad they claim "X years without remote hole." instead of "X years without remote hole IN THE DEFAULT INSTALL". Turdmonkey!

          Comments
          1. Comments

          2. By Lars () on

            Learn to read.

  2. By Frank Denis () j@bitchy-sex.com on http://www.bitchy-sex.com/

    Don't forget that there are plenty of alternatives to Apache : some are more secure, some are faster, some are way easier to configure, etc. <br> <br> WN Server : http://www.wnserver.org/ (ultrasecure) <br> <br> Caudium : http://www.caudium.org/ (simple and very flexible) <br> <br> Zeus : http://www.zeus.com/ (commercial, but it rocks) <br> <br> etc. <br>

  3. By Vincent Foley () on

    Hi, I run a small firewall with OpenBSD, but for convenience I also have Apache (putting school work there, etc.) The problem is that my hard disk is not big enough to have the sources of OpenBSD. Is there a way I can patch Apache without having to recompile anything?

    Comments

    1. By Miod Vallat () miod@openbsd.org on mailto:miod@openbsd.org

      The sources for in-tree httpd are only a bit more than 10MB. Add less than 5MB more for compiling it, and you're done.

      Comments

      1. By Vincent Foley () on

        I can only compile Apache? This is nice! Exactly what I need!

        Comments

        1. By Anonymous Coward () on

          Yes, see the FAQ : http://www.openbsd.org/faq/faq10.html I ran an OpenBSD system like you described. I always checked out the necesarry sources from CVS like described in the FAQ. Sometimes you need to check out some dependencies. You will notice where the compile fails :-)

      2. By Vincent Foley () on

        Miod Vallat, tu ne serais pas un des développeurs français (le pays) de OpenBSD?

        Comments

  4. By tony () tony@libpcap.net on www.libpcap.net

    Let's say with the new systrace, you configured httpd to not allow any exec() calls.. would you be immune to someone spawning a remote shell through this apache bug?

    Comments

    1. By Anonymous Coward () on

      That would be a temporary fix at best. First of all wouldnt this also make it impossible to use cgi scripts? And besides what if there are binaries owned by user nobody on the system that can be backdoored? I have never looked at the sources but I would also assume that apache depends on execve() and/or friends for more than cgi stuff.

  5. By Nobody () on

    the end of "Five years without a remote hole in the default install!"?

    Comments

    1. By Jason () on

      Apache isn't run in a default install

    2. By RC () on

      Well, Apache isn't enabled by default... AND I have so far not seen a claim that you can get ROOT using this on OpenBSD... It seems to primarily be a DoS exploit.

      Comments

      1. By Nobody () on

        What exactly does "default install" mean? If a program is installed as part of the base system but not enabled by default, isn't it "default install"?

        Comments

        1. By _azure () on

          Not precisely, because the program isn't running after the system comes back up after an install. Enabling the potentially problematic daemon would alter the default state of the system after an install -- thus invalidating its description as "default."

        2. By Anonymous Coward () on

          Forget wasting your time even reading the woeful "X years without a remote root". As has been pointed out ad nauseum if you want to use the system for something useful (that is, changing the system from the default install to one that actually does something by adding djbdns, qmail or enabling Apache for example) as 99% of people do, then the catchphrase immediately becomes meaningless. The point is the default install coupled with sound knowledge on your part gives you a solid foundation upon which to build a useful, functional, and comparatively secure server.

        3. By Anonymous Coward () on

          You can always configure a system to be exploitable after the default install. You don't need Apache for that. You can just simply let Telnet spawn a root shell upon connect.

          "default install" is what you have if you don't fiddle with the configuration after installation. If you do, like enabling Apache, the guarantee is gone.

        4. By Anonymous Coward () on

          Theo must have really pissed off the linquist here.
          Kind of funny how much attention this little line gets.
          --





          Install it, run it, love it. Or move on. OpenBSD
          kicks butt.

          Comments

          1. By Anonymous Coward () on

            All that attention and so little comprehension too!

      2. By Anonymous Coward () on

        Oh let's get real here. A remote unprivileged shell means root, even on openbsd.

        Which is probably why even "safe" unpriv daemons are shut off with the default install.

        That being said, it still kicks the fuck out of everything else out there; and I'm just happy to
        be using it.

  6. By JC () on

    I caught this on bugtrack:
    http://online.securityfocus.com/archive/1/277830/2002-06-18/2002-06-24/2

    Anyone tried it yet?

    I sense this vulnerability could turn into a mess..

    JC

    PS: Reassure me: it is normal for Apache to still show version 1.3.24 after patching (patch 005 on obsd 3.1) right?

  7. By JC () on

    I caught this on bugtrack:
    http://online.securityfocus.com/archive/1/277830/2002-06-18/2002-06-24/2

    Anyone tried it yet?

    I sense this vulnerability could turn into a mess..

    JC

    PS: Reassure me: it is normal for Apache to still show version 1.3.24 after patching (patch 005 on obsd 3.1) right?

    Comments

    1. By JC () on

    2. By Anonymous Coward () on

      Well, I tried this one on my (unpatched) 3.1-release testing-box, and it didn't work.
      It manages to segfault apache children allright, but it doesn't spawn a shell. It just prints out "Ooops.. hehehe", which signifies that it failed...
      It's been running in bruteforce mode too for about 10 minutes now, but I don't expect it's going to make it...

      --------------------
      $ ./apache-scalp 5 127.0.0.1:80

      [*] Connecting.. connected!
      [*] Currently using retaddr 0x9011a, length 29896, localport 15045
      Ooops.. hehehe!
      --------------------
      (note: other targets fail too)

      Comments

      1. By Anonymous Coward () on

        I've seen the same behavior against multiple snapshots from 3.0-RELEASE to 3.1-CURRENT. Evidently the offsets for each version number that are hardcoded into the exploit are not absolute for those version numbers.
        Either that or I'm just too stupid to use the exploit correctly -- which is always a possibility.

        Comments

        1. By Anonymous Coward () on

          It's probably something like that; but here too, it doesn't work on a freshly installed 3.1-release box (just a plain install, and /usr/sbin/apachectl start; nothing more).

      2. By Michael Anuzis () michael_anuzis@hotmail.com on http://www.anuzis.net/apachescalp.txt

        Tested on a computer next to me. It didn't work on default install of OpenBSD3.1, however when I went to apache.org and downloaded/installed 1.3.23 I was able to produce this:
        http://www.anuzis.net/apachescalp.txt

        --Michael

        Comments

        1. By Anonymous Coward () on

          Children shall play.
          MY default install of 3.1
          /usr/sbin/httpd -v
          Server version: Apache/1.3.24 (Unix)
          Server built: Apr 10 2002 16:15:30
          -
          -
          Am I missing something in this little drama?

          Comments

          1. By Michael Anuzis () on

            Yes I'm sorry. The test was run on an OpenBSD3.0 machine not 3.1. My mistake.

    3. By Miod Vallat () miod@openbsd.org on mailto:miod@openbsd.org

      The errata patch does not change the version number in any way.

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.]