lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
From: nick at virus-l.demon.co.uk (Nick FitzGerald) Subject: f-prot not catching mimail ? psz@...hs.usyd.edu.au (Paul Szabo) wrote: > >>I cannot see anything "special" in the MIME structure of Mimail that would > >>cause f-prot to miss the ZIP attachment (or maybe it is the structure of > >>the ZIP that f-prot cannot unpack?). > > > > I was told its the encoding scheme in the .html file thats the problem. > > Currently the scanner does not support that type of encoding. > > It seems to me that the HTML contains the binary EXE without any encoding: > > $ cat -v message.html | fold | head -5 > MIME-Version: 1.0 > Content-Location:File://foo.exe What's that then? Moon dust???? > Content-Transfer-Encoding: binary Hmmmmm -- moon dust that thinks it's "binary encoded" even... > MZM-^P^@^C^@^@^@^D^@^@^@...?M-^?^@^@...^@^@^@^@^@^@^@@^@^@^@^@^@^@^@^@^@^@^@^@^@ Of course it is encoded. The file you are looking at is an MHTML format file that just happens to include a copy of the viral EXE as a MIME component that is "binary encoded". Sure there exists a "string" within the MHTML file that is a bit for bit copy of one instantiation of this virus, but it is not correct to say that the EXE is not encoded. Of course, the simple-minded view of how virus scanners work ("grep on steroids") would suggest that even so, the scanner should find this virus in this file because whatever "signature" or "scan string" the scanner is looking for must, by definition, be present in this MHTML file form. Of course, that ignores the horrendous performance penalty -- not to mention the impossibility of reliably detecting polymorphic and metamorphic viruses and many types of malware that exist in complex, multi-component file formats that mean the same code can have different representations -- of such a scanner and that no useful product has worked like that for a decade or so. The MIME "encoding" (the presence of the MIME headers at the top of the file) stops the scanner from seeing this as an EXE file, and quite rightly as it is not an EXE file. In turn, that prevents the file being processed and scanned as if it were an EXE -- a huge performance improvement you silently thank your AV vendors for every time you click a link in your web browser...). > Regardless, f-prot should list the ZIP attachment, and the files contained > within the ZIP ... I'm not sure I understand the comment or its relevance. If F-PROT is not listing the ZIP file nor the HTML file it contains, that may be the result of some configuration option. By default, F-PROT only lists "infected" files and as it is not "seeing" the EXE inside the MHTML (inside the ZIP attached to the Email message) I'm not sure I'd normally expect it to report the ZIP's presence unless some non-default logging options were enabled. -- Nick FitzGerald Computer Virus Consulting Ltd. Ph/FAX: +64 3 3529854
Powered by blists - more mailing lists