Solaris ab2 (DynaWeb) Server DoS & Possible Trojan Vulnerability
BID:253
Info
Solaris ab2 (DynaWeb) Server DoS & Possible Trojan Vulnerability
| Bugtraq ID: | 253 |
| Class: | Failure to Handle Exceptional Conditions |
| CVE: |
CVE-1999-1416 CVE-1999-1417 |
| Remote: | Yes |
| Local: | Yes |
| Published: | Apr 30 1998 12:00AM |
| Updated: | Nov 15 2007 12:39AM |
| Credit: | This vulnerability was initially forwarded to the Bugtraq mailing list by Jamie Lawrence <[email protected]> Thu, 30 Apr 1998 (the actual forwarded message was written by Thomas Anders <[email protected]>). On Sun, 23 Aug 1998, Marc Slemko <[email protected]> sent |
| Vulnerable: |
Sun Solaris 2.6_x86 Sun Solaris 2.6 Inso dwhttpd 3.1 a4 |
| Not Vulnerable: |
Sun Solaris 7.0_x86 Sun Solaris 7.0 |
Discussion
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.
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.
References
Solaris ab2 (DynaWeb) Server DoS & Possible Trojan Vulnerability
References:
References:
- INSO Corporation (INSO)