Slashdot Mirror
Interview with Ilfak Guilfanov (WMF Patch Hero)
GrayWolf42 writes "SecuriTeam Blogs has posted an interview with Ilfak Guilfanov, one of the people developing the IDA Pro disassembler, who also happens to have written the unofficial WMF vulnerability patch. In this short interview he discusses the patch, how it works, and why he wrote it." From the article: "Q: When you heard of this vulnerability, you created a temporary patch to close the hole until Microsoft updated its software. Could you tell us more about what the patch does? A: The patch just removes this powerful command. It does not do anything else. The fix modifies the memory image of the system on the fly. It does not alter any files on the disk. It modifies [the image of] the system DLL 'gdi32.dll' because the vulnerable code is there." Microsoft has released an official update, which you should be able to download from the windows update site.
Seems like the site also provides with a binsiff output of the Microsoft patch: http://blogs.securiteam.com/index.php/archives/184
The "SecuriTeam Blogs" site has been a very good source for real-time security information since it came online.
MS deserves bashing for the flaw, but there's a difference between an untested one-man release, and the official, QA'd patch. Part of the reason Microsoft couldn't release a patch immediately is because they need to make sure their fix doesn't break snything else.
The theory of relativity doesn't work right in Arkansas.
So this is a design issue?
Yes, it is a design issue.
I would think the MS would have a department of crackers and hackers to try to do shit like this. Also, didn't any of the original developers think of this when they wrote it or did they think the exploit was so remote, that it'll never happen?
They did. The official patch has the same end effect as the unofficial one. The only difference is in method. Microsoft modified the source code to remove the vulnerability instead of removing it in memory.
- AMW
Why not just auto-scramble the DLL code on the fly for every installation of the Windows OS?
That would mean buffer overflows are essentially defeated on a vast majority of cases? One simple thing we could do would be to insert random NOP's in DLL's, making the buffer overflow get the correct offset wrong most of the time and thus fail to work. I'm sure there are dozens of more clever ways to achieve this, in a completely general sort of way.
The reason these attacks spread is that the binary code is essentially a monoculture crop -- all clones of each other. Why not take the SID of a system, or some GUID, and use it to morph all the binary images on a system in a unique way for that system?
Since lots of attacks use NOP's, XOR'd code, and other techniques to avoid being detected as code, why don't we apply the same techniques to our binary objects to obfuscate them from the attacking code?
Paul Sop
The problem is in what was intended. If your "feature" is a boneheaded security hole, no amount of good design and good coding can save you. All they will get you is a beautifully designed, perfectly coded boneheaded security hole.
The guy did not "remove one line of code." He used a DLL injection technique (documented by Richter in Advanced Windows Programming) that allows him to replace the registered address of a function in gd132.dll. This is not beginner coding, it works fine in principle but is not easy to pull off and have be reliable.
One problem, for instance, is that if some other hacker came along and reset the function pointer with their *own* dll, we'd be back to square one (tho that requires a greater level of system access). And the DLLs themselves don't have explicit control over when they get loaded, so they can't guarantee that they are first or last.
Microsoft's patch is nothing like his. They (I'm guessing) rebuilt gdi32.dll to actually turn the function into a no-op. Adequate testing by MS would have to include ensuring that all the various WMFs dynamically generated by the OS are not adversely affected.
Premature optimization is the root of all evil
MS should have been all over this once the news hit. Why did it take them so long to get a patch out the door for this vulnerability? I suppose I could understand that it was the holiday, but even then, with 90%+ marketshare, you have an obligation to get that patched up ASAP.
I think that's a bit unfair. We got news of this zero day exploit the 27th of December? It's still only about 10 days to produce a patch and test it. It fixes multiple versions of Windows too. IMO it didn't take too long for MS to fix it compared to the 200+ day fixes you read about regulary on eEye's site. Of course the not so good design of Windows doesn't help either. Windows is not modular so fixing something like an image processing function can impact the entire kernel, it needs extra testing.
Or just do what OpenBSD does: Make writable memory non-executable, make executable memory non-writable. This bit of common sense is disappointingly rarely implemented.
Additionally if you check the timestamp on %WINDIR%\System32\gdi32.dll (the file fixed by Microsoft's patch) you'll see that it is dated 12/28. So we found out about the exploit on 12/27, Microsoft had it fixed the next day (assuming they didn't modify the file dates for any reason) and spent the remainder of the time testing the patch.
That's exactly what the Data Execution Prevention (DEP) is. It requires XP SP2 and a CPU that has the NX bit (or I forgot what Intel called the "we didn't copy this form AMD" bit). In fact, it appears that DEP does stop the exploit.