-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roflek of TK53 wrote: > Hello everyone, >> "1) ClamAV uses own functions to create temporary files. One such routine is >> vulnerable to a race condition attack." >> >> The analysis is incorrect. The author mistakenly assumed that name_salt is >> fixed and this is not true. After each call to cli_gentemp() name_salt gets >> updated with a new MD5 digest and then used in generating new temporary name, >> updated again and so on. Together with 48 pseudo-random bytes(*) used in >> hashing it makes a solution practically resistant to race conditions. > > Simply generating very long filenames doesn't protect you from race > conditions and symlink attacks. Well, from a practical, naive point of > view that only considers what is easy to observe, it is. But since > security is a serious business, the race condition exists as long as > the code doesn't correctly check the existence of the target file. > Hint: atomicity is the keyword. > But, it makes it extremely unlikely to occur; which is not what the reporter suggests. >> "2) ClamAV fails to properly check for base64-UUEncoded files, allowing >> bypassing of the scanner through the use of such files." >> >> This is not really a security bug but rather a lack of feature. Any (massive) >> attempt to bypass the uuencode decoder can be stopped with regular signatures >> thanks to the fact that ClamAV additionally scans all files in raw mode. > > The first person that will be pwned because ClamAV failed to properly > scan the Base64-UUEncoded file attachment that the user's mail client > decodes and displays as regular attachment will greatly thank you and > your wise and cautious look at virus-related issues. > I believe scanning in RAW mode would catch the virus; but, not many viruses written will use this encoding for the message. Remember the best virus spreads through simplicity and not complexity. Making up an obscure coding scheme to spread a virus is in effect silly. >> Sigtool is primarily a tool for signature database developers and by no means >> it was designed to be run with SUID/SGID bits set. There is no practical >> exploitation of this "vulnerability" and it should not be considered >> a security issue. > > It doesn't need to be run with SUID/SGID bits set. Ever heard about > symlink attacks? Especially juicy in directories such as /tmp. And it > even works when you and the attacker are both unprivileged users. One > symlink at the right moment, and your data is fucked. Overwritten by a > command issued by yourself. symbolic links do not give users permission to overwrite files and directories at will. If so, then there would be kernel patches quickly in place to prevent this maneuver.!!!
> > It's not a big deal to fix those things and make your users secure, so > stop denying that there are problems with the existing code, and go > fix them. Point taken; but, you have to evaluate if the fixes actually address the problem or make more problems. - -James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHfAEGkNLDmnu1kSkRArKuAJ44AsgZXz6dWNDLSwjx80bo8dRo4QCbB50d LDVOyGDuGvEasPEKstNp/zA= =sozl -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
