Interesting People mailing list archives

more on Virus Scanners Made Moot By New Exploit?


From: David Farber <dave () farber net>
Date: Fri, 4 Nov 2005 18:44:20 -0500



Begin forwarded message:

From: Marc <marcaniballi () hotmail com>
Date: November 4, 2005 11:21:30 AM EST
To: dave () farber net
Subject: RE: [IP] Virus Scanners Made Moot By New Exploit?

Hi Dave;

While this news is disquieting, I can't help but notice that there is a
major player not listed in the list of vulnerable AV packages.

Symantec's Norton AV (and related suites).

Is this because they are not vulnerable, or is this just an accidental
omission? If the former, then the news isn't as perilous as one might think
reading this. If the latter, then is there someone on IP who can confirm
this?

Marc

-----Original Message-----
From: David Farber [mailto:dave () farber net]
Sent: Friday, November 04, 2005 8:04 AM
To: ip () v2 listbox com
Subject: [IP] Virus Scanners Made Moot By New Exploit?



Begin forwarded message:

From: Randall <rvh40 () insightbb com>
Date: November 3, 2005 10:44:01 PM EST
To: Dave <dave () farber net>
Subject: Virus Scanners Made Moot By New Exploit?

http://tinyurl.com/9zre5
Virus Scanners Made Moot by New Exploit
By Larry Loeb
November 3, 2005

Anti-virus software has always lived with the tradeoff of performance
versus thoroughness. It's led to some software design decisions on the
methods of how files are actually scanned that are now coming home to
roost.

Recently, researcher Andrey Bayora revealed that it is possible to fool
the scanners into thinking that a file under scan is one kind, when it
is in actuality something entirely different. Bayora (of
www.securityelf.org), a Russian-born Israeli, has issued an advisory
that details how to bypass many popular Windows AV programs.

Bayora says that he told vendors in July about what he found. He also
says that none of them ever got back to him. The exploit is fully
discussed in the white paper he wrote that is available at
www.securityelf.org/magicbyte.html.

The programs he found at risk for the exploit (followed by the CVE
number) are:

   * ArcaVir 2005 (engine 2005-06-03,vir def 2005-06-27, scanner ver
     2005-03-06, package ver 2005-06-21) (CVE-2005-3370)
   * AVG 7 (updates 24 June, ver.7.0.323, virus base 267.8.0/27)
     (CVE-2005-3371)
   * eTrust CA (ver 7.0.1.4, engine 11.9.1, vir sig. 9229)
     (CVE-2005-3372)
   * Dr.Web (v.4.32b, update 27.06.2005) (CVE-2005-3373)
   * F-Prot (ver. 3.16c, update 6/24/2005) (CVE-2005-3374)
   * Ikarus (latest demo version for DOS) (CVE-2005-3375)
   * Kaspersky (update 24 June, ver. 5.0.372) (CVE-2005-3376)
   * McAfee Internet Security Suite 7.1.5 (updates 25 June, ver 9.1.08,
     engine 4.4.00, dat 4.0.4519 6/22/2005) (CVE-2005-3377)
   * McAfee Corporate (updates 25 June, ver. 8.0.0 patch 10, vir def
     4521, engine 4400) (CVE-2005-3377)
   * Norman ( ver 5.81, engine 5.83.02, update 2005/06/23)
     (CVE-2005-3378)
   * TrendMicro PC-Cillin 2005 (ver 12.0.1244, engine 7.510.1002,
pattern
     2.701.00) (CVE-2005-3379)
   * TrendMicro OfficeScan (ver7.0, engine 7.510.1002, vir pattern
     2.701.00 6/23/2005) (CVE-2005-3379)
   * Panda Titanium 2005 (updates 24 June, ver 4.02.01) (CVE-2005-3380)
   * UNA - Ukrainian National Antivirus (ver. 1.83.2.16 kernel v.265)
     (CVE-2005-3381)
   * Sophos 3.91 (engine 2.28.4, virData 3.91) (CVE-2005-3382)
   * CAT-QuickHeal (ver 8.0)
   * Fortinet (2.48.0.0)
   * TheHacker (5.8.4.128)

Basically, the exploit prepends a header byte (he used "MZ"-the first
bytes of an EXE file) that convinces the scanner that the file is not
the type of file that the suffix averred that it was. The file types of
BAT, EXE and EML were postpended, and in his test suite could be
executed as any of the file types. So, what this points out is that
unrelated data can be prepended without preventing or adversely
affecting the execution/rendering of a file.

But there is another, more insidious problem that this technique
highlights. Because routine prepended data can be of variable length (as
it is in a JPG file) it is extremely difficult (or impossible) to locate
the original start offset of a file. It would seem that the only way out
of this is to scan the entire file for headers, which would greatly
decrease the throughput of the virus scanner.

By the way, Bayora says that in none of the cases tested was the
"detection signature" that is used by the AV scanners altered.

There seems to be no workaround, save a total redesign of how scanning
engines work.

Since the technique has been made public, I'd expect the first uses of
it to be fairly soon. Time for AV vendors to get on the stick here. Bad
times are on the horizon for them, and they are getting closer by the
day.

--




-------------------------------------
You are subscribed as marcaniballi () hotmail com
To manage your subscription, go to
  http://v2.listbox.com/member/?listname=ip

Archives at: http://www.interesting-people.org/archives/interesting- people/

-------------------------------------
You are subscribed as lists-ip () insecure org
To manage your subscription, go to
 http://v2.listbox.com/member/?listname=ip

Archives at: http://www.interesting-people.org/archives/interesting-people/


Current thread: