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.
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".
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
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
Also, most people running Ilfak's patch are going to know what they're doing well enough to expect changes in their machine's behavior if the patch causes problems. If MS put the exact same patch on Windows Update and every granny's and PHB's computer applied it overnight, it would be equally bad publicity when millions of less-tech-inclined users wake up the next day and can't add EPS clipart to their PowerPoint presentations because the patch prevented vector graphics from working at all.
Think about it - when you installed Ilfak's patch, did you think that it was failsafe? No, if you're smart, you figured it was better than nothing and went ahead anyway. Microsoft can't afford to release something that's "better than nothing". Only after several days of Ilfak's patch being released, without any serious side effects being reported, could you really be sure that it was a truly good solution. By then, it was only a couple more days before MS released their official patch that made the same solution permanent within the DLL.
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.
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.
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.
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?
We have a few security-focused assets in the company.
There is a team that grew out of some of the company-wide security folks that are sort of the "gatekeepers" now for all software that leaves the building.. you have to pass their audits, which are primarily about running internally brewed tools against your source code and binaries. As we get better at this stuff we update our tools and as the tools find things the developers get smarter about not writing dumb code to begin with, the testers get better at writing evil tests, and the PMs get better about recognizing that a feature is a problem-by-design to begin with.
This team will also do some code/design review, and will make you justify any bugs you decided to "Won't Fix" during the developmnent cycle. Our bug tracking systems have all been amended to include lots of rich info re: security/threat impact, and this team mines that data as well.
They do _very_ limited penetration testing.
Distributed across teams there are security "representatives" that are supposed to coordinate training and getting the latest tools/best practices out to the developers/testers at large.
Development teams are required to create threat models for all feature areas. The threat model library must be presented to the "gatekeeper" team described earlier as well.
Some teams are building local penetration testing teams.. which ahve product/feature area domain expertise.. but also understand the art of penetration testing. We don't have enough "centralized" resources to have a crack team of pen testers that cover all products. They can provide guidance/expertise/interviewing/whatever, but ultimately cant cover the whole company. Building a culture of grey-hat minded people and sprinkling them through-out every product team takes a long time.
Note that everything i am describing did not exist at MS 5 years ago. Blaster, Nimda, CodeRed, Melissa, etc really kicked our ass with customers. In a way, we needed all those so that internally people could really justify making the investments needed in security. There was a lot of sentiment along the lines of "we got to be #1 with the way we've been doing things, who are you to argue?", from a lot of really smart, strong-minded people.
Breaking that and reforming them to the new religion takes time.
We have a _huge_ debt of bad code, bad practices, bad developers, bad testers, and bad managers. We've been working pretty hard to pay down that debt. When i say "bad developer" i mean "developer that wrote code for years, never having to care about security", not that the developer is stupid/has malcious/intentionally poor habits.
Based on how often we issue patches, # of patches released for a given product, etc now compared to say, Win2k, i think the changes are already starting to pay dividends for us. Server 2003 is a lot better out-of-box than Server 2000 was. If nothing else, when i read a design doc or look at a bug report now and feel like it might be a problem, and say so, people take me more seriously. They aren't as apt to play the "it's not my problem" or "that can't happen in the real world" games as they were just a few years ago.
My opinions are my own, and do not necessarily represent those of my employer.