More procmail

[chris () FERRET LMH OX AC UK (Chris Evans)]

Hi,

Well well since Debian appear to have "broken silence" on the procmail
front rather than wait for an official announcement...

I found something potentially more serious than boring heap overflows. It
is allegedly fixed in the latest procmail release but I haven't checked.

As a summary local users can dump the contents of any file to screen. As a
comment I would suggest anyone running procmail with elevated privs either

a) Needs their head examined or
b) Hasn't read the code.

Here is a quote of a previous mail I sent various people when I first
found the file handling issue. I also recommended to the procmail team
that they review _all_ of their file handling code. I have no idea whether
this recommendation was taken on board or not..

Cheers
Chris

-----8<--------

However on to more interesting things, I have found a much more serious
security hole in procmail's file handling which can lead to users dumping
the contents of arbitrary files they should not be able to read to the
screen.

The faulty code sequence is in the handling of .procmailrc files and goes
something like

1) stat .procmailrc (as root) - if it can't be stat'ed keep root privs
2) open .procmailrc
3) do lstat on .procmailrc for security check

By replacing .procmailrc after steps 1) and 2) with a symlink to the file
to dump and a regular file respectively, we can win a race condition.

You might not think this is a very plausible race but with a few deep
directory/multiple symlink tricks/SIGSTOP/etc. the window can be made
quite wide. This is definitely exploitable.