F-Prot bypass/evasion - ZIP Method Field

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


This bug was reported 4 years ago [1] 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.

[1] CVE-2005-3499
http://www.zoller.lu/research/fprot.htm
http://web.nvd.nist.gov/view/vuln/detail?execution=e3s1

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 gateway 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 of engine)
• F-PROT Antivirus for Linux x86 File Servers : (High: complete bypass of engine)
• 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 peers.

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.

I. Background
FRISK Software International, established in 1993, is one of the world's leading companies in antivirus research and product development. 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.

II. Description
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.

III. Impact
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 ZIP file

The scanner denotes files that are passworded, an example is an E-mail Gatewayscanner 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. Additionally 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.

• 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

Yes.

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 engine released."
  

• 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
  

          No reply.
            

• 27/03/2009 : Resend.        

           No reply.            
           
No further coordination attempts will be done with FRISK in the future should they not revisit there position on security notification and response practices.