RE: U3 TEchnology was RE: strange new virus

Just thinking of a possibility here-what if the software were added to the
software restrictions GP. Or have you found that there is a way for U3
software to get around that Ryan?
Or does that seem unwieldy-especially if the U3 software has a ton of
versions or updates regularly.

-----Original Message-----
From: listbounce@xxxxxxxxxxxxxxxxx [mailto:listbounce@xxxxxxxxxxxxxxxxx] On
Behalf Of Ryan Buena
Sent: Wednesday, December 27, 2006 7:54 AM
To: James D. Stallard
Cc: Harlan Carvey; Thor (Hammer of God); focus-ms@xxxxxxxxxxxxxxxxx
Subject: Re: U3 TEchnology was RE: strange new virus

The U3 Hacksaw and Switchblade software are huge security threats to
companies. I have been researching it for a while now and cannot find
a viable way to detect or prevent these things from running. Though
you can disable autorun from windows via registry or group policy, if
the user inadvertently double clicks on the thumb drive in My
Computer, it will autorun the U3 software and cause it to get
infected. The best bet right now is Windows Vista which allows you to
lock down USB ports.

On 12/18/06, James D. Stallard <james@xxxxxxxxxxxxx> wrote:

Firstly, no, I have no evidence of the behaviour. It was only ever a
based on the idea of a buffer overflow ocurring during an automated
My reference to the JPEG GDI+ issue was only given as an example of the
that graphics files could be used as an attack vector. I probably do not
have the skills necessary to write an exploit or even to prove the

Incidentally, the chap that discovered the GDI+ issue deserves our respect
as having demonstrated a beautiful piece of lateral thinking. After all,
idea that a graphics file could infect a host machine is against
we learnt in the early days.

Secondly, I am interested in the file format for icon files as I remember
the old days of Windows 9x. As I remember, an ICO file was simply an
uncompressed memory map of bit values arranged in the correct dimensions
(originally, a 32x32 bit matrix). In other words an icon file was a
with a different file extension. This still works and you can demonstrate
yourself by creating a 32x32 .BMP file with your favourite paint program
once saved, change the file extension to .ICO. The file will still work,
it's content is now displayed as its icon.

However, the newer .ICO files that ship with XP (I tried \Program
Files\MSN\MSNCoreFiles\MSNMS.ICO as it's likely to exist on your systems
too) are no longer simply bitmaps and seem to have a different internal
structure - not explained by multiple versions of the same image at
different resolutions.

Therefore, I suspected that the file format is not standardised and there
might be room in there for something that could be used as an attack

The trouble is I am not an expert on ICO file formats (!) and none of the
icon files I inspected with a hex editor have any comments associated with
them (although a couple of animated GIFs contained all sorts of stuff ;) )

Returning to One of Thor's points about leverage a vector in the user
context. The risk is not really about leveraging in a given context, it's
about running something without user knowledge or intervention.

Interesting indeed, but very obscure!


James D. Stallard

-----Original Message-----
From: Harlan Carvey [mailto:keydet89@xxxxxxxxx]
Sent: 18 December 2006 20:12
To: James D. Stallard; 'Thor (Hammer of God)'
Subject: RE: U3 TEchnology was RE: strange new virus

James and Tim,

My theory is that if the Autorun.inf file is present, then the
enumeration process reads it and although it ignores the "open="
statement on media
marked as removable, it still processes the "icon="
statement - on my system
apparently regardless of whether autoplay is switched on or off.

Understood, and agreed...I've seen this myself.

A malformed .ICO file could conceivably cause the buffer overflow, and
might allow the situation to be taken advantage of - IE run arbitrary
code on the USB flashdisk.

Conceivably? James, do you have anything besides that to point to, such
a vulnerability to the image processing component that handles ico files?

As the autorun "ico=" statement is also capable of pulling icons
directly out of an executable, it seems plenty possible to hijack it -
provided the buffer overflow is

While I'm not discounting the possibility...after all, anything is
potentially possible...I am looking at this from an Occam's Razor
standpoint. Do you have anything other than "it happened with this image
format, it *couold* happen with another" to point to?
After all, I haven't been able to locate any standard for ico files (yet)
that mention comment fields (or any other fields) of the sort found in the
JPEG standard.



Harlan Carvey, CISSP
"Windows Forensics and Incident Recovery"