5974842 2001-01-17 17:05 +0000 /220 rader/ <auto122896@HUSHMAIL.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-18 21:27 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: auto122896@HUSHMAIL.COM
Mottagare: Bugtraq (import) <14882>
Ärende: numerous holes
------------------------------------------------------------
+-----------------------------------------------------------+
| Independent Security Analysis |#
| "Security Vulnerabilities That Matter" |#
| |#
+___________________________________________________________+#
############################################################/
wwwwais.c is a CGI-based application that provides a frontend to
several WAIS query tools. I was unable to locate the main
distribution site for it, but source code can be found at the
following locations:
http://www.spawar.navy.mil/planet_earth/free/wwwwais/
http://sunsite.bilkent.edu.tr/pub/infosystems/wwwwais/
http://xenia.sote.hu/ftp/www/tools/index/wwwwais/
http://www.doc.mmu.ac.uk/DEVELOPMENT/scripts/
http://yardim.bilkent.edu.tr/WWW/wwwwais/
http://wwwmaths.anu.edu.au/atc/wwwwais/
This discussion applies to wwwwais.25.c, which appears to be the
latest version. There has been no prior mention of this vulnerability
by other Bugtraqers, hence my reason for posting.
(1) The attacker uses the GET method, causing execution of the following
code:
136 static char query_string[MAXSTRLEN],
[...]
196 else if (!strncmp(method, "GET", 3)) {
197 query = (char *) getenv("QUERY_STRING");
198 if (query == NULL)
199 query_string[0] = '\0';
200 else
201 strcpy(query_string, query);
query_string is a character array allocated in the BSS segment. Its
size is MAXSTRLEN, which translates to 1024. The POST method won't
work for this overflow because a guard variable is used to process it.
211 version = ((getvalue(VERSIONTXT, ""))[0] == '\0') ? 0 : 1;
As can be seen, getvalue() is invoked immediately afterwards.
(2) The attacker prepends "version=666&" to QUERY_STRING in order to
force execution of the strcpy at line 351 in the following code:
335 {
336 int i;
337 char *c, *argp, argstr[MAXSTRLEN];
338 static char value[MAXSTRLEN], tmpstr[MAXSTRLEN];
339
340 if (query_string[0] == '\0' || !lstrstr(query_string, var)) {
341 argp = (char *) getenv("PATH_INFO");
342 if (argp == NULL || !lstrstr(argp, var)) {
343 if (strlen(def) <= 1)
344 return "\0";
345 strcpy(tmpstr, decode(def));
346 return tmpstr;
347 }
348 strcpy(argstr, argp);
349 }
350 else
351 strcpy(argstr, query_string);
352
353 for (i = 0, c = (char *) lstrstr(argstr, var) +
354 strlen(var); *c && i < MAXSTRLEN && *c != '&'; c++)
355 value[i++] = *c;
356 value[i] = '\0';
357
358 if (i) {
359 strcpy(tmpstr, decode(value));
360 return tmpstr;
361 }
argstr is allocated on the stack; therefore the attacker can overwrite
the activation record by crafting QUERY_STRING appropriately.
The attacker will most likely gain access to the system running the
vulnerable application, with privileges equivalent to those belonging
to the webserver process. However, most attackers will use fork-bomb
shellcode that could bring your server to a complete standstill. It
is estimated that 200-300 sites are vulnerable to this overflow.
It's probable that there are many other vulnerabilities existing in
wwwwais.c, but the one mentioned above is by far the easiest to
exploit.
Workaround: `rm -f wwwwais*`
Exploit code for this is not included because I don't think it's right
to give people the chance to deface webpages with my code -- something
the crew at www.netcat.it would not agree with.
(http://www.attrition.org/mirror/attrition/2001/01/05/www.virtue.nu/)
It has also come to my attention that hotmail.com has yet another
javascript security hole. The impact of this is that a malicious
hacker out there in the wild can email a hotmail user and breach the
user's client-side security. This is very distressing for me.
Hotmail has requested that I hold back from releasing exploit code at
the present time, and in true RFPolicy manner, this is what I shall
be doing. However, in the meantime I'd like to give a brief outline
of the vulnerability's ramifications and also discuss some of the
general effects of other related vulnerabilities with extremely high
care factors.
The code to exploit the hotmail vulnerability is quite exceptional
because rather than attacking features of the web scripting languages
as past attacks have done (CSS imports, javascript: protocol abuse,
character entity escapes, hex escapes, etc.), the exploit attacks
hotmail's filtering system itself. Further development of the exploit
can yield devastating blows ranging from password capture to infinite
loop window bombing with an incredibly fast cyclic rate.
Also, attackers may be afforded the opportunity to utilize concepts
pertaining to the recently discussed "cache cookies"
vulnerability. This is unnerving because, amidst the world of
cleartext HTTP transactions, the last thing the Internet security
infrastructure needed was the chance for unscrupulous administrators
to discover if their website visitors had recently visited Yahoo or
Ebay. At present I'm unsure if the hotmail hole will perpetuate the
cache cookies vulnerability, but I'm in the process of investigating
it.
Client-side attacks seem to be the preferred penetration techniques
for hackers on the Internet. Unlike their server-side counterparts,
client- side holes allow attackers to wage a full-fledged battery
against unsuspecting victims, with a high degree of granularity. This
is not to say that server-side attacks haven't become more serious in
recent times; the efforts of Guardent and their gopherd hole
affecting millions of servers worldwide attest otherwise. Luckily,
problems of this magnitude are rare and the major threats still seem
to arise from client-side holes.
Netscape, Internet Explorer, Lynx, ad nauseum -- they've all proved in
the past that they're not immune to highly sophisticated intrusion
methods believed to be in active use by federal agencies, terrorist
units, and hackers throughout the globe.
It has long been known that certain security groups keep their
exploits secret and distribute them only in cloak-and-dagger
fashion. Among this exploit code, an estimated 95% of it is believed
to enable individuals to enter computer systems through
vulnerabilities existing in Internet Explorer, pine, mutt, and other
critical network software. As a whitehat security professional who
gets paid thousands of dollars to perform security assessments with
nessus, nmap, and traceroute, I am truly disturbed that this exploit
code is not being shared freely with people like me who actually want
to improve the state of security and make some negligible cash at the
same time.
Consider the spur of bugtraq posts detailing holes found in
PalmOs. What can you trust these days? Was your Nintendo Gameboy
designed with a preemptive approach to risk mitigation? Or is it
violating your security policy? Perhaps the @stake boys have the
answer.
In these troubled times, only a compulsive security diet and a very
conspiratorial paranoia will ultimately protect you from the latest
and greatest unreleased exploit code that is actively being used to
grant access to your servers -- through your web browsers.
Free, encrypted, secure Web-based email at www.hushmail.com
(5974842) --------------------------------(Ombruten)