Reverse Engineering WMF Exploit Code

websense has done a lot of work on wmf since first alerting about it publically (yep, that was them), and in fact, along with many others, helped with alerting us (tisf / mwp) to many sites hosting malicious wmf files so that they can be taken down.

their latest blog entry is:
reverse engineering wmf exploit code

jan 17 2006 10:33am
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 stepsin 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.

url is:

direct url to the flash video:

gadi evron,


MS releases MS06-002 and MS06-003

(Updated: January 10, 2006 on 7:40 pm, updated again: January 11, 2006 on 07:54 am)

Yes we are at that special day of the month, and like everything else, it comes better second time around :)

Microsoft has released MS06-002 (BTW… it was discovered 162 days ago) and MS06-003 a few minutes ago, both are categorized as critical, doesn’t that give you a waorm feeling?

MS06-002 was discovered by eEye, while MS06-003 was discovered NGS Software. This already tells me two things, for the eEye an abundance of technical material will be made available, while for NGS Software, literally no technical information will be uncovered. Unless like in the case of the recent WMF Spyware/Worm/Whateveryoucallit shenanigan, someone skilled enough will find how to exploit it on their own.

Some initial details on MS06-002: it also affects legacy software such as Windows 98, and requires the user to simply visit a malicious web site – much like the WMF vulnerability.

Some initial details on MS06-003: it affects Outlook 2000 and up, and can be easily exploited by sending someone a TNEF file (Transport Neutral Encapsulation Format).

More to come as I analyze these two vulnerabilities to gather additional information from the public and hax0r mailing lists (:D)…

eEye has released an advisory, from the advisory the following can be understood:
Embedded Open Type fonts are referenced through the use of style data, as the following snippet illustrates:

@font-face {
font-family: Abysmal;
font-style: normal;
font-weight: normal;
src: url(evil.eot);

The heap overflow vulnerability is found in the in T2EMBED.DLL, and:
The data within an EOT file is compressed in Agfa MicroType Express format, which hosts an LZ-compressed stream that includes a 24-bit allocation size. This size + 1C00h is allocated within the function MTX_LZCOMP_UnPackMemory, but the resulting allocation size is not validated before data is copied into the block, allowing a malformed EOT file to cause an essentially arbitrary-length heap buffer overflow with binary data.

Sounds simple enough to exploit… let the countdown begin.

Update 2:
A very technical and detailed explaination on the vulnerability can be found at:


Digital Mind-Reading: How NOT To Handle Reduced-Privilege Environments

Current approaches to reducing privilege in the desktop world take the technically wrong-headed approach of creating user accounts with huge levels of privilege, and then simultaneously using these accounts to run tasks with limited privilege. The line isn’t at all clear. This effectively forces your computer to become a mind-reader everytime you log on. Suffice it to say, the accuracy is none too impressive…

What did impress me was reading about Michael Howard’s DropMyRights tool for Windows XP. After I put the tool to the test, however, my enthusiasm fell considerably. Howard’s DropMyRights tool suffers from one unavoidable issue: an OS that was never meant to be used in the fashion Howard intended.

In all fairness, Michael Howard is no fool. As a Microsoft Security PM, Howard has been one of the most outspoken voices on secure coding for the Windows platform. He still recommends (and in no uncertain terms) the tried-and-true (however painful) advice of running as a limited user. I, for one, am following it. I was more interested in the seemingly bizarre premise of Howard’s tool: the ability to reduce the privileges of arbitrary applications from an administrative context to a limited user context.

I also found related tools, such as the RunAsAdmin project, which appear to be a first effort of sorts at implementing the type of protection offered by the User Account Protection (UAP) feature of the forthcoming Windows Vista. The RunAsAdmin tool is a “shim” around the infamous explorer.exe that causes the shell to be run with Normal User (or less) privileges, even when the user who logs on is an Administrator or Power User. Such powerful users need to use a taskbar icon to run fully-privileged tasks.

After reviewing and deploying both tools, I attempted certain actions that would be permissible for an administrator, but not a normal user. These include privilege uses, registry alterations, and file system modifications. All were denied as expected. It would appear on first-glance that I had indeed managed to surrender all of my extra access and privileges, and was no longer a danger to my system. It would also appear that the project team for RunAsAdmin has given us an eerie glimpse of a sort of “unpolished UAP”. If that is the case, we can only hope that Vista’s final implementation isn’t as dangerous to security.

Why the sudden change of tune, you ask? As I marveled at this unique paradox (an unprivileged privileged user), a thought occurred to me:

“How does such a user authenticate themselves to other systems or services in such a limited way?”

Armed with little more than excess free time, I set to work on the question at hand. It didn’t take me very long to figure out my answer.

I had three theories about how this process could take place, or not take place:

1) Any application run as a user with this kind of arbitrary limitation loses the ability to automatically gain access to such services, and is forced to either:

a) use a null session
b) prompt the user for legitimate credentials

2) Any application run as a user that has been limited will pass on its full token context (as opposed to purely its logon credentials), and thus the full extent of its limits, to the remote service.

3) Any application run as a user that has been limited simply uses the original username and password of that user to any services requesting authentication.

Can you guess which one actually happens? Here’s a hint: why am I writing this article?

You guessed it… it’s #3. If a process run by me submits a request to a remote process to do a task on my behalf, it uses my username and password to authenticate to that process, and that task then inherits the original, unchecked, full power of my account… whether the original requestor is limited or otherwise.

To see for yourself, use Howard’s “DropMyRights” tool from an administrative account to spawn a process like Internet Explorer, that has easy access to files. Go to your system root directory (C:\WINDOWS, usually), and attempt to move, delete, etc., some system file there. You’ll be denied.

Now, access the same directory via the network redirector, using Windows XP’s built-in, immutable administrative shares:


Move a file from that directory into some subdirectory of it, and then watch the file disappear. If you moved a system file, a refresh will even show you that Windows File Protection (WFP) has restored it to its original location. Congratulations, you’re authenticated to your own system (silently, no less) as a full administrator from a limited process.

Had malware done the same thing, it wouldn’t present you a pretty graphical shell, and you can bet it would do far more damage than moving a file or two out of your install directory.

This disaster of a privilege-limitation attempt illustrates just how wrong-headed the entire design is. It’s wrong on two points.

First, you never start with excess power and then try to rid yourself of it. You always build up power as you need it. To do it the other way around is to invite laziness and error, and expose your entire network to more danger.

Second, people forget that what is signified by a username/password combination is an authority, not an identity. People try to make accounts serve as identities, when they are nowhere close. The strength of the identity is directly proportional to both the strength and the secrecy of the password. If either is compromised (and in a lot of cases, one of the two is severely so), identity is worthless. Further, even the strongest, most well-guarded passwords provide only a questionable level of identity verification.

Regardless of how vulnerable the identifying intent behind passwords is, though, your use of a username and password is a claim to the authority to use any rights tied to the account you’re accessing. In the case of an administrator, that’s essentially the right to destroy your PC if you so choose. Attempting to limit rights in this context is roughly equivalent to giving the applications you run this excessive amount of power and then trying to prevent them from using the powers you’ve been afforded.

I suspect that this is why you won’t find the three privilege-limiting software restriction policy options (which are used by Howard’s tool) listed in XP’s Local Security Policy snap-in:

  • Normal User
  • Constrained
  • Untrusted

Instead, all that’s available to you is “Unrestricted” and “Disallowed”. It’s no wonder, now… why that is. The design is so fundamentally flawed as to make its entire premise of securing your system utterly false. When the same set of credentials that made you a serf can make you a god, you force your computers to become mind readers. Odds are, they’ll get it wrong. That’s bad news for your security.

Will we see the same thing in Vista? Who’s to say. But, unless Microsoft delivers on the redesign it promises, there’s a good chance that running with privilege, protected or otherwise, will be just as dangerous as it always has been.


Did Microsoft pull an Ilfak? Microsoft’s patch under a magnifying glass

So, Microsoft released a patch ahead of schedule. We can only applaud that.

But what does that patch do?
Exactly what Ilfak Guilfanov’s patch did, only he built it in a few hours (plus some testing).

Microsoft disallowed SETABORT. Same as Ilfak’s… rearranged a bit. See for yourselves below. If that is the best solution, we see no harm in that either. It just seems that MS06-001 is Ilfak’s patch in a prettier outfit.

We understand the need for extensive testing, so the time differential in this case can be accepted. And yet…
The new patch was released today. After patching, the new gdi32.dll is dated to the 28th of December. What’s the date today?

What’s that all about? It makes you wonder, doesn’t it?

Well, why don’t you see for yourselves? Here is what Microsoft did, as bindiff shows.

Old GDI32 has the bug here:

.text:77F24914                 movzx   eax, word ptr [ebx+6]
.text:77F24918                 cmp     eax, 0Fh
.text:77F2491B                 jz      loc_77F25067    ; default
.text:77F24921                 push    0               ; LPVOID
.text:77F24923                 lea     ecx, [ebx+0Ah]
.text:77F24926                 push    ecx             ; LPCSTR
.text:77F24927                 movzx   ecx, word ptr [ebx+8]
.text:77F2492B                 push    ecx             ; int
.text:77F2492C                 push    eax             ; int
.text:77F2492D                 push    dword ptr [ebp-7Ch] ; HDC
.text:77F24930                 call    Escape
.text:77F24935                 jmp     loc_77F23F23

The patched GDI32.DLL contains this code instead:

.text:77F24914                 movzx   ecx, word ptr [ebx+6]
.text:77F24918                 push    ecx
.text:77F24919                 call    _IsAllowedWmfEscape@4 ; IsAllowedWmfEscape(x)
.text:77F2491E                 test    eax, eax
.text:77F24920                 jz      loc_77F2506C    ; default
.text:77F24926                 push    0               ; LPVOID
.text:77F24928                 lea     eax, [ebx+0Ah]
.text:77F2492B                 push    eax             ; LPCSTR
.text:77F2492C                 movzx   eax, word ptr [ebx+8]
.text:77F24930                 push    eax             ; int
.text:77F24931                 push    ecx             ; int
.text:77F24932                 push    [ebp+var_7C]    ; HDC
.text:77F24935                 call    _Escape@20      ; Escape(x,x,x,x,x)
.text:77F2493A                 jmp     loc_77F23F23

… and the new function itself:

.text:77F42D66 ; __stdcall IsAllowedWmfEscape(x)
.text:77F42D66 _IsAllowedWmfEscape@4 proc near         ; CODE XREF: PlayMetaFileRecord(x,x,x,x)+ACD
.text:77F42D66 arg_0           = dword ptr  8
.text:77F42D66                 mov     edi, edi
.text:77F42D68                 push    ebp
.text:77F42D69                 mov     ebp, esp
.text:77F42D6B                 xor     eax, eax
.text:77F42D6D                 cmp     [ebp+arg_0], 9
.text:77F42D71                 jz      short loc_77F42D7A
.text:77F42D73                 cmp     [ebp+arg_0], 0Fh
.text:77F42D77                 jz      short loc_77F42D7A
.text:77F42D79                 inc     eax
.text:77F42D7A loc_77F42D7A:                           ; CODE XREF: IsAllowedWmfEscape(x)+B
.text:77F42D7A                                         ; IsAllowedWmfEscape(x)+11
.text:77F42D7A                 pop     ebp
.text:77F42D7B                 retn    4
.text:77F42D7B _IsAllowedWmfEscape@4 endp

(got anything to tell Ren&Stimpy? Email us:


Who is going to bindiff the MS WMF patch first? Already done.

apparently, guys from the funsec list:

“looked at it over someone else’s shoulder, on a 64 bit system, they
just disallowed setabort. in other words, the “functionality” is
broken (which is a good thing)” — pierre.

rings any bells?

gadi evron,


WMF Spyware/Worm on the loose

(Updated 2005-12-28 16:09 GMT)

A browser orientated spyware/worm appears to be on the loose. It exploits a vulnerability in the WMF rendering of Windows based operating system to infect them.

The worm utilizes a malicious WMF located at “uni on seek. com/ d/t 1/ wmf_exp. htm” (note the extra spaces are here to avoid accidental infection).

The vulnerability being exploited appears to be related to MS05-53, but somehow fully patched system still get infected by this worm.

Most infections occur on Windows XP machines, but I am not sure that there is a reason why other OS won’t get infected.

According to VirusTotal, only one Antivirus/Spyware detection system was able to determine that its a Trojan.Downloader a few hours ago (around 9:00 GMT), while now most Antivirus/Spyware classify it as:

Antivirus Version Update Result
AntiVir 12.28.2005 TR/Dldr.WMF.Small
Avast 4.6.695.0 12.28.2005 Win32:Exdown
AVG 718 12.27.2005 no virus found
Avira 12.28.2005 TR/Dldr.WMF.Small
BitDefender 7.2 12.28.2005 Exploit.Win32.WMF-PFV
CAT-QuickHeal 8.00 12.28.2005 no virus found
ClamAV devel-20051108 12.26.2005 no virus found
DrWeb 4.33 12.28.2005 Exploit.MS05-053
eTrust-Iris 12.27.2005 no virus found
eTrust-Vet 12.28.2005 no virus found
Ewido 3.5 12.28.2005 Not-A-Virus.Exploit.Win32.Agent.r
Fortinet 12.28.2005 W32/WMF-exploit
F-Prot 3.16c 12.28.2005 no virus found
Ikarus 12.28.2005 no virus found
Kaspersky 12.28.2005 Trojan-Downloader.Win32.Agent.acd
McAfee 4661 12.28.2005 Exploit-WMF
NOD32v2 1.1342 12.28.2005 Win32/TrojanDownloader.Wmfex
Norman 5.70.10 12.28.2005 no virus found
Panda 8.02.00 12.28.2005 Exploit/Metafile
Sophos 4.01.0 12.28.2005 Troj/DownLdr-LW
Symantec 8.0 12.28.2005 Download.Trojan
TheHacker 12.28.2005 Exploit/WMF
UNA 1.83 12.28.2005 no virus found
VBA32 3.10.5 12.28.2005 no virus found

As can be seen Antivirus companies have now started detecting it, which should bring the infection rate down or at least stop from getting any worse.

I will try and update you on additional details as they appear.

Metasploit Exploit:
H D Moore has created an exploit from the WMF worm that utilizes the same techinque as the worm does to open a shell on a remote Windows XP system, the exploit is available from:


Information Concerning Reported FireFox Vulnerability

A recent PacketStorm article reproduced by SecuriTeam indicates that a vulnerability has been found in the Browsing History code of Mozilla Firefox. Initial investigation confirms that FireFox 1.5 on Windows is not affected, and it appears that the report may be false.

Peter Laborge of SecurityFocus has also written a “news brief” on this vulnerability. It appears at this time that SecurityFocus is spreading inaccurate information and contributing to overblown media reporting on the issue.

Testing of the PoC code on Mozilla Firefox 1.5 with Windows XP Service Pack 2 causes no ill-effects. Contrary to the public claims, the browser runs normally. Startup is slowed considerably, but the browser does indeed function after some delay. Deleting history links will clear the slight sluggishness that the supposed “exploit” causes. The problem will clear up naturally once the malicious link expires from the history, which seems to be 9 days in Firefox 1.5 by default.

Other posters have also reported that the browser operates normally, with only a delay in startup, after the attack is carried out. Users who are concerned about a few seconds of delay in Firefox’s startup can turn off the history — something many privacy-conscious users have already done — via the Options window in the “Privacy” section.

To reiterate… there is no evidence that a vulnerability exists in FireFox related to history processing at this time.

[EDIT: Mozilla has investigated this issue, and come to the same conclusion. Though there's some slowdown at startup, it's not a hang (the browser loads) and it's not a crash. The Mozilla advisory is available here.]


DocuColor Tracking Dot Decoding Guide

The EFF has broken the tracking code used by Xerox DocuColor. The “DocuColor” prints a series of yellow dots on a 15×8 grid on every page to identify the printer.

The EFF has created a web application that can be used to decode the dots which hide the time, date, and serial number of the printer.


Cross-Site Scripting Worm Hits MySpace

As by hand of “god” – a worm that exploits a cross site scripting issue in MySpace has caused numerous users to become “infected” with a piece of javascript that would add them to the buddy list of “Samy”.

This worm comes a few days after we have published an article predicting the spread of such worms. We didn’t know it would happen so quickly, but hey, don’t say we didn’t warn you.

Maybe it will cause webmasters to regard cross site scripting as more than just an inconvenience.