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.
I think the /. post should link to Microsoft Update and not Windows Update. Microsoft Update will patch MS Office and other products as well as Windows.
It's one step closer to "apt-get update; apt-get upgrade".
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?
The guy removes one line of code and becomes famous almost instantly.
Why didn't anyone a Microsoft think of this solution? They might have been put in charge of their own security team.
He who knows best knows how little he knows. - Thomas Jefferson
From SecuriTeam Blogs: Is there anything that you think should be done to make vulnerabilities like this less dangerous in the future?
Good design and good coding practices, but that is easier said than done.
But shouldn't that be everybody's focus? We're seeing a lot of articles this week on coding practices, bugs, and vulnerabilities, and it all boils down to how hard every programmer is going to work to eliminate them. It's unrealistic to think that there will be no bugs in any piece of code, but if there are to be bugs/vulnerabilities, their impact should at least be minimized. And it's going to take teamwork; the day of the lone programmer capable of wiping out the bugs is long over.
GetOuttaMySpace - The Anti-Social Network
http://www.microsoft.com/technet/security/bulletin /ms06-001.mspx
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. This could have been a lot worse than it is/was, but I think the pressure from outside and the release of the "unofficial" patch is ultimately what got MS off it's collective ass and back to work.
My MythTV HowTo
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
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.
I'm not saying these are (necessarily) insurmountable, but:
One doesn't really have _full_ flexibility in binary layout. There are issues like word alignment to be aware of.
Windows needs to know how to get the address of a symbol, by name, dynamically. Even if you change the address underneath, the exploit only needs to call a routine to just call the moved function by name.
One of the advantages of DLLs is that the text (code) segments are shared cross-process. If you want to make the loader muck with the images per-process, you effectively have static libraries. This is lethal on server type applications with hundreds or thousands of separate address spaces.
Note that if you _dont_ do per-process space scrambling, your exploit can just scan its entire address space to see where the relocated stuff is, because it will be the same in all the other address spaces on the box.
Finally - this was a spec defect - my understanding is that the code is actually running as designed.. it's just a facility that has no business in a modern, assumed-hostile computing world.
My opinions are my own, and do not necessarily represent those of my employer.
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.