numerous holes

[auto122896 () HUSHMAIL COM]

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