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:[EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> 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 --------------------------------------------------------------------------- ---------------------------------------------------------------------------
