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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <41026291.14153.481216CE@localhost>
Date: Sat, 24 Jul 2004 13:22:25 +1200
From: Nick FitzGerald <nick@...us-l.demon.co.uk>
To: bugtraq@...urityfocus.com
Subject: Re: eSafe: Could this be exploited?


Hugo van der Kooij wrote:

> I had a bit of a chat with Aladdin support regarding the odd results I had
> with their network virusscanner (aka: eSafe). (see also:
> http://www.ealaddin.com/esafe/default.asp)
> 
> Both as NitroEngine or CVP server they will push as much of 80% to the
> end-user before they stop a virus.  ...

This is the common (and obvious as soon as you decide to try to 
implement something like this) "how do we keep the client from timing 
out" problem?  After all, unlike SMTP with its inherently "store and 
forward" mechanisms introducing several natural "pauses" during the 
transport of content, HTTP (like most other Internet protocols) is 
considerably more "real time"...

Another approach to solving this problem involves the use of some kind 
of agent at the client end.  Of course, that requires a greater degree 
of management and reduces the utility of the scanning service to those 
machines that are running the agent and otherwise properly 
configured...

> ...  Then they rely on the adding of the
> exact URL so that URL can be blocked in all next requests.
> 
> If it is a first time hit you can get as much as 80% of the payload on
> your machine and while they may reset the tcp stream at least IE does
> store the 80% chunk as if the file was transfered correctly. (This part I
> tested with over 30 different virus files.)
> 
> First off this is extremely confusing to the user who just thinks (s)he
> just had a virus passing their scanner. (And they are about 80% right.)
> 
> Then the chunk may contain enough to trigger another scanner which may
> reside on the desktop of said user adding further to the belief this is
> not a good product.
> 
> But what if I were to write a really small harmfull virus (say less then 2
> ethernet packets)? Or create it in such way that the last 20 to 25% is
> expendible without loosing it's sting?
> 
> Is someone able to verify such a virus may work? (I am not a programmer so
> I can think of the potential breach but I can't verify it is exploitable.)

In the Windows malware world there are some very small downloaders -- 
Windows executables around the 4-5KB size range (and a few even 
smaller).

Also, there are several quite widespread viruses that pad their .EXE 
files out with random amounts of random junk.  The Windows PE loader 
simply ignores additional "junk" on the end of a file ("extra" as 
judged by what the PE headers say should be there).  Whether any of 
these use as much as 20-25% padding I'm not sure (but suspect _not_) -- 
for now it seems that this technique is used because the virus writers 
seem to believe they'll bypass some useful proportion of content 
blocking gateways because the attachments of these viruses do not have 
constant CRC/MD5/etc (any gateway that is fooled by such a simple trick 
really should not be in production, so I guess there are probably only 
a few thousand such gateways out there...).

> I have a felling it is just a matter of time before such a scanner will be
> bypassed.

All scanners will always be (able to be) bypassed by something.  When 
you look at all the tricks the malware writers can use and that a 
scanner has to work around, you quickly realize that scanning is 
inherently inefficient.  To beat this the scanner developers implement 
all kinds of heuristics and shortcuts and imperfect "optimizations" to 
get performance back to acceptable levels.  Each scanner is chock full 
of tons of really, really fugly stuff you'd have kittens over if you 
knew.  The reason the scanner developers "get away with it" is because 
each does it differently -- the fuglies in NAV are mostly entirely 
different fuglies from those in the McAfee products which in turn are 
entirely different from those in all the other products.  (BTW, this is 
the primary reason why MS entering the AV market -- at least with an 
"integrated" or "built-in" virus scanner -- is a chronically stupid 
idea as then one set of AV stupidities will be really, really 
widespread and common, so researching and targeting just those 
weaknesses will be especially worthwhile for the VXers.  And, if that 
happens, MS will have to remove more and more of the shortcuts in its 
scanner, making it slower and slower and slower...)

So, all scanners are bypassable, but this seems a rather obvious bypass 
for this general approach to "web scanning".


-- 
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ