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:
- Re: sendmail exploit script Peter Wemm (Mar 27)
- <Possible follow-ups>
- Re: sendmail exploit script Peter Wemm (Mar 28)