[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[TZO-07-2009] F-PROT ZIP Method evasion
From the low-hanging-fruit-department - F-PROT ZIP method evasion
Release mode: Coordinated.
Ref : TZO-07-2009 Fprot ZIP Method Evasion
WWW : http://blog.zoller.lu/
Vendor : http://www.f-prot.com
Security notification reaction rating : Mediocre-Poor
Disclosure Policy :
This bug was reported 4 years ago  to FRISK, the response at that
time has been that "a fix for this bug will be included in future
versions of F-Prot Antivirus". Fast forward 4 years the same error
still allow to bypass the engine.
Considering this and the reaction from FRISK I am unsure as how
serious FRISK is about the security of their clients.
Affected products :
- All Fprot versions currently used, vendor supplies no patch for
current release. The vendor (Frisk) considers this problem to be
too low priority to patch in current release and notify clients.
To put this in perspective, rendering the Fprot scanning on GW
solutions completely useless (for certain archive types)
is low priority for Frisk.
If you are a Frisk customer and concerned about security I would
recommend calling support and ask for a patch. NB, if you are using
FPROT localy and with ON access scans you are not affected.
Products (with impact details) :
- F-PROT AVES (High: complete bypass of engine)
- F-PROT Antivirus for Windows (unknown)
- F-PROT Antivirus for Windows on Mail Servers : (High: complete
bypass of engine)
- F-PROT Antivirus for Exchange (High: complete bypass of engine)
- F-PROT Antivirus for Linux x86 Mail Servers : (High: complete bypass
- F-PROT Antivirus for Linux x86 File Servers : (High: complete bypass
- F-PROT Antivirus for Solaris SPARC / Solaris x86 Mail Servers
(High: complete bypass of engine)
- F-PROT Milter - for example sendmail (High: complete bypass of engine)
- F-PROT Antivirus for Linux on IBM zSeries (S/390) (High: complete
bypass of engine)
- F-Prot Antivirus for Linux x86 Workstations (unknown)
About this advisory
I used to not report bugs publicly where a a vendor - has not reacted
to my notifications - silently patched. I also did not publish
low hanging fruits as they make you look silly in the eyes of your
Over the past years I had the chance to audit and test a lot of critical
infrastructures that (also) relied on products (and about security
notification from vendors) and have witnessed various ways of setting
up your defenses that make some bugs critical that you'd consider low,
I came to the conclusion that most bugs deserve disclosure.
Please see "Common misconceptions" for more information.
FRISK Software International, established in 1993, is one of the
world's leading companies in antivirus research and product
FRISK Software produces the hugely popular F-Prot Antivirus products
range offering unrivalled heuristic detection capabilities.
In addition to this, the F-Prot AVES managed online email security
service filters away the nuisance of spam email as well as viruses,
worms and other malware that increasingly clog up inboxes and
threaten data security.
The parsing engine can be bypassed by manipulating ZIP Method field.
It is as easy as opening a ZIP file in an editor and type a number
greater than 15 on your keyboard. Basically Fprot looks at the Method
field that indicates what method was used to compress the archive
and decides that it will not extract and inspect the data within.
The bug results in denying the engine the possibility to inspect
code within the ZIP archive. While the impact might be low client-
side (as code is inspected upon extraction by the user) the impact
for gateways or AV infrastructure where the archive is not extracted
is considerable. There is no inspection of the content at all, prior
disclosure therefore refered to this class of bugs as Denial of service
(you deny the service of the scan engine for that file) however I
choose to stick the terms of evasion/bypass, being the primary impact
of these types of bugs.
PS. I am aware that there are hundreds of ways to bypass, that however
doesn't make it less of a problem. I am waiting for the day where the
first worm uses these techniques to stay undetected over a longer
period of time, as depending on the evasion a kernel update (engine
update) is necessary and sig updates do not suffice. Resulting in
longer window of exposure - at least for GW solutions. *Must make
confiker reference here*
IV. Common misconceptions about this "bug class"
- This has the same effect as adding a password to a archive file
The scanner explicitely denotes files that are passworded, an example
is an Gateway scanner that adds "Attachment not scanned" to the
subject line or otherwise indicates that the file was not scanned.
This is not the case with bypasses, in most cases the engine has not
inspected the content at all or has inspected it in a different way.
Additional passworded archive files are easily filterable by a content
policy, allowing or denying them.
- This is only an issue with gateway products
Every environment where the archive is not actively extracted by
the end-user is affected. For example, fileservers, databases
etc. pp. Over the years I saw the strangest environments that
were affected by this type of "bug". My position is that customers
deserve better security than this.
- If this is exploited by a worm it will be fixed within minutes.
Some bypasses required modifications in the AV "kernel" and cannot be
fixed with a signature update. As such it would not only take longer
but for those customers that do no push binary updates immediately
(or not at all) increase the window of exposure consistently.
- Behavioral analysis will catch this ?
No, the content is unreadable to the AV engine as such no inspection
whatsoever is possible.
- Evasions are the Cross Site scripting of File formats bugs
IV. Disclosure timeline
23/03/2009 : Send proof of concept, description the terms under which
I cooperate and the planned disclosure date (02/04/2009)
26/03/2009 : Technical Support responds
"The fix for this was minor, with virtually no potential
for side effects - so it was added to the current
development branch for engine version 4.5 - being
low-priority, it will not be added to the 4.4 branch.
In other words, the fix will be included in the next
26/03/2009 : Replied, that
- the bug is 4 years old
- risk assesement is to be done by the client using
the engine one way or the other
- asked for location of advisory or credit
27/03/2009 : Resend.
No further coordination attempts will be done with FRISK should they not
revisit there position on security notification and response practices.