Bugtraq mailing list archives

Re: sendmail -d hole


From: jkb () mrc-lmb cam ac uk (Bonfield James)
Date: Wed, 16 Mar 94 13:35:36 EST


Hello,

It seems many people are asking more about the sendmail -d problem. 

I'm not going to write any exploit scripts, although several people have asked
for them. That just gives the feebler crackers a chance. Currently only the
more knowlegdable (ie probably only 5% or less) crackers are likely to know how
to exploit this. Besides, I've only followed this through to the conclusion on
Solaris 2.3.

However more info does follow:

The problem is that with -d arguments between max signed int and max unsigned
int pass the valid-range (0-99 inclusive) check. The result is that it is
possible to write to areas of memory prior to the debug array. With a bit of
trickery the pathname of the sendmail config can be deduced as an offset from
the debug array. Hence the leading slash can then be changed to a '.' to
produce a relative pathname. Once you've got your own sendmail config I'm sure
you all realise how easy obtaining root access is. There are presumably many
other memory locations that can also be overwritten to have a similar effect.

Several points to note though:

a) The attack can only be done from the local system - it requires execute
permission of the sendmail binary.

b) To figure out the correct -d value initially read access on sendmail, or
read access to a sendmail core dump is of major help.

c) Even with b) it is tricky to obtain the correct address as most sendmails
are normally void of all debugging information.

d) It does not effect sendmail 8.6.7 or IDA sendmail. Not all standard vendor
sendmails are effected either.

e) The -d value probably differs for each system type, and probably for each
system release.

f) Many of the above don't count once it is known that for a particular system
the correct value is 'xyzzy'.

g) To fix in the source (assuming a derivitive of most sendmails), change the
"first", "last" and "i" variables in trace.c:tTflag() to unsigned int. I've
just noticed a message from Scott Chasin reporting exactly this.

This is a real threat. I have sucessfully obtained root access by using this
method on a standard distribution of Solaris 2.3. I would suggest anyone who
checks their own system for this to hassle the relevant vendor. If they didn't
know of the bug fix years back when it was found, it is possible that they
still don't.

Testing for the problem isn't obvious. I've used 'sendmail -d3000000000' to
test - if this crashes then you've certainly got a problem. If you're int size
isn't 32 bits then you'll have to choose another -d value instead. The above
works because 3000000000 is equivalent to (I think) index -0x4D2FA200 into the
debug array, which _normally_ yields a memory exception. I have no better
check.

Once again, cheers to Francis Dupont (dupont@@inria.inria.fr) who is credited
for the report of this bug in the IDA sendmail RCS file trace.c,v.

        James

James Bonfield (jkb () mrc-lmb cam ac uk)   Tel: 0223 402499   Fax: 0223 412282
Medical Research Council - Laboratory of Molecular Biology,
Hills Road, Cambridge, CB2 2QH, England.



Current thread: