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>] [day] [month] [year] [list]
Date: Fri Oct 28 19:19:05 2005
From: x at blackopssec.com (x)
Subject: Re: Multiple Vendor Anti-Virus Software
	DetectionEvasion Vulnerability through forged magic byte


Bipin Gautam said:
+ > Consequently, the issue that you describe is *not* a
+ > vulnerability issue, but rather just an example of a new
+ > variant that has not yet been added to an AV vendor's 
+ > database of "known viruses".
+ 
+ yap, maybe* but i consider this issue equv. to the 
+ 'classic issue' of adding NOP to the shell-code to bypass 
+ IDS/IPS You ain't gonna add every possible combinations 
+ as signatures!

That is true, but the key point is that you _don't have_ to
add a sig for every possible combination.  You only have to 
add a sig when somebody actually releases a functioning
"variant" into the wild.  Or, if your AV scanner uses
heuristic / rules-based scanning by default, you can just 
write a rule to detect most/all of the combinations.
And this is exactly the way IDS/IPS works too.  They don't
write sigs for every theoretically possible vulnerability
or threat; they just write sigs/rules for known exploits
and vulnerabilities, and for theoretical issues that have 
a good probability of showing up in the wild.  So, the AV 
vendors wouldn't have to do anything unless somebody 
actually created a working variant of a virus based on this 
magic byte concept, and released it into the wild.

+ Variant huh?
+
+ My defination of variant are bit straight forward. And 
+ sure isn't a 'universal trick' that can be used to 
+ modified any malicious executable (which has known Av 
+ signature)  by a 8 year old with 0 programming knowledge 
+ or by using any special tools to make it un-detectable, 
+ later. Admit it... Av vendors aren't going to 
+ doyuble/tripple their Av defination to detect all of such
+ possible varient. Common, is the execution point of ANY 
+ instruction code or program flow is being changed?

See above.

8 year olds?  Considering the maturity of current "virus
creation toolkits", I have no doubt that 8 year olds with
no programming skills are pointing and clicking to create
new viruses.

All that said, if an AV vendor can fix this issue by
easily creating patches for all of their products, then
great.  I'm simply stating that the issue can be 
effectively, and probably more easily, fixed too by 
creating new signatures or rules.  I bet this is how most 
vendors will handle the issue now.  Remember: the AV 
vendors only have to write signatures/rules if Andrey, or 
somebody else, actually creates a functioning "variant" 
and releases it into the wild.

Andrey Bayora said:
+ > The AV vendors aren't going to patch their products if 
+ > they don't detect your PoC; they're just going to write a 
+ > new signature or modify an existing signature to detect 
+ > your new variants.  The fact that it can and will be 
+ > fixed by AV signatures instead of product patches should 
+ > help you figure out if this is a product vulnerability 
+ > issue or just a "new virus variant" issue.
+ 
+ Good point, so I have news for you - some AV vendors 
+ contacted me and they are WILL issue patches for their 
+ products. Is it what you need as a proof of existence of 
+ a bug? Please, wait couple of weeks.

Cool - there's more than one way to skin a virus.  As long
as they take action when necessary to mitigate the actual /
real risks.
 
+ > BTW, Andrey, did you bother to use the "deep scan",
+ > "heuristic mode", "reviewer mode", etc to see if any
+ > of those AV scanners picked up your new variants?
+ 
+ YES, that is the reason why I prefer to use my AV lab 
+ instead of virustotal.com and others. The only exception 
+ is CA - I tested 7.0 version that didn't has "reviewer 
+ mode" (or I didn't found how to enable this).

None of the 15 vendors you listed as vulnerable had any 
sort of "deep scan" or heuristic mode that detected your
variants?

+ Best regards,
+ Andrey Bayora.

Bottom line:  the issue you have discovered/reported is
just one of zillions of theoretical attacks / viruses / 
variants.  The "known virus" AV vendors only need to 
address the actual viruses/variants that make it into the 
wild or are sent to them.  This is the way most AV, and
heck even network security, products work.  They only 
address the real or probable threats.  If they tried to 
address all of the theoretical stuff too, their products 
- and even the internet - would grind to a halt 
(nightmares like TCP/IP, SMTP Win32, etc insure this).

IMO, the best solution for this, and all other AV issues,
is to just lock down a *BSD or linux box and use that 
instead.  We can probably all agree on that.

--
x @ bos


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ