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
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.