This Old Vulnerability: Sendmail 8.6.9
Dave G. | May 18th, 2007 | Filed Under: This Old Vulnerability
Today on This Old Vulnerability, we will take a quick tour through a classic metacharacter/delimiter injection attack. Our petri dish will be Sendmail 8.6.9 (and 8.6.10). The vulnerability was caused when sendmail would take input from a remote identd (the username) and blindly write it into a sendmail queue file. Normally, the output from identd would look something like:
srvrport , clientport : USERID : UNIX :username
Sendmail was just trying to grab the username. However, since no input validation was performed, an attacker could write their own identd that would return a response like:
25,25 : USERID : UNIX : Croot\r\n
Mprog, P=/bin/sh, F=lsDFMeu, A=sh -c $u\r\n
Mlocal, P=/bin/sh, F=lsDFMeu, A=sh -c $u\r\n
R<"|/bin/echo toor::0:1:toor:/:/bin/csh >> /etc/passwd”>\r\n
R<"|/usr/bin/chmod 4755 /usr/bin/time\r\n
As you can probably guess, everything past the “UNIX : ” part will get deposited into a sendmail queue file. Furthermore, you can probably guess that a sendmail queue file with that cruft in there will eventually cause sendmail to add a user called ‘toor’ with root privileges and no password, and make /usr/bin/time setuid root. A setuid time is bad because:
$ /usr/bin/time /bin/sh
will execute /bin/sh as root (This was a long time ago, and for its day considered clever, not unlike myself).
I think we should consult the sendmail release notes and see what they have to say about this vulnerability:
SECURITY: Diagnose bogus values to some command line flags that
could allow trash to get into headers and qf files.
Validate the name of the user returned by the IDENT protocol.
Some systems that really dislike IDENT send intentionally
bogus information. Problem pointed out by Michael Bushnell
of the Free Software Foundation. Has some security
implications.
The authors of sendmail had a very simple fix for this. Look for occurences of newline (’\n’) characters and change them to the space character. Alas, it appears that through the use of queue file continuation lines, an attacker could add a bunch of tabs and trigger the same vulnerability (*).
(*) I will admit to not being 100% sure of this, but it my best guess based on 2 seconds of reviewing an exploit, the diff and google, as you can tell from the lack of posting, time to read sendmail diffs is a luxury I don’t have. It is entirely possible that the root cause is something else entirely, that the exploit never worked or that it was fixed later than 8.6.11. There was another patch for this vulnerability in 8.6.13.
