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?
http://thisweekintech.com/sn21
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
Leo Laporte and Steve Gibson also interviewed him yesterday in their very professional sounding security podcast.
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
we could but then we'd be sued for trademark infringement. The current logo is unique enough to be "artistic expression".
-nB
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
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.
Maverick patches are the last thing we need. And now, since this guy is getting a bunch of press, we will have 90 million hackers trying to be the first to release a patch for the next MS bug.
So who's the one at fault: the maverick hacker who writes a patch, or the user who chooses to install it instead of waiting for the official patch from Redmond?
You do know that Ilfak's patch was optional, right?
That's all reversible information, though. Somewhere, for an executable to work, this information would need to be stored, and on the disk. Considering that nothing stored on disk is completely secure, I don't see this as a viable option.
Consider the GUID option: That GUID is going to have to be known so that everytime a new DLL or EXE or other executable code file is copied, on an OS level, to the system, that it be modified to include the correct jump points. It would be trivial to write a hack that grabs this GUID stored somewhere. Knowing that this GUID is used to jumble the locations of a process, the whole thing could be "undone". Even if you were to generate the GUID on the fly (with each execution) the problem arises that the original executable code is still on the disk somewhere- and that you can get at that file. The only security this creates would be fleeting, because it depends on the method of "encrypting" the file with the GUID be secret or that the method the GUID is created with be secret. Otherwise, it's all easily repeatable by anyone who takes the time to determine how the GUID is generated.
Even in a best-case scenario, in which the GUID is generated based on some known information and some pseudo-random information, applied on execution of the file on the OS level, and then the file is run from memory, could still fall prey to some easy hacks: Patterns. If the file is ever stored on the disk, it can be analysed, patterns generated from it, and memory locations could be determined from that.
Basically, any executable stored is vulnerable to this unless the code is secure to begin with. Instead of patching the entire system with a solution that is more of a cold medicine-style fix, the key is to have both have engineers design good specs and to have programmers write better code.
http://www.datarescue.com/freefiles/funnyad.jpg
>I'm not sure [..] if Windows is just POS software.
...
Really? Let me clear that up for you
There is much cruelty in the universe, John.
Yeah, we seem to have the tour map.
Doesn't matter where in the software you hide the algorithm, the algorithm must be available in software and therefore provides only the illusion of security. Sorta like locking the front door, but leaving the key under the door mat (when everybody knows that you leave the key somewhere near the front door).
Put it in hardware, and you've begun sliding down the slippery slope leading to "Trustworthy Computing".
This is all wide of the point, however; the problem isn't a buffer overflow, it's a well-coded but ill-concieved functionality built into Windows by design. Going back to that front door, it's a mail-slot large enough to put your arm into, in case you ever need to spin the doorknob from the inside. Not intended to make your home insecure, but rather to make your life easier. Oopsy! Didn't realize that thieves could also reach through the mail slot.
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.
hanks for clearing that up. I find it hard to believe that Microsoft would threaten to sue over something like that.
MS threatening to sue is news to me. It sounds like pure speculation. My pure speculation is that the icon was created by someone right after MS did one of the thousands of annoying/illegal/unethical things they regularly do to piss off the computer industry as a whole (you know like buy out and kill a cool technology, intentionally break a standard, or bundle yet another software package illegally) or after someone has just finished several hours of trying to deal with their buggy software. Generally, after hearing the 507th thing MS has done to slow down the progress of computing, sentiment against them is running high enough so that people with a clue are amused and gain some stress relief from a simple mockery of them. I know after a few hours of coding workarounds for IE's broken version of HTML I'm more than happy to see something mocking MS. It's not prejudice to judge someone after observing their behavior for years.
I predict a non-mocking logo for MS will replace the existing one about one year after MS stops pissing everyone off by being evil.
There's also an interview with him in yesterday's Security Now! podcast
http://www.twit.tv/
Insert Sig Here
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.
See here.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).