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:
- Re: sendmail -d hole Bonfield James (Mar 16)
- Re: sendmail -d hole Timothy Newsham (Mar 20)
- <Possible follow-ups>
- Re: sendmail -d hole Bonfield James (Mar 18)