I am off for holidays for the next days :)

A little gimmick that made me smile, I recently wrote an email to a few Luxemburgish MEPs in order to protest against the imminent vote on an Internet regulation proposition (more info : http://www.blackouteurope.eu/)

Here is what I received yesterday :

Your message
To: HENNICOT-SCHOEPGES Erna
Subject: Telekom package -
Sent: Mon, 20 Apr 2009 15:49:06 +0200
was deleted without being read on Tue, 28 Apr 2009 23:24:10 +0200

Long live Microsoft Exchange default setups.

So long - off.

• [TZO-162009] Nod32 CAB bypass / evasion
• [TZO-172009] Trendmicro RAR,ZIP,CAB evasion (no patch)
• [TZO-182009] Mcafee RAR,ZIP multiple evasions
  

Comment:

I have received interesting and mixed feedback from posting the above "bug".

• First I'd like to clarify that a vulnerability is measured by the impact it causes, not how easy it is to find it and not by how technically challenging a vulnerability is.
  
  
• Secondly, vendors appear to not like it but remotely controlling the availability of an application is a security issue. It is the A in the CIA concept. If you are interested in that discussion I wrote a small blog rant about the "Denial of service is not a security issue" mindset of certain vendors.
  
  
• Is this bug a vulnerability? - yes. Is is critical ? Clearly no. Stop seeing the world in Black or White. Something can be a vulnerability and still not be critical for the general public. However make no mistake, some bugs that are (for example) rated medium can become critical for certain companies that use the products in certain ways or critical parts of an infrastructure rely on that particular application.
  
  
• This is the reason I give no risk rating, what for ? I can't assess the risk an customer runs in specific environments when this vulnerability hits the product, I have no way to assess the risk whatsoever. I think it is highly misleading to have a vendor rate risk for a vulnerability. What I give is a description of the impact, with an description of the impact the customer of that product is actually able to assesses the risk, he is the only one that can.
  
  
• To illustrate this point take the bug above and think about several scenarios where this bug might actually pose a problem. Have one ? Fine. I have one too; what about for example Internet Kiosk vendors ? i.e the terminals at airports or cities that give access to the internet. Browse to the PoC and the terminal can no longer be used - so, for terminals offering pay for access service, this might mean actually income loss. (I am aware that some "restart" the whole OS or the envrionment periodicaly to clean up the mess left behind) Still I think you'll get the point here, there are a lot more scenarios like this.
  
  There is more then the typical End-user at home sitting before his pc that kills the process and restarts firefox.
  
  
• During my years doing security consultancy, one of the most astonishing things I learned is the immense variety of how applications are used by different companies. There is no way to summarise risk.
  

---

Release mode : Forced release

Ref : [TZO-27-2009] - Firefox Denial of Service (KEYGEN)

Vendor : http://www.firefox.com

Status : No patch

CVE : none provided

Credit : none

Bugzilla entry: https://bugzilla.mozilla.org/show_bug.cgi?id=469565

Security notification reaction rating : There wasn't any appropriate reaction.

Notification to patch window : x+n

Disclosure Policy : http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html


Affected products :
- Firefox 3.0.10 (Windows)
- probably all versions that support the keygen tag.

I. Background

Firefox is a popular internet browser from the Mozilla Corporation. In 2007 the Mozilla Corporation had a revenue of over 75 million dollars [1], out of which 68 million where made with a search advertising deal, in other words with the search box in Firefox that defaults to Google.

I envy the spirit of everyone that works on Firefox code in their spare time,for free.

II. Description

This bug is a simple design bug that results in an endless loop (and interesting memory leaks). Once upon a time Netscape thought it would be a great idea to add the keygen tag (KEYGEN) as a feature to their Browser. The keygen tag offers a simple way of automatically generating key material using various algorithms. For instance it is possible to generate RSA, DSA and EC key material.

"The public key and challenge string are DER encoded as PublicKeyAndChallenge and then digitally signed with the private key to produce a SignedPublicKeyAndChallenge. The SignedPublicKeyAndChallenge is base64 encoded, and the ASCII data is finally submitted to the server as the value of a name-value pair, where the name is specified by the NAME attribute of the KEYGEN tag."

More information: https://developer.mozilla.org/En/HTML/HTML_Extensions/KEYGEN_Tag

This feature includes the automatic submission of the public part to a script, the crux. The Keygen tag reloads the document by submiting the public key as an argument to the current URI. Combining this with a javascript body onload() call (or meta refresh) results in an neat endless loop blocking access to the UI.

Furthermore memory is leaked during the process.

III. Impact

The browser doesn't respond any longer to any user input, tabs are no longer accessible, your work if any might be lost. According to a Bugzilla entry memory is also leaked during the process.

So let's recap, we have a function that generates key material and looping causes memory to leak. One might think this should be important enough to investigate, especially if you know that for DSA for instance, only a few bits of k can reveal an entire private key. [3]

Note: I am not saying the memory leaks include key material, seeing the lack of interest this bugzilla ticket triggered, I have not considered investigating further. What I am saying is that if security is taken seriously such bugs need to be investigated thoroughly.

IV. Proof of concept

Link to POC


IV. Disclosure timeline

DD/MM/YYYY

• 14/12/2008 : Created bugzilla entry (security) with (the wrong) proof of concept file.
  
  
• 14/12/2008 : Attached the correct POC file (mea culpa) and a stack trace and details of memory corruption that repeatitly occured during testing the POC
  
  
• 24/12/2008 : dveditz@mozilla.com comments : "I can definitely confirm the denial of service aspect, and there's a very minor memory leak (after 9 hours of CPU time memory use went from 60MB to 360MB). Haven't been able to reproduce a crash."
  
  
• 27/05/2009 : The 4 month grace period [2] given is reached. Release of this advisory.

[1]http://www.mozilla.org/foundation/documents/mf-2007-audited-financial-statement.pdf
http://www.guidestar.org/FinDocuments//2007/200/097/2007-200097189-047bbaa9-9.pdf
[2]http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html
[3]http://rdist.root.org/?s=dsa

• [TZO-13-2009] Avira Antivir ZIP evasion
  
• [TZO-14-2009] Comodo RAR evasion
  
• [TZO-15-2009] Aladdin eSafe generic evasion / bypass (forced release)

Update: Aladdin got in contact

Update: People failing to reproduce most likely don't use the xhtml extension when saving the file. Click here to test.

Update: A bug with the same root cause has been reported in 2007 by the infamous Guninsky to Mozilla.


Release mode: Forced release.
Ref : [TZO-26-2009] - Firefox DoS SVG
Vendor : http://www.firefox.com
Status : No patch
CVE : none provided
Credit : none
Bugzilla entry: https://bugzilla.mozilla.org/show_bug.cgi?id=465615

Security notification reaction rating : There wasn't any appropriate reaction. OSS security FTW
Notification to patch window : x+n

Disclosure Policy : http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html

Affected products :
- Firefox all supporting SVG (didn't care to investigate which, task of the vendor)
- all software packages using mozilla engine and allowing SVG

---

I. Background
Firefox is a popular internet browser.

II. Description
This bug is a typical result of what we call unclamped loop. An "attacker"will give the Radius value of the Circle attribute a very big value. That is leetness.

Stack trace :
ntkrnlpa.exe+0x6e9ab
ntkrnlpa.exe!MmIsDriverVerifying+0xbb0
hal.dll+0x2ef2
xul.dll!NS_InvokeByIndex_P+0x30c36
xul.dll!NS_InvokeByIndex_P+0x30e8a
xul.dll!NS_InvokeByIndex_P+0x30e02
xul.dll!NS_InvokeByIndex_P+0x30f5e
xul.dll!XRE_InitEmbedding+0x7858
xul.dll!XRE_InitEmbedding+0xf4ee
xul.dll!XRE_TermEmbedding+0x11411
xul.dll!gfxTextRun::Draw+0xdd4d
xul.dll!gfxTextRun::Draw+0xe1ca
xul.dll!gfxWindowsPlatform::PrefChangedCallback+0x1495
xul.dll!gfxTextRun::SetSpaceGlyph+0x2678
xul.dll!gfxFont::NotifyLineBreaksChanged+0xf1d3
xul.dll!gfxWindowsPlatform::RunLoader+0xa9f6
xul.dll!NS_StringCopy_P+0x9942
xul.dll!gfxImageSurface::gfxImageSurface+0x3188
xul.dll!gfxImageSurface::gfxImageSurface+0x2ed8


Also produces exceptions in MOZCRT19...
MOZCRT19!modf+0x2570:
600715e0 660f122550450960 movlpd xmm4,qword ptr [MOZCRT19!exception::`vftable'+0x1a3d8 (60094550)] ds:0023:60094550=3fe62e42fefa39ef

III. Impact

Browser doesn't respond any longer to any user input, all tabs are no longer accessible, your work (hail to the web 2.0) if any might be lost.

IV. Proof of concept (hold your breath)

Click to enlarge

IV. Disclosure timeline

DD/MM/YYYY

• 18/11/2008 : Created bugzilla entry (security) with proof of concept,description the terms under which ooperate and the planned disclosure date.
• 24/22/2008 : Daniel Veditz comments : "Might be a cairo bug rather than SVG(seems to be looping in libthebes), but I can definitely confirm the DoS.
• 14/12/2008 : Ask for any action plan and my assessement of considering it low risk
  
  No reply.
  

• 28/12/2008 : "Timeless" comments [..] personally, i intend to open this bugto the public [..] a bug like this is more likely to be fixed by being visible to more people than by leaving it in a closet.

• 26/05/2009 : In 2009 I agree; release of this advisory.

Dear Thierry, why are you such an arrogant asshole?
I don't think I am.

That question really arrived in my inbox, in relation to the recent advisories and forced disclosures [1],[2] . Forced disclosure means that since the vendor hasn't reacted I consider myself forced, (ethically, because you don't want customer to run the risk of not knowing) to disclose the issue. In the last month this happened for Avast, IBM and Fortinet. (In all fairness, fortinet actually replied to my third try to reach them)


Let me get you up to speed: The disclosure policy that I adhere to didn't spontaneously spring out of my head, it is based on Secunias' policy. 

As I have reported quite some bugs in the recent years, and faced some problems with certain vendors, it immediately pleased my mind. I made some changes to it and there it was. It is straight forward and fair. It gives the vendor the chance to react, test their code, share their insight. If however the vendor does not answer this proves that either the vendor doesn't care about the security of their customers or that the vendor has simply not received the mail. 

This however is not really an excuse, the international standard addresses for security notification reports are well known (secure@ / security@) furthermore, repositories such as OSVDB exist where vendors can (an should) enter their security email address should it differ from the standard addresses - see, it's not the "researchers" fault if there was no reply, or reception.

Actually in my experience it's most often the vendor that simply ignores your e-mail and/or silently patches the bug in the next release.

So why do I do it then :

1. You see, responsibly disclosure goes both ways, and several vendors have yet to understand that. As a "researcher" you are bound to be responsible towards the vendor but also towards their customers and end-users. If there is a hole in a piece of code that runs at various customers, they should know they have that hole. If the vendor thinks that hole is minor, they should know the vendor thinks it's minor. If there are discrepancy in perception between the vendor and the "researcher", they also deserve to know. Not because the "researcher" is arrogant or suffers from delusions of grandeur, but the researcher thinks that the vendor has not had the complete oversight when rating the issue, and he wants the customers to know.
   
   Advisories are the essence on what risk management lies upon, no advisory and a risk manager lies in the dark about a particular issue. This by the way is also the reason why I think that the IMPACT of a vulnerability and a good description of it is often more important than releasing POC files and very detailed technical advisories.
   
   
2. Create the necessary business incentives for vendors invest in security vulnerabilities notification procedures, patch procedure, SDL processes and human capital. 
   
   Yes you read correctly, if we as "researchers" do not publish bugs, including verbose time lines and how vendors reacted, there is nearly no (apparent) business incentive for a vendor to create such teams and procedures. Why do I say that there would be no incentive. Simple, it's not visible, how often do you have reported a vulnerability ?
   
   Here is something that should be of interest to you: Customers (and mainly large enterprise customers) absolutely love reading vulnerability notification time lines. It proves or disproves that the million dollar license fees they invested in a company's' product is a good investment that the vendor really cares about the security of their products (and hence the customer) and it gives direct insight on how long it takes them to react.
   
   At this point everything comes together, customers that are interested in holding their vendor to account have then grounds to ask for a more professional approach, sometimes even considering a change to another vendor. This is what creates the very business incentive that I want to see. If it worked with Microsoft it works with everybody. Ask them.
   
   
3. And this leads me to another reason why the policy is more aggressive than that of Rain Forest Puppy. Vendors do silently patch. They take your notification, don't reply and magically the problem is gone in the next version. If you ask them - if they reply at all - they claim it has been found during internal tests. However it is common practice that even rediscoveries are credited - some however don't.
   
   
4. Free labor. I expect a certain degree of professionalism - reporting vulnerabilities is am doing free work for a company that make millions. Discovering and coordinating  vulnerabilities  is free work. I have not introduced those vulnerabilities in the first place, if they are within the product of the vendor, it's because you either didn't invest in controls or their controls failed. In any case, it's their problem.
   
   
5. NOT doing so is unfair to vendors that do respect researchers, invest money, time and effort. I have reported over 900 vulnerabilities in products, out of those 900 only 1% were voluntarily published by the vendor without me publishing first. I am able to tell due to particular circumstances.
   
   And where did that lead us to? Screwed statistics and false assumptions.
   
   Charts displaying that one vendor was being "more vulnerable" than another, when in fact it is exactly the opposite. Vendors hat did not publish their vulnerabilities had a lot more holes then those that published. And that, in my book, is not an acceptable situation towards a vendor that respected both researcher and their customers.
   
   An it is this very fact that  lead me to the conclusion that everything even the low priority issues deserve disclosure, especially if the vendor doesn't answer.

Why are there two panda advisories instead of one ? See
http://blog.zoller.lu/2009/05/100th-post-what-about-big-guys.html

Release mode: Coordinated but limited disclosure.

Ref : TZO-25-2009 - Panda generic evasion (TAR)

Vendor : http://www.pandasecurity.com

Status : Patched (Through hotfix and automatic update)

CVE : none provided

OSVDB listing: No [1]

Credit :

http://www.pandasecurity.com/homeusers/support/card?id=80060&idIdioma=2

http://www.pandasecurity.com/homeusers/support/card?id=60039&idIdioma=2

http://www.pandasecurity.com/homeusers/support/card?id=70025&idIdioma=2

Security notification reaction rating : Good

Notification to patch window : +-22 days

Disclosure Policy :http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html

Affected products :

• Global Protection 2009 (Hotifx)
• Internet Security 2009 (Hotifx)
• Panda Antivirus Pro 2009 (Hotfix)
• Panda Security for Business with Exchange
• Panda Security for Business
• Panda Security for Enterprise
• Panda GateDefender Integra (patched through automatic updates)
• Panda GateDefender Performa (patched through automatic updates)
• Panda AdminSecure (patched thorugh automatic updates)

SaaS

• Panda Managed Office Protection
• TrustLayer Mail

Quote : "What virus protection guarantees does TrustLayer offer? With respect to the antivirus filtering service, TrustLayer offers a 100% virus-free contractual guarantee."

I. Background

Quote: "Panda Security is one of the world's leading creators and developers of technologies, products and services for keeping clients' IT resources free from viruses and other computer threats at the lowest possible Total Cost of Ownership."

II. Description

The parsing engine can be bypassed by a specially crafted TAR archive.

III. Impact
A general description of the impact and nature of AV Bypasses/evasions
can be read at :http://blog.zoller.lu/2009/04/case-for-av-bypassesevasions.html

The bug results in denying the engine the possibility to inspect code within TAR archives. There is no inspection of the content at all and hence the impossibility to detect malicious code.

IV. Disclosure timeline

DD/MM/YYYY

• 28/04/2009 : Sent proof of concept TAR, description the terms under which I cooperate and the planned disclosure date
  
  
• 07/05/2009 : Resent POC, description and terms
  
  
• 11/05/2009 : Inform Panda that his is my last attempt to contact them and that I will publish the information on the 20th of Mai.
  
  
• 11/05/2009 : Panda informes me that they are still evaluating and fixing release dates and asks for more time.
  
  
• 11/05/2009 : Panda states that they send me a fix for the TAR bug in order to cross check it fixes the problem.
  
  
• 21/05/2009 : Panda informs me of the release of hotfixes and affected Products.
  
  
• 22/05/2009 : Ask for clarification on affected products
  
  
• 22/05/2009 : Release of this advisory.

Why are there two panda advisories instead of one ? See http://blog.zoller.lu/2009/05/100th-post-what-about-big-guys.html

Release mode: Coordinated but limited disclosure.

Ref         : TZO-24-2009 - Panda generic evasion (CAB)
Vendor      : http://www.pandasecurity.com
Status      : Patched (Through hotfix and automatic update)
CVE         : none provided
OSVDB listing: No [1]
Credit :
http://www.pandasecurity.com/homeusers/support/card?id=80060&idIdioma=2
http://www.pandasecurity.com/homeusers/support/card?id=60039&idIdioma=2
http://www.pandasecurity.com/homeusers/support/card?id=70025&idIdioma=2

Security notification reaction rating : Good
Notification to patch window : +-32 days

Disclosure Policy : http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html

Affected products :

• Global Protection 2009 (Hotifx)
• Internet Security 2009 (Hotifx)
• Panda Antivirus Pro 2009 (Hotfix)
• Panda Security for Business with Exchange
• Panda Security for Business
• Panda Security for Enterprise
• Panda GateDefender Integra (patched through automatic updates)
• Panda GateDefender Performa (patched through automatic updates)
• Panda AdminSecure (patched thorugh automatic updates)
  

SaaS

• Panda Managed Office Protection
• TrustLayer Mail

Quote : "What virus protection guarantees does TrustLayer offer? With respect to the antivirus filtering service, TrustLayer offers a 100% virus-free contractual guarantee."

I. Background
Quote: "Panda Security is one of the world's leading creators and developers of technologies, products and services for keeping clients' IT resources free from viruses and other computer threats at the lowest possible Total Cost of Ownership."

II. Description

The parsing engine can be bypassed by a specially crafted CAB archive.

III. Impact

A general description of the impact and nature of AV Bypasses/evasions can be read at :
http://blog.zoller.lu/2009/04/case-for-av-bypassesevasions.html

The bug results in denying the engine the possibility to inspect code within CAB archives. There is no inspection of the content at all and hence the impossibility to detect malicious code.

IV. Disclosure timeline
DD/MM/YYYY

• 13/04/2009 : Send proof of concept CAB, description the terms under which I cooperate and the planned disclosure date
  
  
• 13/04/2009 : Panda acks receipt and starts investigating
  
  
• 15/04/2009 : Panda denies DoS and bypass condition and considers the bug a reporting issue as a MAX Size rule blocks the sample.
  
  
• 16/04/2009 : Ask if the Gatedefender product ranges, detects, flags or blocks the POC file.
  
  
• 17/04/2009 : Provide a new POC file to Panda that aims at evading the Max Size rule and detection.
  
  
• 17/04/2009 : Panda acks receipt and will investigate.
  
  
• 20/04/2009 : Inform Panda that I sent the wrong POC on the 17/04/2009 and attached the correct one.
  
  
• 28/04/2009 : Ping Panda for updates
  
  
• 28/04/2009 : Panda states that they are planning the patch timeline and will inform me asap.
  
  
• 21/05/2009 : Panda informs me of the release of hotfixes and affected Products.
  
  
• 22/05/2009 : Ask for clarification on affected products
  
  
• 22/05/2009 : Release of this advisory.
  

• [TZO 122009] SUN / ORACLE JVM Remote code execution

Release mode: Coordinated but limited disclosure.

Ref : [TZO-23-2009] - Bitdefender generic PDF evasion (heuristics)

Vendor : http://www.bitdefender.com

Status : Patched (with sig update after 13.05.2009)

CVE : none provided

Credit : none

OSVDB vendor entry: none [1]

Security notification reaction rating : good

Notification to patch window : 5 days

Disclosure Policy : http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html

Affected products :

• Bitdefender Antivirus 2009
• Bitdefender Internet Security 2009
• Bitdefender Total Security 2009
• Bitdefender Small Office Security
• Bitdefender for Fileservers
• Bitdefender for Samba
• Bitdefender for Sharepoint
• Bitdefender Security for Exchange
• Bitdefender Security for Mailservers
• Bitdefender for ISA Servers
• Bitdefender Client security

Bundles:

• BitDefender Business Security
• Bitdefender Antivirus for Unices
• Bitdefender Corporate Security
• Bitdefender SBS Security

I. Background

Quote: "BitDefender™ provides security solutions to satisfy the protection requirements of today's computing environment, delivering effective threat management for over 41 million home and corporate users in more than 100 countries. BitDefender, a division of SOFTWIN, is headquartered in Bucharest, Romania and has offices in Tettnang, Germany, Barcelona, United Kingdom, Denmark, Spain and Fort Lauderdale (FL), USA."


II. Description

The heuristics can be bypassed by a special formated PDF "container", this leads to the bypass of malicious PDF files, old or new. This is not a bypass that relies on archive structures but relies on evading certaincode paths in the av engine "through various means".


III. Impact

To know more about the impact and type of "evasion", I updated the description at http://blog.zoller.lu/2009/04/case-for-av-bypassesevasions.html

Interestingly this opens the possibilty to evade at scan time andrun-time.


IV. Disclosure timeline

DD/MM/YYYY

• 08/05/2009 : Send proof of concept, description the terms under which I cooperate and the planned disclosure date.
• 13/05/2009 : Bitdefender notifies my that the patch was deployed.

[1]
Bitdefender is encouraged to leave their security contact details at
http://osvdb.org/vendor/1/SOFTWIN to facilate communication and reduce lost reports.

Release mode: Coordinated but limited disclosure.

Ref : [TZO-22-2009] - Avira Antivir generic PDF evasion (heuristics)

Vendor : http://www.avira.com

Status : Patched (Engine-Version: AV7 7.9.0.168 / AV8/9: 8.2.0.168)

CVE : none provided

Credit : t.b.a

OSVDB vendor entry: none [1]

Security notification reaction rating : good

Notification to patch window : 10 days

Disclosure Policy :http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html

Affected products :

•  Avira AntiVir Free
• Avira AntiVir Premium
• Avira AntiVir Premium Security Suite
• Avira AntiVir Professional (Desktop)
• Avira AntiVir Server
• Avira AntiVir Exchange
• Avira AntiVir SharePoint
• Avira AntiVir ISA Server
• Avira AntiVir MIMEsweeper
• Avira AntiVir for KEN! 4
• Avira AntiVir Virus Scan Adapter for SAP NetWeaver®
• Avira AntiVir Professional (Unix)
• Avira AntiVir Server (Unix)
• Avira AntiVir MailGate
• Avira AntiVir WebGate

I. Background

Quote: "Avira AntiVir is a reliable free anti virus solution, that constantly and rapidly scans your computer for malicious programs such as viruses, Trojans, backdoor programs, hoaxes, worms, dialers etc. Monitors
every action executed by the user or the operating system and reacts promptly when a malicious program is detected. AV-Comparatives e.V. have chosen Avira AntiVir Premium as the best anti-virus solution of 2008"


II. Description

The heuristics can be bypassed by a special formated PDF "container", this leads to the bypass of malicious PDF files, old or new. This is not a bypass that relies on archive structures but relies on evading certain code paths in the av engine "through various means".

III. Impact

To know more about the impact and this "type of  evasion", I updated the description at http://blog.zoller.lu/2009/04/case-for-av-bypassesevasions.html 

Interestingly this opens the possibility to evade at scan time and run-time.


IV. Disclosure timeline

DD/MM/YYYY

• 08/05/2009 : Send proof of concept, description the terms under whichI cooperate and the planned disclosure date.
  
  
• 10/05/2009 : Avira acknowledges receipt.
  
  
• 11/05/2009 : Avira states that the internal development build has been patched and that the public updates are to be rolled out end of the week.
  
  
• 18/05/2009 : Avira informs me that "we already released the fixed engine to the public on friday, 15th May, 17:59 pm CET: Engine-Version: AV7 7.9.0.168 / AV8/9: 8.2.0.168
  
  
• 18/05/2009 : Release of this advisory.

[1]
Avira is encouraged to leave their security contact details at
http://osvdb.org/vendor/1/AVIRA%20GmbH to facilate communication and reduce lost reports.

Released a few advisories today :

• [TZO-08-2009] Bitdefender - Generic evasion (Limited details)
• [TZO-09-2009] Avast! - Generic evasion (Limited details) (UPDATED)
  
• [TZO-10-2009] Nod32 - Generic evasion (Limited details)
  
• [TZO-11-2009] Fortinet - Generic evasion (Limited details)

Update: Fortinet and Avast contacted me.

If somebody from Authentium, DrWeb, Netgear is reading this - get in touch.

I have been asked to provide a list of vendors that react and do patch bypass/evasions and acknowledge the (obvious) necessity to, here we go.

• F-Secure
• Avira
• Mcafee
• Securecomputing
• Ikarus
• Nod32
• Bitdefender
• Trendmicro
• Panda
• Computer Associates (CA)
• Comodo
• AVG
• Sophos
  

Companies that do not perceive the security risk involved - even for gateways :

• Avast (Alwil)

Coverage : Heise, DSL.sk , Security.nl , CNIS

A case for AV bypasses/evasions

In essence a bypass is simple to understand - a scanning engine (Anti-Virus, DLP, or other), that is the logic and code paths that detect if the content is malicious/blocked or not, are evaded.

This is not to be confused with the manipulation of existing malware in order to be no longer detected - these could be consider an "evasion" but only for that single sample - I do not consider these to be a security problem per se.

Evasions presented here are generic, meaning that they represent a generic method to evade detection and don't depend on content within the archive .

Changes :

• 04/2009 : Initial Publication
• 11/2019 :  Added Sections 5,  and 7 to the section on impacts.
  
  This method of evasion is now being exploited in the wild : https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/double-loaded-zip-file-delivers-nanocore/
  
  Unfortunately only a few AV companies have taken this bug class with the required seriousness and have either improved their parsers or have improved their detection logic.  It is over 10 years that I have reported both this class _and_ this particular vulnerability. Is the AV industry asleep behind the wheel .

Table of contents

1. Advisories
2. Generic evasions through archives
3. Generic evasions through indirectly influencing code paths
4. Common misconceptions about this "bug class"

1. Advisories
Here is a list of advisories disclosed by myself :

• [TZO-22-2009] Avira Antivir generic evasion (PDF)
• [TZO-23-2009] Bitdefender generic evasion (PDF)
• [TZO-20-2009] AVG ZIP bypass / evasion
• [TZO-21-2009] F-Prot CAB bypass / evasion
• [TZO-16-2009] Nod32 CAB bypass / evasion
• [TZO-17-2009] Trendmicro RAR,ZIP,CAB evasion (no patch)
• [TZO-18-2009] Mcafee RAR,ZIP multiple evasions
• [TZO-13-2009] Avira Antivir ZIP evasion
• [TZO-14-2009] Comodo RAR evasion
• [TZO-15-2009] Aladdin eSafe generic evasion / bypass
• [TZO-08-2009] Bitdefender - Generic evasion (Limited details)
• [TZO-09-2009] Avast! - Generic evasion (Limited details)
• [TZO-10-2009] Nod32 - Generic evasion (Limited details)
• [TZO-11-2009] Fortinet - Generic evasion (Limited details)
• [TZO-05-2009] ClamAV below 0.95 - Generic evasion (Limited disclosure)
• [TZO-06-2009] IBM Proventia - Generic evasion (Limited disclosure)
• [TZO-07-2009] F-Prot - ZIP Method evasion
• [TZO-001-2020] - AVIRA Generic Bypass (ISO)
• [TZO-002-2020] - Kaspersky Generic Bypass (ZIP)
• [TZO-003-2020] - ESET Generic Bypass (ZIP) - CVE-2020-9264
• [TZO-004-2020] - Bitdefender Generic Archive Bypass (GZ2)
• [TZO-005-2020] - Kaspersky Generic Bypass II (ZIP)
• [TZO-007-2020] - Bitdefender Generic Archive Bypass (ZIP)
• [TZO-008-2020] - Bitdefender Generic Archive Bypass (ZIP II)
• [TZO-009-2020] - Bitdefender Generic Archive Bypass (RAR I)
• [TZO-010-2020] - Bitdefender Generic Archive Bypass (RAR II)
• [TZO-011-2020] - ESET Generic Bypass (GZIP)
• [TZO-012-2020] - AVIRA Generic Bypass (ZIP)
• [TZO-013-2020] - AVIRA Generic AV Bypass (ZIP GPFLAG)
• [TZO-015-2020] - F-SECURE Generic Malformed Container bypass (RAR)
• [TZO-017-2020] - Kaspersky Generic Archive Bypass (ZIP FLNMLEN) 
• [TZO-018-2020] - Bitdefender Malformed Archive bypass (GZIP)
• [TZO-019-2020] - AVIRA Generic AV Bypass (ISO Container) - CVE-2020-9320

1. Evasions through archives

In essence a bypass is simple to understand - the AV scanning engine, that is the logic and code paths that detect if code is malicious or not, are evaded. This leads to the AV engine that cannot decompress , and hence analyse the file within the archive correctly but the end user is able to extract and run the file. This implies that the AV detection logic is effectively evaded. (See Figure 1)

The bug results in denying the engine the possibility to inspect code within the 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 referred 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.

This is not really new phenomenon, this "bug class" is known since 2004/2005 and not every Anti-virus vendor cared enough to close these apparent problems, or add a logic for gateway products to allow them to block bypasses on request.

The impact of this problem varies from engine to engine and from product to product and varies from how the product is used and relied upont within the context of each customer.

Some impacts however are common : 

1. Client side: Low impact for AV products using a real-time (on access) scanner, only few like clamav and f-prot do not have this capability. The reason why the impact is low, is that the engine is only evaded/bypassed on scan time (example:scheduled hard disc scan ) but not on runtime, when the user extracts the payload.


2. Server side: High impact for AV gateway products (E-mail, WWW etc.), since there is no user that extracts the file, it is impossible for gateway to inspect the code and the engine is completely bypassed. Only recently (after a wake up call and proposed solution by Sergio and myself in the presentation given at Hack.lu and Cansecwest "The Death of AV Defense in depth?") vendors started to built a logic into the products that enable the product to block archives they cannot extract. In this case the impact varies whether said option is enabled or disabled by default.


3. Server side: High impact for AV software on File servers, Database servers or scanners that scan remotely. Code is rarely actively extracted on these server by an end-user and as such the engine can be bypassed completely.


4. In cloud security services : High impact In cloud services usually don't scan user extracted data and as such are evaded completely. This is also one major reason why I think AV in the cloud is not going to work out, it fails as per design.


5. AI - Next Generation AV : The "intelligence" stops being intelligent when it isn't able to read inside the archive that contains the data to be analysed and doesn't take non-commonly structured archives as an additional indicator of a threat.


6. DLP Solutions : DLP solutions completely fail when unable to parse the content of an archive but are letting these through the perimeter.


7. Advanced Persistent Threats: Exfiltrating or infiltrating data can be done easier if inline and perimeter defences are unable to scan content or worse "fail open". Threat Hunting often relies on finding IOCs, some of which can be hidden away quite effectively using these methods. These evasion techniques can be part of an operation to stay undetected longer, which is what everyone agrees must be avoided.
   
   It is common for information security teams to take a "post breach" approach. That is that the information security strategy assumes that the attacker is already inside your network and build defences on the assumption they fail. Keep the window of exposure (ie Threat Agent inside the Network) to the shortest time frame possible requires you to act quickly. Techniques to lengten the detection window is an adversaries biggest asset.


8. Online services (Gmail, Hotmail, Yahooetc): High impact.
   It will be very interesting to see which companies will NOT patch their client side bugs and have these on-line AV services left useless. Example :

Below is a simplified logic of an AV engine detection logic (Image source: F-Secure - Link, ), as I annotated below the logic breaks once the file can't be extracted.

Figure 1. Evasion based on specially crafted archives.

I am aware that there are hundreds of ways to bypass using archives, that however doesn't make it less of a problem. This technique can be used and was actively being used, by malware to stay undetected over a longer period of time. The reason why the window of exposure is expanded is that,depending on the type of evasion a AV kernel update (engine update) is necessary and signature updates do not suffice. Resulting in longer window of exposure - at least for Gateway solutions.

2. Evasions through indirectly influencing code paths

Anti-virus products have been highly optimised (in terms of performance) in the recent years, one easy and logical way of doing such optimisations, is to separate your "analysis logic" in separate routines that trigger only on the respective file types. In other words, not all files are completely analysed and treated equally. For files determined to be PE executables for instance a special subset of routines and heuristics is triggered that catches this type of malware.

The evasion happens if you succeed in manipulating a format in such a way that the scanner thinks it is of another filetype. This leads to another branch of code (and hence logic) to be taken that often results in a complete bypass of the code necessary to detect the original malware. Sometimes a simply magic byte is enough, sometimes more elaborate manipulations must take place. Figure 2 shows the above explanations in graphical shape:

Figure 2. Evasion through indirect influence of code paths

The interesting part in this type of evasion is that sometimes they work scan-time and run-time as opposed the the evasions resulting from manipulating archives.

3. Common misconceptions about this "bug class"

• Misconception 1 : This has the same effect as adding a password to a ZIP file and as such is not a security problem.
  
  I disagree here is why :

1. An Gateway scanner explicitly flags archives that are passworded, an example is an E-mail Gateway scanner that adds "Attachment not scanned" to the subject line or in another location. It therefore indicates that the file was not scanned and as such you know that you have to be extra careful. This is not the case with bypasses, the engine does not indicate it has not scanned the attachment, in most cases the engine has not inspected the content at all or has inspected it in a different way.
   
   Furthermore passworded archive files are easily filterable by a content policy, allowing or denying them, so you have control over them, this is also not the case with bypasses.
2. Those that refute the problem with the argument that this has the same effect as adding a password to an archive, are completely missing the point. Malware/Worms that use passworded archives exist, the problem is that they have to indicate the password to extract the file within the mail. The result is highly suspicious email and an highly ineffective way of spreading wormable code. In fact it was so suspecious that most e-mail worm authors have dropped even using it. Further more, several AV vendors have added simple code to parse the mail for "password: xxxx" strings and try to extract the file on the gateway using that password.
   
   In other words, bypasses are the ideal solution for malware/worms authors to spread their code and have a more effective way of evading gateway scanners, and allow them to stay undedected longer (AV kernel update vs. Signature update) and to get their code deeper within the entreprise.

• Misconception 2 : The problem of bypasses is only an issue on 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.

• Misconception 3: This is not a security issue because if the gateway might be bypassed the the client-side AV will catch the malware on extraction of the archive.
  This argument makes the dangerous asumption that all Anti-virus scanners actually detect that particular malware (which is NOT necessarily the case, take a look at the virustotal.com stats). Most enterprises combine different vendors for the best results.  So imaging this scenario :

1. Gateway would have detected the malicious code (by signatures or heuristics) but it is bypassed
2. Client AV does not detect the sample because it doesn't have any signature
3. ?? oops
   
   This is, as anybody dealing with enterprise AV solutions knows is quite common, and not an unlikely scenario. If you want some proof, see the stats from virustotal for instance.

• Misconception 4: Behavioural analysis will catch this ?
  
  No, the content is unreadable to the AV engine as such no inspection whatsoever is possible.

• Misconception 5:These are not security issues, they are simple bugs.
  
  If you have read all of the above and still believe this to be true, note that my advisories never contain a risk rating, there is a good reason there is none : I can't assess the risk of an application running in a particular environment at customers. So I leave it to others to rate the risk of a bypass, customers and vulnerability databases.
  
  Hint: If there is a rating, it means it's a security issue.

1. NIST rate bypasses from a CVSS score of 5 to 10
2. XForce rate bypasses
3. Secunia rates it as low

I have been asked to provide a list of vendors that react and do patch bypass/evasions and acknowledge the (obvious) necessity to :

• F-Secure
• Avira
• Mcafee
• Securecomputing
• Ikarus
• Nod32
• Bitdefender
• Trendmicro
• Panda
• Computer Associates (CA)
• Comodo
• AVG
• Sophos
• Avast

CHEAP Plug :
************
You are invited to participate in HACK.LU 2009, a small but concentrated luxemburgish security conference. More information : http://www.hack.lu CFP is open, sponsorship is still possible and warmly welcomed!
************

Release mode: Coordinated but limited disclosure.
Ref         : [TZO-21-2009] - F-prot CAB bypass / evasion
Vendor      : http://www.f-prot.com
Status      : Current version not patched, next engine version patched Date unknown, vendor doesn't answer any longer.
CVE         : none provided
Credit      : none provided
OSVDB vendor entry: none [1]
Security notification reaction rating : better than last time
Notification to patch window : n+1 (no patch for current build)

Disclosure Policy : http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html

Affected products :

•  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)

OEM Partners affected :

• Autentium (all)

Command Software Systems, an Authentium company, has been developing and selling an antivirus solution utilizing the powerful F-PROT Antivirus engine since 1991.

OEM Partner unknown status :

•  Sendmail, Inc.
• G-Data

I. Background

Quote: "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 e-mail security service filters away the nuisance of spam e-mail 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 a specially crafted and formatted CAB (Filesize) archive.

III. Impact
A general description of the impact and nature of AV Bypasses/evasions can be read at :
http://blog.zoller.lu/2009/04/case-for-av-bypassesevasions.html

The bug results in denying the engine the possibility to inspect code within CAB archives. There is no inspection of the content at all and hence the impossibility to detect malicious code.


IV. Disclosure timeline
DD/MM/YYYY
10/04/2009 : Send proof of concept, description the terms under whichI cooperate and the planned disclosure date.

15/04/2009 : FRISK responds that they were unable to find any archiveprogram that is able to extract the file and that some archive programs tested suffer from an integer overflow extracting the file.

15/04/2009 : Inform FRISK that the sample should extract fine.

20/04/2009 : FRISK responds that they were unable to find any archive program that is able to extract the file.

20/04/2009 : Inform FRISK that the sample should extract fine.

22/04/2009 : FRISK responds that they were unable to find any archive program that is able to extract the file. However it will be patched nonetheless "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."

22/04/2009 : Sending FRISK a slightly modified POC (same field, different value) that extracts fine and still bypasses the engine. Ask vendor to confirm that the new engine catches the POC.

No Reply

27/04/2009 : Resending previous mail asking to check whether the patch has been effectively closed

No Reply

08/05/2009 : Release of this advisory.


[1]
F-prot is encouraged to leave their security contact details at http://osvdb.org/vendor/1/Frisk%20Software%20International to facilate communication and reduce lost reports.

CHEAP Plug :
****
You are invited to participate in HACK.LU 2009, a small but concentratedluxemburgish security conference. more information : http://www.hack.lu
****

Release mode: Coordinated but limited disclosure.
Ref : [TZO-20-2009] - AVG generic ZIP bypass / evasion
Vendor : http://www.AVG.com
Status : Patched (with engine build 8.5 323)
CVE : none provided
Credit : http://www.avg.com/223363
OSVDB vendor entry: none [1]

Security notification reaction rating : good

Notification to patch window : +-28 days

Comment: Interestingly at AVG, the support department handles the securitynotification response, which strangely seemed to work out this time. I guess when procedures and awareness are in place it doesn't matter that much. (You loose the "bouncer effect" for irrelevant reports though). I'd recommend to designate one person to be responsible to security related issues, and "train" the others to forward to that person (even in case of doubt if security or not) if you choose to have support department handle security notifications.


Disclosure Policy : http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html

Affected products :

• AVG Anti-Virus Network Edition (prior to engine build 8.5 323)
• AVG Internet Security Netzwerk Edition (prior to engine build 8.5 323)
• AVG Server Edition für Linux/FreeBSD (prior to engine build 8.5 323)
• AVG eMail Server Edition (prior to engine build 8.5 323)
• AVG File Server Edition (prior to engine build 8.5 323)
• AVG Internet Security SBS Edition (prior to engine build 8.5 323)
• AVG Anti-Virus SBS Edition (prior to engine build 8.5 323)
• AVG Anti-Virus plus Firewall (prior to engine build 8.5 323)
• AVG Anti-Virus (prior to engine build 8.5 323)
  

I. Background
Quote: "Founded in 1991, with corporate offices in Europe, the US and the UK, AVG is focused on providing home and business computer users with the most comprehensive and proactive protection against computer security threats.

With more than 80 million active users around the world, the AVG family of security software products is distributed globally through resellers and through the Web and supports all major operating systems and platforms."


II. Description
The parsing engine can be bypassed by a specially crafted and formatted ZIP (Filelenght) archive.

III. Impact
A general description of the impact and nature of AV Bypasses/evasions can be read at :
http://blog.zoller.lu/2009/04/case-for-av-bypassesevasions.html

The bug results in denying the engine the possibility to inspect code within RAR and ZIP archives. There is no inspection of the content at all and hence the impossibility to detect malicious code.


IV. Disclosure timeline
DD/MM/YYYY
10/04/2009 : Send proof of concept, description the terms under which
I cooperate and the planned disclosure date.

14/04/2009 : AVG acknowledges reproducibility

14/04/2009 : I inform AVG that this is a security notification not a simple
bug report.

15/04/2009 : AVG acknowledges through a second channel

15/04/2009 : AVG informs me that the fix has been made and the code is
currently being tested prior to being deployed.

15/04/2009 : Ask second channel AVG contact what versions and products
are affected.

no reply

07/05/2009 : Ask AVG wether the patches have now been deployed

08/05/2009 : AVG answers that the patches have been deployed

08/05/2009 : Ask AVG what versions have been affected

08/05/2009 : AVG states that "[..]AVG 8.5 build 285 are affected by this
issue but the latest release of AVG 8.5 build 323 has
resolved the reported issue.[..]"

08/05/2009 : Release of this advisory.


[1]
Grisoft (AVG) is encouraged to leave their security contact details at
http://osvdb.org/vendor/1/Grisoft to facilate communication and reduce
lost reports.

Released a few advisories today :

• [TZO-05-2009] ClamAV below 0.95 - Generic evasion (Limited disclosure)
• [TZO-06-2009] IBM Proventia - Generic evasion (Limited disclosure)
• [TZO-07-2009] F-Prot - ZIP Method evasion

Update : IBM is investigating.
Update 2: For those that do not understand the term "Limited disclosure".In this case it is meant to give the vendor another chance to react, as such you will not find the exact product name at this point in time, the list will be published in coordination with the vendor later.

Coverage : Heise, The Register, CNIS, Sid