On Sat, Feb 14, 2004 at 08:35:20AM -0800, Gary Funck wrote:
I ran a couple of experiments, but didn't have time to go through the
test and make sure it was done in careful way. What I think that I
found out, is that:
:0
PIPE=|cat && /bin/false
(cat copies the input, above, and /bin/false guarrantees a non-zero
exit code)
Will set PIPE to the contents of the message, in spite of the non-zero
return code.
but if either 'w' or 'W' are in place, below it will set PIPE to the
*empty string*.
Yes, that seems completely consistent with what all the recent
experiments are indicating.
So, neither 'w' nor 'W' are safe in this context.
Exactly.
Note: It seems that both using a pipe and backquotes are subject to
the limitation that the amount of data being copied into the variable
must be less than LINEBUF in length. I'm uncertain as to whether the
actual restriction is (LINEBUF-1) characters (to allow for an internal
null character, perhaps, and so on). I'm also uncertain how procmail
behaves if the data being read contains control characters like a null
byte (\000), and/or control-z on Windows platforms.
The LINEBUF restriction is serious, and surprising, and might be the
cause of problems that we've had with the virus scanning example.
Interesting. Yes, we need to determine this for certain one way
or the other.
It'd be good if Mike could share a description of the bug, a
recommended source code patch, etc. Keep in mind that procmail in many
settings is running as 'root', or some privileged user, when executing
/etc/procmailrc. A buffer overrun could lead to a serious security
compromise, DoS, etc.
Good idea. I'll make sure he sees this.
Again, I think it is important to subject this to a wider review, to
make sure that the security implications are known.
Yup.
--
dman
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail