Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Security Operating Systems Software Windows

Interview with Ilfak Guilfanov (WMF Patch Hero) 167

Posted by Zonk from the small-acts-lead-to-big-things dept.
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.
This discussion has been archived. No new comments can be posted.

Interview with Ilfak Guilfanov (WMF Patch Hero) More

Interview with Ilfak Guilfanov (WMF Patch Hero)

Comments Filter:

  • SecuriTeam blogs (Score:5, Informative)

    by GrayWolf42 ( 943541 ) on Friday January 06, 2006 @02:56PM (#14410802)
    Seems like the site also provides with a binsiff output of the Microsoft patch: http://blogs.securiteam.com/index.php/archives/184 [securiteam.com] The "SecuriTeam Blogs" site has been a very good source for real-time security information since it came online.
    • as good as this patch is, it really annoys me that any user can just patch a part of a dll somewhere. It suggests that some other program can patch it right back to what it was.


      You simply should not be able to go and mess around with system files like this.


  • ok... (Score:5, Insightful)

    by User 956 ( 568564 ) on Friday January 06, 2006 @02:56PM (#14410804) Homepage
    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 [eweek.com] Microsoft couldn't release a patch immediately is because they need to make sure their fix doesn't break snything else.

    • Re:ok... (Score:3, Insightful)

      by ackthpt ( 218170 ) *
      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.

      Often, historically, Microsoft's approach has been the same, to just take away the offending bit.

      When the actually correct the code is where Microsoft have sometimes introduced new vulnerabilities, perhaps because the focus of their Q/A is too n

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

      • Re:You're missing the point, though (Score:5, Insightful)

        by dc29A ( 636871 ) on Friday January 06, 2006 @03:40PM (#14411156)
        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.

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

          Actually, the 27th is when the exploit went public. I have yet to see reliable data on when it first was discovered being exploited in the wild and when it was reported to MS. For all we know MS had this reported to them months ago.

        • Re:You're missing the point, though (Score:5, Informative)

          by Diamon ( 13013 ) on Friday January 06, 2006 @03:59PM (#14411341)
          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.

          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.
          • Actually I believe that this was being exploited as early as December 14th according to one security blog [which I can't find at the moment]. I don't think the exploit was widespread until the 27th. Either way, it still took too long to patch.

            I understand that gdi32.dll is pretty much the equivalent of glibc, so its not something they want to modify without testing, but they should have at least went ahead and released the patch to the home users, production servers and the like, shouldn't of been affecte
            • In thier initial security bulliten they did mention the work around of unregistering the dll that drives windows picture and fax viewer which evidentially was the main way this vulnerability was being exploited at the time while they tested the patch.
        • Windows is not modular so fixing something like an image processing function can impact the entire kernel, it needs extra testing.

          I think you misunderstand the meaning of modular. Because Windows is modular the change of one module can impact a number of processes.
        • The 27th? Security firm PivX was able to program an update for preEmpt that blocked all of the WMF exploit vectors on Win9x and higher without breaking anything. It was made available for its auto-updating clients on December 7th (2005-12-07).
        • Well, this is a ten year old 'feature'. So one could argue that MS must have known about the danger of this feature for several of those ten years. It really makes one wonder how many more of these features there are in Windoze.
        • I think that's a bit naive. Clearly what's going on here is that Microsoft wanted to play like this wasn't any more serious than usual and could wait until their pre-planned update day. This is clear from their insistance that we all wait, and then their sudden change of heart that followed the media uproar. So, what we have here is probably 1 day to produce a patch, and nine days to bicker with the marketing department over whether to release it. If you're lucky, they tested it too. Just because other comp
        • Windows is not modular so fixing something like an image processing function can impact the entire kernel, it needs extra testing.

          Do some reading on the design and architecture of Windows. It most certainly *is* modular.

          Not to mention you've got the whole thing arse-about-face. Modularity is *why* code fixes in one module can have repurcussions in many other modules.

        • Why does everyone keep referring to this as a zero-day exploit? This is a long-standing vulnerability which has existed since 1990. It has only recently been publicised, granted, but it is a 15-yr-old vulnerability. Those running older versions of Windows, which MS has graciously declined to support, are still vulnerable to this "design flaw". On the plus side, a zero-day exploit generally means an obvious hole - this hole has existed for years, and it's taken 15 years for it to be published. Is that reall

    • Re:ok... (Score:1, Interesting)

      by Anonymous Coward

      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.

      I've got a big fat BOLLOCKS to that. How much software uses WMFs? How much software relies on being able to supply its own error-handling code should that WMF not display properly? In the WMF file itself?

      Now weigh "all those" applications (i.e. practically none) against the people that can be/have been/will be compromised with this vulnerability. Care to make a

    • Deserves bashing? If they waiting for patch Tuesday, I would agree with you. But they released a major Operating System Security Patch 8 days after the vulnerability was uncovered, and gave us accurate advice. Unregister a DLL and keep anti-virus update-2-date was enough to keep most people secure. And this was not poor programming, but poor design - a feature that was critical in the "old days" was a open hole today. I'm not thrilled with MS overall, but over WMF - I give em at B+ and an A for effort. More

  • Microsoft Update (Score:4, Insightful)

    by Chalex ( 71702 ) on Friday January 06, 2006 @02:57PM (#14410811) Homepage
    I think the /. post should link to Microsoft Update [microsoft.com] 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".
    • I just received an e-mail that the IT department where I work will be pushing out the new Microsoft Patch at 2:00PM.

      On a related note: This may be my last /. post for today.

  • From the Interview... (Score:5, Interesting)

    by IAAP ( 937607 ) on Friday January 06, 2006 @02:57PM (#14410815)
    ... There is one very powerful command code in WMF files. This command code means 'if something wrong happens, do the following: ...'. So the creator of the WMF file can make your computer do anything he/she wants by using this command code and deliberately creating an error condition afterward.

    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?

    • Re:From the Interview... (Score:5, Informative)

      by mobiux ( 118006 ) on Friday January 06, 2006 @03:01PM (#14410848)
      Considering it went back to windows 98, i don't think they anticipated the current computing climate at all.

      • Re:From the Interview... (Score:2, Interesting)

        by IAAP ( 937607 )
        I guess now it's back to my first question. Considering the beating that MS' security reputation is getting, if I were Balmer, I'd be setting up a division of crackers to try to find this shit before the bad guys do. OTOH, this is great for Linux, *BSDs, GNU, etc...

      • Re:From the Interview... (Score:5, Informative)

        by cnettel ( 836611 ) on Friday January 06, 2006 @03:08PM (#14410910)
        It goes back to Windows 3.0. You know, the one which relied on DOS software for network access, without sockets. You know, the one where using any memory protection at all was an OPTION (kind of mandatory in 3.1 and up, even if it was far from complete).
        • Windows up to ME had a command where you could read or write any process's memory, by passing it a process id and an address. That made it pretty much optional everywhere.
          • And such abilities still exist. This is how Ilfaks patch works.
            You start out by loading a DLL and telling the system that DLL needs to be loaded into every process started from there on. Now you are in targets memory space and you are able to modify targets memory space. This in turn allows you to hook functions, ie replace the DLL jump table or write to executable memory directly.

            Of course, with NT (Win2000, XP = NT) you need proper rights (Administrative Account, or User Accounts with specific rights ena
        • See here [slashdot.org].
      • Considering it went back to windows 98, i don't think they anticipated the current computing climate at all.

        No, it goes back to Windows 3.0. And while they couldn't have anticipated the current computing climate, it's hardly as if there were no trojans, virii, or other malicious programs back then. That's a completely invalid excuse.
    • Why would they need to hire a department when there's a whole world of people willing to do this for free? ;)
    • 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?

      I guess they thought the chances were remote, because when MS were doing their security review and subsequently made their GDI vulnerability detection tool [microsoft.com] available, it was not designed to pay attention to this vulnerability. I wonder if they have updated the tool?

    • There's also a very good podcast interview Ilfack did with Leo Laporte. If you'd like to check it out, here's the direct link [aol.com].
    • When this feature was added, most computers didn't even have modems.
    • I would think the MS would have a department of crackers and hackers to try to do shit like this.

      Cracking is largely driven by curiosity, geniune dislike towards software vendor or a criminal intent. Neither really fit the full-timer profile, leave alone someone being employed by the company itself.

      MS can hire 10 departments of 'crackers and hackers', it will still not do them any good.

    • Re:From the Interview... (Score:5, Insightful)

      by bmajik ( 96670 ) <matt@mattevans.org> on Friday January 06, 2006 @04:48PM (#14411735) Homepage Journal
      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.

  • http://thisweekintech.com/sn21 [thisweekintech.com]

  • Microsoft can boost your notariety (Score:4, Funny)

    by digitaldc ( 879047 ) * on Friday January 06, 2006 @03:00PM (#14410838)
    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.

    • Re:Microsoft can boost your notariety (Score:5, Informative)

      by Rolan ( 20257 ) * on Friday January 06, 2006 @03:10PM (#14410923) Homepage Journal
      Why didn't anyone a Microsoft think of this solution?


      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.

    • Re:Microsoft can boost your notariety (Score:5, Informative)

      by cheezit ( 133765 ) on Friday January 06, 2006 @03:30PM (#14411096) Homepage
      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.
    • Obviously he has friends.

      He removed a "system call"... guess what... there are probably a few applications that have a legit reason to use this function.

      Kinda like chemotherapy... kill everything 'cause you might get the cancer too.

      So Microsoft is doing some due diligence to figure out how its broken and how to fix it without breaking more sh!t.

      I love this though. There is a bunch of calls in kernel32 that pose potentially security risks... lets remove them...
    • I'd be willing to bet that Microsoft knew exactly what was wrong and exactly how to fix it within hours of being notified about the problem. From their own FAQ, you'll see that there's quite a bit more involved than simply disabling the function and putting the new DLL on Windows Update. They've got many languages, different versions of Windows, and millions of customers running all sorts of weird crap on their machines that Ilfak doesn't have to worry about in order to maintain his job.

      Also, most people

    • Re:Microsoft can boost your notariety (Score:1, Interesting)

      by Anonymous Coward
      Have you ever used IDA Pro, which this guy wrote? If not, trust me, he doesn't need this to be regarded in the community. I think any security guy or cracker who has used IDA Pro respected him completely before this wmf thing came out.

    • The guy removes one line of code and becomes famous almost instantly. Why didn't anyone a Microsoft think of this solution?

      And if every guy at Microsoft removed a line of code, probably the final product would be far better.

  • Root of the problem (Score:4, Insightful)

    by Billosaur ( 927319 ) * <<wgrother> <at> <optonline.net>> on Friday January 06, 2006 @03:02PM (#14410858) Journal

    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.

    • Re:Root of the problem (Score:5, Insightful)

      by rewt66 ( 738525 ) on Friday January 06, 2006 @03:25PM (#14411051)
      This particular problem has a deeper root. The problem is that the code is working as designed, and is well-designed to do what was intended.

      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.

      • "All they will get you is a beautifully designed, perfectly coded boneheaded security hole."

          - at best.

        It might have bugs, which might close the security hole.

    • Re:Root of the problem (Score:2, Insightful)

      by dc29A ( 636871 )
      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.

      Hey now, programmers are
      • Yes programmers produce code with bugs, yes they do try to correct it until Mr.Manager comes in and tells them they need to ship yesterday.

        But... The point is they could be designing/coding in ways that reduce bugs from the start, not spending time later trying to hunt them down.
    • What it really boils down to is managers putting bug-free code over schedule. What it will really take is companies willing to spend the time and money to get it right the first time and to stop shipping stuff the first time the QA report lists fewer than 1000 bugs.

      But this is moot, because the WMF flaw is not a bug. It's a design problem. The code does exactly what it is supposed to. The trouble is that no one went back and examined these ancient APIs for security issues when people started hooking Win

  • Podcast Interview (Score:2, Informative)

    by Anonymous Coward
    Leo Laporte and Steve Gibson also interviewed him yesterday in their very professional sounding security podcast. [thisweekintech.com]
  • I love how the Slashdot Windows logo [slashdot.org] is a broken window, but all of the other OSes on this site have prefectly legit logos representing their topics. Must be a shout-out to all the Windows haters out there... Could we get a legit logo for Windows topics here? Something like this [computel.nl]?
    • we could but then we'd be sued for trademark infringement. The current logo is unique enough to be "artistic expression".
      -nB

  • Why not scramble all DLL's and EXE's on the fly? (Score:5, Insightful)

    by DoktorFuture ( 466015 ) on Friday January 06, 2006 @03:24PM (#14411046) Homepage
    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
    • you suggested:

      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?

      Now that sounds quite similar to M$'s "(un)Trustworthy Computing" bit. Since the keys and the encryption algorithm both reside on any given system, the decryption must take place within a (hardware embedded) subsystem in order to prevent the system software from being compromised. Uh, what happens if I want to install LINUX, or even when I just want to rein

      • Since the keys and the encryption algorithm both reside on any given system, the decryption must take place within a (hardware embedded) subsystem in order to prevent the system software from being compromised.

        No, it is perfectly safe to do this encryption / entry point calculation in software. The moment someone can run code on your system, you're screwed anyway. But in order to run code, they must 1) load the code to be executed into system memory, and 2) get the CPU to execute the code. Step 1 is stil

    • /* 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? */

      I think if MS did that, it may slow down the search for exploits until someone comes up with the de-scrambler. If the starting point of the scramble is on the system, the hackers will have a starting point to break it. From there it's just a matter

    • Re:Why not scramble all DLL's and EXE's on the fly (Score:5, Interesting)

      by Anonymous Coward on Friday January 06, 2006 @03:46PM (#14411212)
      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.
      • 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.

        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 [blogspot.com] the exploit.
        • Look on kyeu.com forums (I think it was).

          hardware DEP does stop the exploit under certain conditions, but installing other (seemingly unrelated) code invalidates the protection (because they are binaries packed with some special software and MS turns off DEP for those binaries since they wouldn't work otherwise).

          I'm surprised DEP worked at all on this, the flaw is a design flaw, not a buffer overflow exploit.
      • Just don't expect this to solve everything. The point of DoktorFuture was that people hardwire their exploits to existing code addresses, so hard that even a simple DLL relocation may break them. Even if all writable address space is no execute, you can get a buffer overflow to overwrite the RET pointer on the stack. In its place, you can write the address to a carefully chosen routine, and if you're really mean (and depending on the calling convention used), you might even get the possibility to tell what

    • 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?

      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 GU

    • Why not just auto-scramble the DLL code on the fly for every installation of the Windows OS?

      This would not prevent procedure call hijacking attacks, where an existing call to a procedure is given specially crafted parameters. Nor would it prevent exploits from using system calls directly. Just like preventing execution of code in the stack segment, the measure would make attacks harder, but would not prevent them.

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

    • Why not just auto-scramble the DLL code on the fly for every installation of the Windows OS?

      Because adding NOOPs will not change the behavior of the functions. Especially case in point, it would not have blocked this security hole. Nor would it really block any security hole.

      Exploits just attempt the exploitable behavior and if it works, then it works, if it doesn't then the exploit fails, but who cares? and it continues on.

      The problem with buffer overflows is the regularized position and size of the STAC
    • What you're thinking of is called address space layout randomization, and is implemented on Linux since some time ago (if you're a RH/Fedora user). There are commercial packages which add it to Windows, but AFAIK they carry a heavy performance penalty as the Win32 PE file format requires something called "rebasing" to move it around inside the address space. That requires binary patching of the in-memory DLL image by the linker, which makes them non-shareable, which increases memory consumption dramatically
  • From the article:

    You will have to download from one of the better-connected mirrors, as poor Ilfak has already had to move hosts once. I guess he's a victim of his own popularity. :-(

    Why can't we get credit for THAT? :( bummer!

  • Without Source Code (Score:2, Interesting)

    by AB3A ( 192265 )
    I think Microsoft deserves a great deal of criticism for their response to this exploit. Let's face it, exploits will always be a fact of life. How we deal with them is what separates the kids from the adults.

    In this context I find it quite amusing that Guilfanov was able to make a quick and effective fix without the benefit of the source code for gdi32.dll. In contrast the folks at Microsoft thrashed around for more than a week before realizing the significance and the simplicity of the fix.

    I wonder how

  • Also (Score:3, Informative)

    by shoptroll ( 544006 ) on Friday January 06, 2006 @04:43PM (#14411702)
    There's also an interview with him in yesterday's Security Now! podcast

    http://www.twit.tv/ [www.twit.tv]
  • In other news it is unclear if Microsoft will press charges under the DMCA, since this person is clearly a criminal because only by reverse engineering the Windows OS would it have been possible to create this patch...

Slashdot Top Deals

"More software projects have gone awry for lack of calendar time than for all other causes combined." -- Fred Brooks, Jr., _The Mythical Man Month_

Close