Bugtraq mailing list archives

Re: sendmail exploit script


From: peter () gecko dialix oz au (Peter Wemm)
Date: Mon, 28 Mar 1994 05:03:06 +0800 (WST)


james abendschan writes:
:
:What follows is a sample run exercising the latest sendmail hole and the
:script used to exploit this hole.

This message arrived truncated on my machine - the last few lines of
the script were missing. Also, there was a typo near the end with
three quote characters inside the echo "  ... " >> sm.cf, causing the
shell to break.   However, it gives all the information needed to make
it real simple to do the job.

I have a couple of things to add.

1: If the sendmail you are attacking was compiled with gcc or another 
compiler that puts constant strings in the text section, "calc" wont
find the string "/.../sendmail.cf" in the core, as all the systems
that I have access to do not include the text in the core.

2: again, assuming gcc or another one with strings in the text..  the
-d values *cannot* modify the string "/....../sendmail.cf" - it's a
constant in the read-only text section.  As soon as the -d value hits
the string, you get an instant SEGV.  I would venture as far as saying
that sendmail on these systems cannot be exploited in this particular
way - youd have to find something else to modify in the core image.

3: by default we install binaries without read permission.  I imaging
that a lot of others would do the same.  This script does not work on
systems without read permission on /usr/lib/sendmail.  it needs to
copy it so that it can remove the setuid bits.  However.. on systems
with enhanced security, a process can *revoke* kernel permissions.  A
SCO unix system (for example) can volunteer to "give up" setuid exec()
privs and that will *probably* mean that you could get
/usr/lib/sendmail (unreadable, setuid) to core dump (as it's no longer
setuid).  Assuming this works, this would mean that a user could use
the "security" system on SCO unix to *obtain* *extra* information that
normal OS's dont give..  kinda like a security negative-enhancement.
Of course, I've not tested this, but I did write some code once that
had to deal with removing privs for a replacement login binary.  It's
probably possible on any system with SecureWare(TM) "enhancements".

4: I was going to have a bitch about this being sent out on the
weekend, but I suppose I cannot really, as we had plenty of warning
that the bug was there..  Still, it would have been nice to know that
the admins were stung into action on monday had the same amount of
time as the hackers.  Yes, I know this has been thrashed to death in
comp.security.unix. 

Oh. Joy!  However, with the intense security that sendmail is getting
at the moment, I can't imagine that there's too many undiscovered
holes left now..

-- 
Peter Wemm <peter () DIALix oz au> - NIC Handle: PW65 - The keeper of "NN"
      "My computer is better than your computer" - Anonymous
  (Overheard, shortly after the creation of the second computer....)



Current thread: