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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Buena Sent: Wednesday, December 27, 2006 7:54 AM To: James D. Stallard Cc: Harlan Carvey; Thor (Hammer of God); [email protected] 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 <[EMAIL PROTECTED]> wrote: > Harlan > > Firstly, no, I have no evidence of the behaviour. It was only ever a theory > based on the idea of a buffer overflow ocurring during an automated process. > My reference to the JPEG GDI+ issue was only given as an example of the fact > 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 concept. > > Incidentally, the chap that discovered the GDI+ issue deserves our respect > as having demonstrated a beautiful piece of lateral thinking. After all, the > idea that a graphics file could infect a host machine is against everything > 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 bitmap, > with a different file extension. This still works and you can demonstrate it > yourself by creating a 32x32 .BMP file with your favourite paint program and > once saved, change the file extension to .ICO. The file will still work, and > 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 vector. > > 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! > > Cheers > > James > James D. Stallard > > > > > -----Original Message----- > From: Harlan Carvey [mailto:[EMAIL PROTECTED] > 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 as > 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 > unchecked. > > 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. > > Thanks, > > Harlan > > > ------------------------------------------ > Harlan Carvey, CISSP > "Windows Forensics and Incident Recovery" > http://www.windows-ir.com > http://windowsir.blogspot.com > ------------------------------------------ > > > > --------------------------------------------------------------------------- > --------------------------------------------------------------------------- > >
