[569] in Intrusion Detection Systems
sendmail test
daemon@ATHENA.MIT.EDU (Mudge (uberhuman?))
Fri Feb 9 13:59:34 1996
Date: Wed, 7 Feb 1996 14:49:04 -0500 (EST)
From: "Mudge (uberhuman?)" <mudge@l0pht.com>
To: ids@uow.edu.au
Reply-To: ids@uow.edu.au
Fred Cohen wrote:
>Hi Frank:
>I have tried to generate buffer overruns from my sendmail but only get
>an error message stating that the input line is too long.
>I am running Sun's Sendmail 4.1/3.2.012693 under SunOS Release 4.1.3_U
>Is there a test I can do to determine whether or not this vulnerability
>applies? I am running Sendmail through tcp wrappers in case this makes a
>difference.
There are several remote tests to do for this but there is an even
more trivial local test.
The problem ends up being buried way down in libc. Turns out that
vsnprintf(), though supposedly bounds checking, was not.
An easy way to see if you have the problem is to send a very long
string to syslog() which, in it's bowels, calls vsnprintf().
try something like
foo.c
#include <syslog.h>
main()
{
char bar[4096];
int i;
for (i=0; i<4096; i++)
bar[i] = 'A';
syslog(LOG_ERR, bar);
}
If you get a segmentation fault after running the above program
program you have the problem.
If you want to examine what's going on, gdb the program. You should
see that 0x41 overwrites the stack.
There are several places where sendmail calls syslog() with user
supplied input and does not do any bounds checking.
I've been able to exploit the problem both locally and remotely on
BSDI boxes and gain root access ('cause I had PC assembler reference manuals
handy for all the opcodes). The problem is not confined to BSDI on
x86 architectures. If I had the inclination to dig up my SunOS manuals
for assembly cruft that would be just as easy. Rumor has it that
several people at Sun have done just this (and I've been able to confirm
this).
PS... TCP wrappers won't prevent this. All they are doing is providing
you extra loggin and an access control list.
.mudge
