Bugtraq mailing list archives

Re: Microsoft BackOffice component: adredir.asp


From: secure () MICROSOFT COM (Microsoft Security Response Center)
Date: Sun, 4 Jun 2000 07:34:53 -0700


-----BEGIN PGP SIGNED MESSAGE-----

Microsoft engineers worked through the night to investigate this
report, and we have preliminary results.  There does not appear to be
a security vulnerability here.

The most common shipment vehicle for Adredir.asp is Site Server 3.0,
Commerce Edition.  Our test matrix checked Site Server 3.0, Commerce
Edition (all service packs) running on Windows NT 4.0 (all service
packs since SP3) or Windows 2000.  The results were the same in each
case:
*       There was no denial of service.  When we sent a sufficiently long
bogus URL to Adredir.asp, the server did drop the connection.  This
was an appropriate response, since the URL was invalid.  However, in
all of our tests, the server continued normal processing -- in
particular, it continued servicing other current connections, and
would accept new ones.
*       There was no opportunity to run arbitrary code.  No matter how long
the URL was, it did not overwrite either the stack or the heap.  We
double-checked our results by doing a source code review, and found
that there are no fixed-length buffers at all in Adredir.asp, and the
code appears to properly validate all inputs before using them.

If any BugTraq readers have tested this on their own systems and
obtained results different from ours, we'd be most interested in
hearing more.  For now, though, it does not appear that there is a
security vulnerability here.

In closing, I'd like to note that the Microsoft Security Response
Center is available at any time to investigate any potential security
vulnerability involving a Microsoft product.  We can respond most
quickly when the reports are sent directly to us at
secure () microsoft com.  Regards,

Secure () microsoft com

- -----Original Message-----
From: Michal Zalewski [mailto:lcamtuf () TPI PL]
Sent: Saturday, June 03, 2000 5:00 AM
To: BUGTRAQ () SECURITYFOCUS COM
Subject: Microsoft BackOffice component: adredir.asp

Bkgrnd: adredir.asp is commonly used component of IIS-based commercial
sites, used to handle ad banners. Altavista dumps pretty impressive
list
of sites using it. Usually, this script lives in subdirectory on main
IIS
server, or on dedicated ad server - you could easily obtain it's
location
by inspecting banner code... adredir.asp is often renamed to
'redirect.asp' or so, but quite popular.

This BO component (the first and only I'm going to check - responsible
web
admins shouldn't use IIS+ASP at all, choosing more secure solutions,
like
Apache+SSI or even Apache+IIS, IMHO) has buffer overflow. It can be
exploited by sending request like:

GET /place_it_lives_in/adredir.asp?url=(more than +/- 500 bytes)

By choosing something around 500-510 bytes (depending on directory
name
length), you'll notice first change - server will drop connection
after
returning '302 Moved' http header. Normally, it prints these headers,
and
then some html code as well: <body><h1>Object Moved</h1>This object
may be
found <a HREF="AAAA.... Probably this HTML is rendered into small text
buffer, and script crashes while trying to assemble it.

With approx 1000 bytes of junk, script will die without even
displaying
headers. Funny. And exploitable, I guess. I have no idea about
symptoms on
NT machine, probably not much, at least it not crashes (wow,
uncommon!).

Have a good day. Someone might want to check if I'm right, but I can't
imagine it might be something else than overflow.

Btw. OAS (Oracle Application Server) / OWL (Oracle Web Listener) users
shouldn't feel safe. More details soon.

Standard disclaimer applies. Yeah, yeah. Hi to: b0f, lam3rz, HERT,
teso
and other people.

_______________________________________________________
Michal Zalewski [lcamtuf () tpi pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2

iQEVAwUBOTpmuI0ZSRQxA/UrAQEjrggAopZXE2POl7dcEqMQuIfLd9bRT6n+5nwg
8rOUH6O0uFlH+Ye19yLOoDdAB1bG3SGkvBYd7wsd9sqgzVKqs36alAh1rkD/phoD
GtuMcMNXSDcTURefYkgkjXOUTlbSBFlNev3wymwcnTeqgFH3NnrFTEmjJ8AKxK0W
YTG2OZg/XJqf1y6tvjMGV4BeZ3voQopgyhxzVuzEnlrTIgPm+OK93SKB/3njsP7n
QhNo8ia+04+qhL6ddrv8XfpiH1lMI741VAVk3vt5CAkEPcyjDgqsd9j4an9ylG+Q
bJpwd3DaIovmES49IE7dAf3pmzz1B5i4Bvc1Nmh43pXNESb9gFdcMQ==
=hgvr
-----END PGP SIGNATURE-----


Current thread: