[1303] in linux-security and linux-alert archive
[linux-security] Re: Re: Sendmail 8.8.2 exploit.
daemon@ATHENA.MIT.EDU (Quantum)
Wed Nov 20 05:56:12 1996
Old-X-Envelope-From: quantum@obsidian.cse.fau.edu Tue Nov 19 22:27:21 1996
Date: Tue, 19 Nov 1996 22:28:53 -0500 (EST)
From: Quantum <quantum@obsidian.cse.fau.edu>
To: linux-security@redhat.com
In-Reply-To: <199611180836.JAA15574@tiger.cert.dfn.de>
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
On Mon, 18 Nov 1996, Wolfgang Ley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Dawnshadow wrote:
> >
> > Hm, look what I got hold of today.. Works if sendmail is mode 4111 or
> > similar:
>
> [exploit script deleted]
>
> Sendmail 8.8.3 (which is available now) fixes the problem. Get it from
> ftp://ftp.sendmail.org/ucb/src/sendmail/
> or
> ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/
hi.. rather than us sifting through the code could you tell us how it was
fixed ? does the exec(argv[0]) check to see if the argv[0] = some
predefined sendmail? I honestly cannot think of a time where argv[0]
shouldnt equal the path name (tho I'm sure there must be) thus isnt this a
bug in execve implementations? perhaps the new source only allows a reload
of the binary if the HUP signal comes from uid=0 in which case I would
rather like to see that implementation.
[mod: I haven't had time to look at the code either, but as far as I
know checking the source of a signal is not possible. exec-ing
sendmail_install_location would be an idea. However this wouldn't
explain why some people are still seeing exploit possibilities. -- REW]
