Re: /bin/mail...

[neil () legless demon co uk (Neil Woods)]

> Good Morning,
>
>   After playing with the race condition this morning, I honestly don't
>   see how the patch made it worse. (Unless I've got the scripts
>   backwards.) The first exploit allowed you to create or append to any
>   file. The second exploit only allows you to create any file. Yeah, it
>   probably makes people feel more secure, but it's silly if they feel
>   safe. So, after the patch, you can atleast not append to /etc/passwd
>   or whatever. As well, it seems that if there is an alias for the 0 UID
>   user, the problem doesn't exist. (Atleast I didn't see an option for
>   not doing an alias with binmail. I could be wrong.) As well, even if
>   you could write to /etc/passwd (/etc/shadow) it doesn't parse past
>   bogus lines. (ie. the mail headers) 
>
>   Please let me know if I'm wrong in any of these statements.

At the time of writing of the second binmail advisory, it was possible
for the first exploit script to lose the race permanently - i.e. a mailbox
was created in /var/spool/mail.  Suns patch ensured that losing was no longer
possible.

As stated in the second advisory, it is still possible to append to files
with the patch Sun provided, the exploit script simply does not support this,
as this would have involved unnecessary work on our part.  The ability to create
files anywhere around the filesystem is just as serious as being able to append
to files.

It is not possible to use aliases as a work-around.  binmail doesn't handle
aliasing, sendmail does.  sendmail itself has an option to not perform aliasing.

Cheers,

Neil

-- 
Bull in the Heather, Me and My Charms, The Lights, Sensual World, Go, Ritual,
Handsome and Gretel, Take Me, Blue Room, Drunken Butterfly, She's Lost Control.

        ...like a badger with an afro throwing sparklers at the Pope...