Trawling through the logs this evening, I totted up the total hits to this site: over 50,000 page hits as of 01/12/2006.
Blimey!
Page : 1/1
Thursday, 21 Dec 2006
This article originally appeared in Microsoft Security Focus. I've excerpted my original article and some of the responses to provide a more contiguous discussion.
Background:
The question was raised by a subscriber as to the behaviour of certain types of USB storage devices. Specifically, the U3 type device and it's apparent ability to autorun arbitrary code without user intervention. This is not known to be possible with a non-U3 device and despite the many copy-and-paste blogs on the subject by script kiddies trying to make themselves look like they know what they're talking about, has not actually been achieved in the wild. The conversation moved on to the possibility of arbitrarily executing code from a generic USB storage device *ON INSERTION* and subsequently developed into a theory on how this might be possible. The participants were Harlan C, Thor HOG and myself.
James DS Wrote:
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.
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.
Thor HOG Wrote (Quoting original):
> 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.
James DS Wrote:
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.
Thor HOG Wrote:
Ah- I see what you are saying. I didn't know that - I didn't know you could introduce content that way (i.e., via icon file), but it makes perfect sense. I'm glad you took the time to reply in detail...
And yes, I remember the JPEG issues, so you raise a good point. But since explorer.exe runs in the user context, I'm not sure levering a potential vector like that would "buy" you anything you wouldn't already get (and more
easily) from a U3 drive.
That being said, it is a good thing to keep in the back of our heads. If something came along (similar to the JPEG issue) that would yield Admin or SYSTEM, and you could do it from any old ghetto usb drive, that would really be quite cool. I mean, that would be very bad ;)
Interesting stuff...
Harlan C Wrote (Quoting Original):
> 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.
James DS Wrote:
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 leveraging 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!
End Article
1:23 AM
| Comments [0] | #Security
Monday, 18 Dec 2006
I recently got into one of those entertaining little email exchange of fire incidents with a chap I'll call Bob.
Bob has been transferred to another supplier as part of an outsourced service. Bob has been amazingly pissed about this and vents his spleen with undimished venom whenever an opportunity presents itself.
Bob is a hardline lefty, aggressive in his socialist stance to the point of religious mania, and impossible to contradict for fear of a sustained and personal attack.
I have been known to occasionally rattle Bob's cage for entertainment value. It's always been a giggle to sling him some bait and watch the resulting apoplexy. Several of my colleagues have egged me on and I confess, I am guilty of poking a pig with a stick. I shouldn’t I know, but believe me, you would too! I used to have a certain respect for his deeply held views and enjoyed the debate. However, after Bob's initial arguments had been dismissed, all that was left was an undercurrent of resentment and personal attacks ensued. This gets tired pretty quick and the only reason left to deal with him was for curiosity value. If you’re a Dilbert fan you'll recognise Bobs amazing resemblance to the occasional character, Peeved Eve.
Last time, I poked the pig with an email. It was only the most gentle ribbing, but Bob's unrequited fury at being transferred to another supplier caused him to come out full steam ahead and damn the torpedoes. The usual personal attack ensued (this time without a reasoned point of view) and with a good public audience on the CC list. I was still enjoying myself, so I let it run and was amused to be called a Moon Man (whatever the hell that is!) and a man with limited vision (amusing given what I do for a living!). For my part, I have never cared in the slightest about his opinions on anything, but it was fun to occasionally lift the rock and see what crawled out.
I have been asked nicely by someone senior to stop the poking as it turns out his reaction adversely affects the performance of the whole team, so this will sadly be the last time I do it - deliberately anyway. 
One or two people have asked me if Bob is a real person. Bob is a character I am considering developing to illustrate the angry nuts we all meet in the workplace. Bob is therefore a composite of a number of nuts I run into now and again. Any relationship between Bob and a living person is therefore in your imagination. After all, no-one is that odd - are they?
Friday, 1 Dec 2006
Is it just me or has the media coverage of the radioactive poisoning of Alexander Litvinenko excessive for the story. It is true that this is almost certainly a state sponsored assassination, and that the method is particularly cruel and unusual. It is also true that there is a small public health risk.
However, we are still at war in Iraq and Afghanistan, we are still peacekeeping in a dozen+ other countries and celebrities are still behaving badly. Odd then to watch any of the television news channels over the last few days and weeks and see almost none of the usual dross we are told is news. It is even possible that this one incident has received more broadcast time than the 7/7 bombings. One wonders why.
The political situation is interesting indeed.
The media clearly thinks that the guilty party is Mr Putin, but although implication is rife (even at the normally circumspect BBC) no one is coming out and saying "We know you did it, now explain yourself". Is this perhaps due to the current negotiations going on with Russia to secure Oil and Gas stocks for the coming decades? Maybe I'm seeing monsters where there are none, but something doesn't ring true here and we have yet to be shown what it is.
Blimey, I just had my "personal mobile telephony" bill.
You know you're busy when you have three SIM cards and the itemised bills for each device runs into 30 pages total! I think i'll change to summary bills, the amount of waste paper makes me feel guilty
