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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3F2FC7B3.10655.272BEFE0@localhost>
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ