[210] in bugtraq

home help back first fref pref prev next nref lref last post

Comments on SunOS /bin/mail patch

daemon@ATHENA.MIT.EDU (Chris Ellwood)
Sat Nov 26 06:47:19 1994

Date: Sat, 26 Nov 1994 02:26:50 -0800
From: Chris Ellwood <cellwood@gauss.ELEE.CalPoly.EDU>
To: bugtraq@fc.net

I noticed that there hasn't been much discussion on Sun's recently
released SunOS v4.1.3 /bin/mail patch (patch# 101436-08), especially 
in regard to if it fixes any of the three big security holes in 
/bin/mail, which past Sun patches have failed to do (See 
8lgm-Advisory-6.UNIX.mail2.2-May-1994).

After doing some analysis with trace(1) and experimenting with some exploit 
scripts, it seems that this patch indeed does fix at least one, if not all
three of the race conditions holes in /bin/mail.  

This new patch seems to prevent the old problem of being able to write 
to any existing file by exploiting a race condition with the creation 
of the temp file.  None of the exploit scripts developed to exploit this
race condition work on the patched version, and careful analysis with 
trace(1) reveals that this is due to a much improved method of opening 
temp files.

It also seems to handle mailbox lock files correctly, so I would hope this 
fixes the mailbox lock file race condition as well, though I have not 
tested the lock file race condition yet.  

Upon cursory analysis, it also seems to have fixed the much publicized
/usr/spool/mail mailbox race condition.  Perhaps the 8lgm security team 
could fill us in on that, in light of their excellent analysis of the
problems with past Sun patches to fix this particular race condition.

I was going to include a sample trace output to show how Sun fixed the
problems (so people can point out potential flaws), but since that would
possibly violate the Sun licensing agreement, I won't.  Needless to say
the new Sun code seems to do open's and fstat's correctly to prevent race 
conditions, but don't take my word for it.  Obtain your own copy and see 
for yourself.

Again, my analysis is no where near complete or that of an expert, so I
welcome any and all comments on this.

Regards,

- Christopher Ellwood <cellwood@gauss.calpoly.edu>
EL/EE Dept. System Administrator - Cal Poly, San Luis Obispo, California

home help back first fref pref prev next nref lref last post