be back with the same overflow situation caused by the lea edi,[esi+0x18]
instruction.
The solution to these problems is to simply define the buffer length as an
unsigned short, which would cause the compiler to use MOVZXinstead of
MOVSX. MOVZXzero extends the integer during conversion (meaning simply
that the most significant word in the target 32-bit integer is set to zero), so that
its numeric value stays the same.Case-Study: The IIS Indexing Service Vulnerability
Let’s take a look at what one of these bugs look like in a real commercial soft-
ware product. This is different from what you’ve done up to this point because
all of the samples you’ve looked at so far in this chapter were short samples
created specifically to demonstrate one particular bug or another. With a com-
mercial product, the challenging part is typically the magnitude of code we
need to look at. Sure, eventually when you locate the bug it looks just like it
did in the brief samples, but the challenge is to make out these bugs inside an
endless sea of code.
In June 2001, a nasty vulnerability was discovered in versions 4 and 5 of the
Microsoft Internet Information Services (IIS). The main problem was that any
Windows 2000 Server system was vulnerable in its default configuration out of
the box. The vulnerability was caused by an unchecked buffer in an ISAPI(Inter-
net Services Application Programming Interface) DLL. ISAPI is an interface that
is used for creating IIS extension DLLs that provide server-side functionality in
the Web server. The vulnerability was found in idq.dll—an ISAPI DLL that
interfaces with the Indexing Service and is installed as a part of IIS.
The vulnerability (which was posted by Microsoft as security bulletin
MS01-044) was actually exploited by the Code Red Worm, of which you’ve
probably heard. Code Red had many different variants, but generally speak-
ing it would operate on a monthly cycle (meaning that it would do different
things on different days of the month). During much of the time, the worm
would simply try to find other vulnerable hosts to which it could spread. At
other times, the worm would intercept all incoming HTTP requests and make
IIS send back the following message instead of any meaningful Web page:HELLO! Welcome to http://www.worm.com! Hacked By Chinese!The vulnerability in IIS was caused by a combination of several flaws, but
most important was the fact that URLs sent to IIS that contained an .idqor
.idafile name resulted in the URL parameters being passed into idq.dll
(regardless of whether the file is actually found). Once inside idq.dll, the
URL was decoded and converted to Unicode inside a limited-sized stack vari-
able, with absolutely no bounds checking.262 Chapter 7