0. The tone of the original posting, especially the subject line, is quite unprofessional.
1. The race condition seems easy enough to fix by using O_EXCL. But then it should retry with a new generated file name a bunch of times, rather than simply giving up. (Giving up is especially bad for clamd.) 2. It would be nice if ClamAV also scanned base64-UUEncoded files, but I wouldn't call it a vulnerability, as I don't see how it can compromise ClamAV itself. (Any virus let through can compromise a downstream user or computer, but *no* AV package finds *all* viruses.) BTW, signatures for *raw* base64-UUEncoded files is not the best way to go. UUencoding can be a one-to-many map (en.wikipedia.org/wiki/Uuencode), so there could be an arbitrary number of UUencoded files, and hence base64-UUEncoded files, for a given malware payload. In fact, uudecode version 4.6.2 (GNU sharutils) on Linux indeed ignores space and back-quote characters at end of *interior* lines in the base64 data. So all that a bad guy would have to do is randomly modify the output of standard uuencode to make signature detection problematic. 3. It would be nice if sigtool handled output files "more securely", but I wouldn't consider it a critical vulnerability, and I suspect that many common programs have the same problem. 4. All AV packages seem to have vulnerabilities on occasion. I have high overall confidence in ClamAV because (a) it is still Open Source, so I can know what it is doing, (b) even the Windows version (AFAIK) doesn't hook in to the kernel (like most Windows AV), making it less likely to be a path to total compromise of the computer. Paul Kosinski _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
