Thor
I'm not sure I explained myself that well.
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.
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.
It would not be the first time a buffer overflow was used to take advantage
of duff processing of a graphics file, remember the GDI+ vulnerability
MS04-028 that did similar with JPEG files in late 2004?
The JPEG GDI+ vuln depended upon the content of the comment field within the
JGPEG file (described here:
http://marc.theaimsgroup.com/?l=bugtraq&m=109524346729948&q=raw).
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 unchecked.
Cheers
James
-----Original Message-----
From: Thor (Hammer of God) [mailto:thor@hammerofgod.com]
Sent: 18 December 2006 17:11
To: James D. Stallard; Focus-MS
Subject: Re: U3 TEchnology was RE: strange new virus
Hey James... inline:
On 12/15/06 5:07 PM, "James D. Stallard" <james@leafgrove.com> spoketh to
all:
Thor, et al
Question regarding autorun on USB flash disks (I never like the term
"thumbdrive"):
If you have a file in the root called "autorun.inf" and it contains a
valid syntax for an icon file, the icon will appear as the drive icon
in Windows Explorer. This most certainly works with XPSP2+patches.
Actually, you'll get a drive icon whether it has an autorun.inf or not...
That's just Windows identifying the device as a mountable drive. The
autorun doesn't do anything... Even with it present (on my systems) it
doesn't even ask you to run it.
The OS is clearly executing something, just not your arbitrary code.
The question is, would it be possible to take advantage of the icon
functionality (presumably within explorer.exe) to hijack the process
and run your own code? I'm thinking buffer overflow as the most likely
scenario, but I'm also thinking that following MS "trustworthy
computing initiative" and XPSP2, the existence of buffer overflow
possibilities in the OS is pretty minimal these days.
Well, that's the trick... Explorer.exe is just saying "This device mounted
as a drive letter, and here it is." Yes, it's "running code" (Actually, I
would guess that the code is already running and that it just renums
available drives by type) but as you said, it's not running any code on the
device itself.
Sure you could hijack the process, but that would mean that the OS was
already compromised in some way, or that you've already got code on the box
to do that (a rootkit could easily do this. Well, "easily" if you know how
;). But at that point, it's moot. I don't see how you could do that with
any data that requires it be loaded from the device to then exploit some
vector, even if such vector exists. But even if you could, and you really
wanted to go down that path, I think it would be easier to just get yourself
a U3 drive so that stuff like autorun would work by design.
t
---------------------------------------------------------------------------
---------------------------------------------------------------------------
