I think we all need to calm down. "Vulnerability" #1: Yes, cli_gentemp has a theoretical race condition. Is it theoretically exploitable? Sure. Is it *likely* to be exploited in the real world? No. You have to guess 128 bits of mildly-good random data. That's quite unlikely.
"Vulnerability" #2: It's not necessary to support decoding of uuencoded data. You just need to publish signatures for the raw uuencoded data and you're done. "Vulnerability" #3: I have not looked in depth at how sigtool uses/generates temporary files, but it appears to use cli_gentemp so again the vulnerability is largely theoretical. IMO, if you want a *real* vulnerability, look at the hard-coded /tmp/clamav-partial directory. If an attacker manages to create a symlink in /tmp/clamav-partial to an appropriate directory of his choosing, then damage can be done. The attack is tricky because it needs to happen before clam itself has created /tmp/clamav-partial. Also, the code tests for the permissions of the partial directory, so you'd need to have the directory be mode 0700 for the stat and relax the permissions thereafter, but this is a much more promising vector for getting clam to overwrite files it shouldn't touch. Also, I have not looked in detail at the code that dumps files into clamav-partial, but it seems on cursory reading to place a worrying amount of trust in the filenames declared in the MIME headers. IMO, it should choose sequential filenames like "part.1", "part.2" etc. for maximum safety. Of course, an entire class of bugs can be eliminated if sysadmins point TMPDIR to a private directory, and Clam supports that. Regards, David. _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
