Search: Home Bugtraq Vulnerabilities Mailing Lists Jobs Tools Beta Programs

Solaris ab2 (DynaWeb) Server DoS & Possible Trojan Vulnerability

A denial-of-service attack and a possible trojan-insertion attack have been found in dwhttpd/3.1a4 (answerbook webserver).

At least two users reported this bug to Bugtraq and to Sun. The following database entry is a summary of their messages. The actual messages in their entirety are included in the Credit section of this database entry.

- - - - - - - - - -
It seems to be trivial to force dwhttpd to stop processing CGI requests by doing a POST with a large content-length; further CGI requests then fail with the following message:

HTTP/1.0 500 Server Error
Server: dwhttpd/3.1a4 (Inso; sun5)
[...]

The server currently lacks the resources needed to handle your request.
Please try again later.

The affected dwhttpd process will eat one cpu, with possible impact on other services. (MP machines will still have some cpus available.)

Furthermore it doesn't seem to handle %-encoding and logs in a bizzarre way , which results in URLs with printf-style '%' strings in them getting odd 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 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 can possibly result in some security problems. 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

This is dangerous in that it seems to be access (or open) a shared library in /tmp:

xstat(2, "/tmp/ecm/utf8.so", 0xDED03024) Err#2 ENOENT

This could in theory allow a hostile user to install a trojan libaray in the /tmp/ecm directory replacing utf8.so and allowing them to leverage access at which dwhttpd is run as.







 

Privacy Statement
Copyright 2009, SecurityFocus