dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
395

SpannerITWks
Premium Member
join:2005-04-22

SpannerITWks

Premium Member

Reverse Engineering WMF Exploit Code etc

Here's a look at the exploit in more detail.

-

As we have reported, there are still thousands of websites hosting WMF exploit code.Since we have been analyzing several of these, we thought we would share some steps in researching the behavior of the what the exploit code is doing.

This video displays malicious WMF Files debugging. It shows how you can easily locate and debug the embedded shell code of WMF files, to find out what it was supposed to do.

If you want to try it yourself, do it inside a Virtual Machine and on an unpatched Windows.

»www.websensesecuritylabs ··· om/blog/

-

There are more versions of the exploit floating around, as well as the previous ones, which will still impact millions of people around the world. Also i wonder how different browsers stacked up against the recent WMF threat in percentages, and if that data is available ? Here's one example with FF.

-

WMF Infected Site Examples

We have also included a screenshot of the behavior of a Unix machine (running Knoppix) and Firefox.

»www.websensesecuritylabs ··· rtID=391

Spanner

ZOverLord
Premium Member
join:2003-10-20
Minneapolis, MN

1 edit

ZOverLord

Premium Member

What's also different about this code when it is reverse engineered compared to most other flaws found in Windows is that when you look at the code itself, it is easy to see that it was coded intentionally to do as it does, to execute code from within the meta-file itself.

This is one reason systems programmers are saying that this code was designed to do this, that it was intentional and that it was intended to functioned this way.

Most of the systems programmers community so far, agree that other products that emulate Windows meta-file processing had carried it over, such as WINE for one example, because they were trying to emulate exactly what Windows was doing, inside or outside of the Windows specification, that was their main goal, Windows emulation.

It would be safe to say that something coded intentional, becomes a feature, especially when some parts of the operating system are modified to protect them self from this, yet other parts of the operating system were still allowed to have access to it.

So the deeper questions become once it was concluded that this was intentional, and also known about as well, what were its purposes, its intended reasons for existence?

This is where the visual reverse engineering of the code helps little. In some ways it's where the reverse social engineering starts.

Basically the systems programmer community knows that only the original author and/or parties at Microsoft will able to answer that question.

It should be noted that the systems programmer community agrees that there really is no easy kernel interface with using this, there is no real easy context interface. This means that this feature would have minimal benefit to meta-file processing, in general.

I think where some of the confusion on how this operates came from is that many people assumed that meta-files were always allowed to execute code from within them self, and that this was some major abuse of that.

Actually meta-files were always allowed to callback an application procedure contained in a application processing meta-files, but meta-files were never officially allowed to execute code within them self.

It is this fact which was found, combined with the way this was coded itself, that systems programmers in the end determined intent.

I hope we can stay on the topic of this thread and deal with the reverse engineering methods of this.

Thanks

Marilla9
I Am My Own Arbiter
Premium Member
join:2002-12-06
Belpre, OH

Marilla9

Premium Member

said by ZOverLord:

I think where some of the confusion on how this operates came from is that many people assumed that meta-files were always allowed to execute code from within them self, and that this was some major abuse of that.
Not aware of anyone who thought that, myself. I always thought that the fact that you could call code in the WMF file itself was part of the vulnerability here. However, you don't have to call code within the WMF to call malicious code; You could point SETABORTPROC to some other damaging code as well.
said by ZOverLord:

Actually meta-files were always allowed to callback an application procedure contained in a application processing meta-files, but meta-files were never officially allowed to execute code within them self.
Right, which is where the exploit comes in; allowing specific code that is outside of functions available within GDI, to be executed.

ZOverLord
Premium Member
join:2003-10-20
Minneapolis, MN

1 edit

ZOverLord to SpannerITWks

Premium Member

to SpannerITWks
I don't think I said it was restrained from doing things outside of a meta-file itself?

"It should be noted that the systems programmer community agrees that there really is no easy kernel interface with using this, there is no real easy context interface. This means that this feature would have minimal benefit to meta-file processing, in general."

I think the systems programmers community agrees that the fundamental exploit ability of this was the fact that meta-files were allowed to execute code from within them self.

Marilla9
I Am My Own Arbiter
Premium Member
join:2002-12-06
Belpre, OH

1 recommendation

Marilla9

Premium Member

said by ZOverLord:

I think the systems programmers community agrees that the fundamental exploit ability of this was the fact that meta-files were allowed to execute code from within them self.
Yes. That's exactly what I just said.