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.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:41:36 PDT