Subject: Re: One problem in filetype.c in clamav0.90 - msg#00044

Previous Message by Date: click to view message preview

Re: One problem in filetype.c in clamav0.90

Gianluigi Tiesi wrote: > There is a reason if we (clamwin) changed this, we still prefer to skip > unknown files, and we don't need to care much about html and mail > files, so I've made some tweaks (not only this one) to save some > cpu cycles avoiding scan of unneeded files. > I'm aware that for a mail server scanner it's not the correct approach, > so in fact my post was only a "comment", it was never intended to > be in clamav tree. > A scan of a real pc hd can take ages, clamscan without any change > scans large avi files in raw mode (there is only a specific check for > anim riffs), other media files and e.g. iso files are also scanned in > raw mode. > 10-20gb of media/iso is not uncommon to find in a user pc, while > they are very unlikely to be in a mail. > Perhaps linux doesn't need itself to have a scanner for executable files > (linux but also the other unixes). Long ago we started implementing a list of types which are always considered not harmful. Unfortunately it seems that no file type is currently safe by default as demonstrated by the gif and jpeg exploits. Maybe we should now handle safe_by_default filetypes via DCONF, so, in case an exploit (for i.e. image/png) comes out we are able to scan it anyway? _______________________________________________ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net

Next Message by Date: click to view message preview

Re: Some programs stop building with clamav-0.90

Hello, On Sun, Feb 18, 2007 at 10:19:17PM +0200, Henrik Krohns wrote: > On Sun, Feb 18, 2007 at 03:25:41PM -0200, Renato Botelho wrote: > > After I upgraded clamav to 0.90 on FreeBSD ports, some other programs > > stop building. Here are them: > > > > Is there an easy way to fix it? > > cl_loaddbdir -> cl_load and add "CL_DB_STDOPT" as new parameter. > > Why isn't it left as compatibility in 0.90? It's almost the exact same call, > I don't get it. Now it's pretty harsh to all the programs out there. Why it is still named libclamav.so.1, if it is not binary and also not source compatible? And another question: Why these aliases are good for, if compatibility with older version is broken? /* aliases for backward compatibility */ #define CL_RAW CL_SCAN_RAW #define CL_ARCHIVE CL_SCAN_ARCHIVE #define CL_MAIL CL_SCAN_MAIL #define CL_OLE2 CL_SCAN_OLE2 #define CL_ENCRYPTED CL_SCAN_BLOCKENCRYPTED #define cl_node cl_engine Please, remove these old aliases or add some other to keep compatibility in source and binary forms. If it is not possible, is there ability to add my libclamav module for python to clamav sources? It is hard to build proper version of this module, if you don't know which clamav is installed on system. It requires Pyrex and python-devel to build. SAL _______________________________________________ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net

Previous Message by Thread: click to view message preview

Re: One problem in filetype.c in clamav0.90

Gianluigi Tiesi wrote: > There is a reason if we (clamwin) changed this, we still prefer to skip > unknown files, and we don't need to care much about html and mail > files, so I've made some tweaks (not only this one) to save some > cpu cycles avoiding scan of unneeded files. > I'm aware that for a mail server scanner it's not the correct approach, > so in fact my post was only a "comment", it was never intended to > be in clamav tree. > A scan of a real pc hd can take ages, clamscan without any change > scans large avi files in raw mode (there is only a specific check for > anim riffs), other media files and e.g. iso files are also scanned in > raw mode. > 10-20gb of media/iso is not uncommon to find in a user pc, while > they are very unlikely to be in a mail. > Perhaps linux doesn't need itself to have a scanner for executable files > (linux but also the other unixes). Long ago we started implementing a list of types which are always considered not harmful. Unfortunately it seems that no file type is currently safe by default as demonstrated by the gif and jpeg exploits. Maybe we should now handle safe_by_default filetypes via DCONF, so, in case an exploit (for i.e. image/png) comes out we are able to scan it anyway? _______________________________________________ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net

Next Message by Thread: click to view message preview

Re: One problem in filetype.c in clamav0.90

On Wed, 28 Feb 2007 11:28:38 +0800 "alex" <alex77@xxxxxxxxxxxx> wrote: > Dears all: > > I have read the source code of clamav 0.90 and found a strange code in > filetype.c. > > There is an expressioniIn 233 line of filetype.c : > > if(!iscntrl(buf[i]) && !isprint(buf[i]) && !internat[buf[i] & > 0xff]) > > and this expression would ALWAYS be false. > > I want to know if i am wrong ? Hi Alex, you're not wrong. The problem is however not a big issue because from the ClamAV point of view it's much more safe to assume that all files are of the type CL_TYPE_UNKNOWN_TEXT (it will have some performance drawbacks, though). The line 233 should read "if(!internat[buf[i]])" however I'm rather in favour of rewriting that check (to not depend on a single character but use some basic statistics instead) or dropping it completely. Otherwise, it may in some cases lead to false negatives or allow attackers to fool ClamAV very easily. Regards, -- oo ..... Tomasz Kojm <tkojm@xxxxxxxxxx> (\/)\......... http://www.ClamAV.net/gpg/tkojm.gpg \..........._ 0DCA5A08407D5288279DB43454822DC8985A444B //\ /\ Wed Feb 28 15:11:49 CET 2007 _______________________________________________ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net