Help me understand this .wmf exploit a little better

Is this how the exploit loads and initiates when surfing. This assumes Joe Bloggs using Windows XP Home(SP2) and surfing with a vulnerable IE6.

I go to a Web page - embedded in that page is a container/iframe which may be invisible to the observer and contains a URL which calls up a .WMF file.

Good Example of a basic iframe in use:-

http://www.codetoad.com/html/frames/iframes.asp

Assuming it is not stopped by filtering/blocking this is then cached.

Once loaded client side it is designed to take advantage of Windows default behaviour and be opened either by the Microsoft Picture & Fax viewer, or an alternative viewer that makes use of the driver shimgvw.dll.

The point of all this being to have these programs/drivers in active memory space in order to take advantage of a buffer overflow weakness ?

In this case, to place in the vulnerable memory space a pointer to and/or a newly embedded instruction which is also placed in this exploitable memory space. The point being to instruct a download of whatever dodgy.exe is pointed to ?

Buffer overflows explained in easy terms:-

http://www.watchguard.com/infocenter/editorial/135136.asp

If so - is it the driver shimgvw.dll that is directly vulnerable to the exploit or is the driver simply an avenue to the Escape() function in gdi32.dll. This being the real weakness that creates the possibility for the exploit ?

This being the reason that the unofficial patch preventing the escape function is more valuable than un-registering the shimgvw.dll, which could potentially be re-registered by malware ?

Or have I missed the point totally ?

I was gonna post this privately to a member I trust for his comment - but I figure I'm so new to this and currently working on such a basic level that your responses may be useful to other people on the same level. Even if all I have said is wrong - I'm assuming now this framework has been provided - it can be corrected in a way that anyone can understand - even me.

 

I thought the wmf exploit has nothing to do with buffer overflows?

 

I had thought so:-

For instance from: http://vil.nai.com/vil/content/v_137760.htm

A more complete page which I had overlooked: http://www.kb.cert.org/vuls/id/181038

Bear in mind I have no indepth understanding and so taking things out of context is a danger for me at the moment. But I think these are valid.

 

Yours sounds like a good description. The two sources for buffer overflow are the same ones I have.

A good read to follow the action chronologically is at sans.org. Start here

http://isc.sans.org/diary.php?storyid=972

and just click on "next" at the bottom of each page.



________________
~~Be ALERT!!! ~~

 

Eyes-open, altough the term buffer overflow is used widely these days to almost mean exploit, if you read the description , in particular the part you quote it doesn't describe a buffer overflow at all.

It is a mistake in provding an additional function that is the problem.

If it's a buffer overflow, can you tell me if it's a heap or stack buffer overflow?

I would disregard the mcaffee url, they aren't 100% accurate particularly on technical issues which have no bearing on their jobs. The US-CERT report, as i said, does not describe an buffer overflow, though for some reason it mentions a buffer overflow lower down?

But other than that, i can't find any source that calls the exploit a buffer overflow, for example SANS FAQ doesn't mention it, neither does MS's advisory report or various security related blogs.

If it was a buffer overflow, you would expect, a mention at least. Also In prior cases of real buffer overflows they were mentioned as such in MS's advisories.....

 

Truthfully I can't with any confidence say you are wrong. I asked if my take was basically correct, based on what little I have read so far.

I had interpreted the exploit as a buffer overflow based partly on my very limited understanding of how they work, partly I think based on expectation and partly because the term had been used elsewhere.

Below is a direct link to a .pdf document titled:-

which illustrates the action of the exploit:-

http://www.section66.com/handlers/WMF.pdf

Below is from page 7 of the above .pdf

I think it is this action

that is most similar to the action of a buffer overflow exploit - that is the part where new illicit code replaces the original expected data ?

Honestly as I've said I'm very new and could be taking something way out of context. I won't mind having been proven to have been wrong - all I want to do is learn.

Thanks for taking the time to reply

eyes-open

 

After looking at it more, I'm 95% sure this exploit has nothing to do with buffer overflows as conventionally defined. Emperically, i've looked at a lot of security sites, and none of them mention anything about a buffer overflow, where normally they would if one was involved...

Logically...

I'm hardly an expert, but what you quote isn't necessarily a buffer overflow. Remote code execution would necessarily require some way to 'loop' back to executable shell code in the file.

The point is I don't see how this can be a buffer overflow if no buffers are affected? It's not like if the WMF file causes an overflow, it uses as ifar as I understand it a perfectly legimate function call without attempting to smash the stack. The problem of course is that this function should not be allowed but they forgot to remove it.

I spoke to a couple of people about 24 hours after the wmf exploit story broke (but before any analysis was available) and they told me explictly it was not a buffer overflow but simply a mistake in the way MS's handling of WMF. An overlooked function was as best as they could explain it to me.

This is certainly the wrong place to learn about such things. Wilders is a good place if you want to compare notes about security software, but wrong place otherwise for technical discussions particularly about exploits.

There are certainly people who do know better (mostly commercial guys and a few none associated people), but they seldom comment, though of course i would love to be proven wrong

 

I have to go and look for the link, but I know how to completely disable this exploit so no worries until microsoft comes out with the patch. Go to (classic view)control panel-system/advanced tab/performance settings/data execution prevention and enable for all programs not just windows programs. Then go to command prompt and unregister the dll that is used in this exploit(this will disable thumbnail view in windows explorer). This is done by typing this at command prompt: regsvr32 /u shimgvw.dll I saw this in on a I think a U.K. website and on another I can't remember I will go find and post in a minute so anyone with doubts will be straight but it is tested and proven with minimal side effects. Oh yeah by enabling data execution prevention for all programs you might experience problems with some programs you will need to go back and make exception on bottom data execution prevention tab.I'll be back in a minute with url's with this info!

 

http://sunbeltblog.blogspot.com/2005/12/note-on-dep-and-wmf-exploit.html
http://blogs.zdnet.com/Ou/index.php?p=143
Here go those url's, there is alot of going back and forth about these workarounds but generally anything is better than nothing if you care at all about your PC's security.

 

@ eyes wide shut

I am happy to agree that the other sites do use the term Remote Code Execution Exploit. This is undoubtedly the preferred description.

I shall try & learn a little about how Remote Code Execution Exploits work in order that I can try and relate them to this event.

I very much appreciate your posts 'eyes wide shut'



Regards & Best Wishes for the New Year

eyes-open

 

I don't think the term remote code execution says a lot. I doubt if it's really a seperate technical category. It just means there is a way to run code remotely.

Even a buffer overflow usually leads to remote code execution which gets all the excition

 

New results i think? from av-test

These detected all the wmf samples
* BitDefender
* Computer Associates eTrust-VET
* F-Secure
* Kaspersky Lab
* McAfee
* Eset Nod32
* Microso OneCare
* Sophos
* Symantec

These missed just one file:

* Alwil Avast
* Clam AntiVirus
* Aladdin eSafe

These missed a number of samples (total in parentheses):

* Fortinet (1
* AntiVir (24)
* eTrust-INO (25)
* Panda (25)
* Ikarus (26)
* Norman (26)
* Ewido (47)
* AVG (59)
* VirusBuster (61)
* QuickHeal (63)
* Trend Micro (63)
* Dr Web (93)
* VBA32 (110)
* Authentium Command (119)
* F-Prot (119)

 

But then HERE they specifically refer to it as a buffer overflow...

It's entirely possible that it started out one way, and then evolved into another. Kaspersky is stating that there are over a hundred different variations of the exploit, so who knows. I haven't seen a lot of technical info on this particular exploit, I have a feeling we'll find out more after the patch is released and things are a little more under control.

 

Just to round this off - This from a transcript between Steve Gibson, Leo Laporte and Ilfak Guilfanov (the guy who wrote the unofficial patch)

Given Ilfak wrote the patch - I may have run out of wriggle room lol ......

 

I was hearing the same thing as well.. I do wish the expers would get their stories straight before releasing this stuff It certainly doesn't make things easier for the rest of us, does it?

 

Hi Notok

Yeh, a lot of folks seem to have used US-CERT as a source - including other Governmental agencies. I back-tracked several links to their original releases. These links have then in turn been used as reference points. An object lesson in how not to obtain information.

Still - all credit due to eyes wide shut who was kind enough to encourage me to re-think. At least on these boards there's the chance to work through stuff.......can't ask for more than that.

Thanks to all who contributed - much appreciated