+-----------------------------------------------------------+
| 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

IMPORTANT NOTICE: If you are not using HushMail, this message could have been read easily by the many people who have access to your open personal email messages.
Get your FREE, totally secure email address at http://www.hushmail.com.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]