[<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