Slashdot Mirror


WINE Still Vulnerable to WMF Exploit

blast3r wrote to mention a ZDNet Blog posting by George Ou, stating that WINE is still vulnerable to the WMF flaw. From the article: "All applications launched inside Wine, Cedega, or Cross-Over Office are technically still exploitable. Wine runs on most x86 platforms, including Linux and the various BSDs. The surprising part about finding this flaw in Wine is that they implemented the entire Meta File API without realizing that this could be a security issue. Exploiting a Windows application running inside Wine depends on that application calling the vulnerable function with malicious data."

4 of 240 comments (clear)

  1. Immitation is the sincerest form of flattery by Schezar · · Score: 5, Insightful

    I suppose this speaks very highly of the WINE developers. After all, they're not out to make something better than Windows: they're out there to duplicate every broken, strange, or inexplicable behaviour Windows exhibits.

    Wine is Not an Emulator, but it's purpose is to allow all of us in Linuxland to use software developed for Windows. That means that it must replicate even the broken parts.

    Luckily, I assume two things:

    1. The WINE devs will plug this as soon as they get around to it.

    2. Anyone using WINE successfully is probably canny enough to make due until then without getting themselves compromised.

    --
    GeekNights!
    Late Night Radio for Geeks!
  2. Why should they realize it's a problem? by Weaselmancer · · Score: 4, Insightful

    The surprising part about finding this flaw in Wine is that they implemented the entire Meta File API without realizing that this could be a security issue.

    Remember, the goal of WINE is to duplicate the API as exactly as possible. And up until a few days ago, that *was* part of the API.

    WINE isn't supposed to be an improvement, just a duplication of the API so that win32 apps can run on x86 *nix. It should be no surprise to anyone that their implementation of the metafile API is exactly like the one in Windows. That's the point.

    --
    Weaselmancer
    rediculous.
  3. Re:I don't understand by cnettel · · Score: 5, Insightful

    The DLL in question is a common library used to load and view image files. The real WMF parsing is going on in GDI32 and Win32K.sys (GDI32 relies on Win32k, which is generally not called directly), though. So, you can't run explorer.exe from XP to get fancy thumbnails, but you CAN open an exploiting WMF file in several programs, and get the exploit all for free. As I noted in another comment, it's unlikely that a WMF effective on XP would also be effective on WINE, as it will probably be relying on the specific address space layout, though.

  4. The thing here is... by williamyf · · Score: 5, Insightful

    ... that when the WINE Coders were coding the Metafile APIs, they:

    1.) Did not realize this was a design flaw (most likely).
            or
    2.) Realized this was a security flaw and have been explioting it since years ago (highly unlikely).
              or
    3.) Have been urging Microsoft to change the code since they realized (highly unlikely, as well).

              The point I am trying to make is that this design flaw was not spotted by the many eyes of the WINE project, showing that even the OSS development model is subject to mistakes.

              The intent of this comment is not to say which development model is better, just to point out the fact that ALL development models are subjet to failures, and that our analysis should not be so unidimensional and binary, a thought that seems to be quite lost in this particular thread.

              As an aside, if this atack was made public in 12/27/05, and confirmed by Microsoft in 12/28/05, shoudnt have the WINE comunity tested for the flaw, posted a preliminary patch ASAP and then post a definitive patch that mimics the efect off the Microsoft patch? Why to produce the patch just AFTER Microsoft posted theirs, late by the comon wisdom of /.?

              My other question our regard a Turing-Complete "Image File Format", Postscript. Given the complexity in Postcript, is it not possible (but most likely harder, since it can not touch Filesystems) to do exploits in it?

              Just my two cents

    --
    *** Suerte a todos y Feliz dia!