COMMAND

    ab2 server

SYSTEMS AFFECTED

    Solaris 2.6

PROBLEM

    Marc Slemko  found following  about the  dwhttpd/3.1a4 web  server
    that is installed for the ab2 stuff  in 2.6 is.  It is trivial  to
    make it stop processing CGI requests by doing a POST with a  large
    content-length;  further  CGI  requests  then  fail with an out of
    memory or something.   It doesn't handle %-encoding and logs in  a
    funky way, which results in URLs with printf-style '%' strings  in
    getting funky log entries.  For example, accessing

        http://apollo:8888/foo/%s

    gives a log entry of:

        http-8888 [02/May/2000:00:24:12 -0600] warning: send-file reports:  The requested8ãÿß$þßGÇßßÇßÓ×Èߪä¾ÈßÊ" could not be opened!

    It is interpreting the %s as  a printf style format string.   This
    could, if you can find the right error message and have the  right
    junk  memory  accessed,  possibly  compromise information from the
    address space of  the server that  shouldn't be compromised.   Not
    likely, but  possible.   Note that  this mishandling  of %-encoded
    strings also rejects  valid requests that  are % encoded,  but the
    server doesn't even  start to be  HTTP compliant so  that probably
    doesn't matter.

    You can cause it to core dump trivially in many ways.   Requesting
    /foo.cgi makes it die,  as does a request  that is long enough  to
    get an ENAMETOOLONG (causes it to try opening ""), or even  longer
    (causes it to die with an assertion failure):

        Assertion failed: buffer && len > 0 && timeout >= 0, file ../dwhttpd/dwsocket.cc, line 294\n

    All of the above is lame and can possibly result in some  security
    problems, but since this  server obviously isn't intended  to have
    any real use then the DoS attacks aren't overly serious.  None  of
    these  appear  to  be  buffer  overflow  problems.   More serious,
    however, is this excerpt from a truss of it handling a request:

        poll(0xDED00A60, 1, 120000)                     = 1
        recv(12, " G E T   /   H T T P / 1".., 4096, 0) = 261
        xstat(2, "/usr/lib/ab2/data/docs/", 0xDED03BB4) = 0
        xstat(2, "/tmp/ecm/utf8.so", 0xDED03024)        Err#2 ENOENT
        xstat(2, "/usr/lib/ab2/lib/ecm/utf8.so", 0xDED03024) Err#2 ENOENT
        xstat(2, "/usr/lib/ab2/dweb/sunos5/lib/ecm/utf8.so", 0xDED03024) = 0
        open("/usr/lib/ab2/dweb/sunos5/lib/ecm/utf8.so", O_RDONLY) = 13

    Why the heck  is it trying  to open a  shared library under  /tmp?
    There's nothing stopping me from creating my own trojaned  utf8.so
    and  putting  it  in  /tmp/ecm  to  gain easy access to the daemon
    uid.  No,  access to daemon  doesn't give you  that much (although
    it could do more  if you had some  NFS mounts from another  server
    where it did matter)  and none of the  above is a remote  exploit,
    but  finding  all  this  in  15  minutes  of  looking is enough to
    convince me that there is  a high probability of their  being some
    yet-unpublished remote exploit to gain access to the box remotely.
    Some of this may be x86 specific.  Tests done on the below system:

        Release: 5.6
        Kernel architecture: i86pc
        Application architecture: i386
        Kernel version: SunOS 5.6 Generic 105182-04 January 1998

SOLUTION

    Disable this daemon.