Slashdot Mirror

← Back to Stories (view on slashdot.org)

Interview with Ilfak Guilfanov (WMF Patch Hero)

Posted by Zonk on 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.

16 of 167 comments (clear)

  1. SecuriTeam blogs by GrayWolf42 · · Score: 5, Informative

    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.

  2. Security Now! Interview by AnalystX · · Score: 2, Informative

    http://thisweekintech.com/sn21

  3. Re:From the Interview... by mobiux · · Score: 4, Informative

    Considering it went back to windows 98, i don't think they anticipated the current computing climate at all.

  4. Re:From the Interview... by cnettel · · Score: 4, Informative

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

  5. Re:Microsoft can boost your notariety by Rolan · · Score: 5, Informative
    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.
    --
    - AMW
  6. Actual link to the MS-official patches by mflorell · · Score: 3, Informative

    http://www.microsoft.com/technet/security/bulletin /ms06-001.mspx

  7. Podcast Interview by Anonymous Coward · · Score: 2, Informative

    Leo Laporte and Steve Gibson also interviewed him yesterday in their very professional sounding security podcast.

  8. Re:Microsoft can boost your notariety by cheezit · · Score: 4, Informative

    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.

    --
    Premature optimization is the root of all evil
  9. Re:ok... by Anonymous Coward · · Score: 1, Informative

    Enough software uses this functionality that Ilfak's patch broke a boatload of stuff (printing mostly).

  10. Re:You're missing the point, though by Diamon · · Score: 4, Informative
    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.
  11. A few reasons i can think of that complicate it.. by bmajik · · Score: 3, Informative

    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.
  12. Also by shoptroll · · Score: 2, Informative

    There's also an interview with him in yesterday's Security Now! podcast

    http://www.twit.tv/

    --
    Insert Sig Here
  13. Re:Why not scramble all DLL's and EXE's on the fly by Rufus211 · · Score: 4, Informative
    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 the exploit.
  14. Re:Why not scramble all DLL's and EXE's on the fly by Anonymous Coward · · Score: 1, Informative
    OpenBSD uses some MMU and 386 segment voodoo to make it so that W^X works even on Intel processors that don't have NX.

    In addition to W^X they have:
    • Software stack protector (propolice). I believe this has been merged into GCC 4.1, so maybe more Linux distros will have this feature in the coming years.
    • On SPARC, they protect the stack using hardware stack protection, using some SPARC assembly voodoo which I can't say I know much about.
    • Randomized heap locations. Any malloc() call returns an unpredictable memory location. Sure this won't solve stack-based exploits but having an uncorrupted heap (and crashing programs before they corrupt it) is a good idea.
  15. Re:You're missing the point, though by CFrankBernard · · Score: 3, Informative

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

  16. Yep, read my /. comment... by antdude · · Score: 2, Informative

    See here.

    --
    Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).