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

Comments

I had no idea...

[MichaelSmith]

...that wine provided so much of the normal windows user experience. I must start recommending it to my friends

So...

[ImaLamer]

Should I be worried about my Fake Windows security or am I at no risk as long as I don't run "sol.exe" as root?

How far can someone get by working over WINE with this exploit?

Kudos to WINE

[DrXym]

For implementing Win32 so closely that you can actually be infected with Win32 exploits. I suspect that the effects wouldn't be as bad as the real thing though.

On a serious note, I wonder what this means for emulation projects. If you recognize an exploit in the original environment (as possibly someone did when writing a WMF parser for WINE), do you implement the exploit in your emulator or do you introduce a potential incompatibility?

Re:Kudos to WINE

[Afecks]

On a serious note, I wonder what this means for emulation projects. If you recognize an exploit in the original environment (as possibly someone did when writing a WMF parser for WINE), do you implement the exploit in your emulator or do you introduce a potential incompatibility?

WINE IS NOT AN EMULATOR!

Make a copy?

[vandon]

Can't you just make a copy of the fixed gdi32.dll from a working windows machine?

Re:Make a copy?

[cnettel]

No, the Win32 version is (mostly) just calling down to the Win32K.sys file in the kernel. This isn't present in WINE. There are also other issues, but this single fact is the killer that makes it totally impossible to work. (aside from licensing issues :-)

Perfect emulation

[miscz]

This shows how great Wine is. It even emulates exploits and being late with the patches! Hurray for Wine!

I don't understand

[overshoot]

The WINE libraries don't even include an equivalent of the DLL that causes the problem for Microsoft.

How does WINE manage to duplicate a flaw in a function that WINE doesn't even implement?

Re:I don't understand

[cnettel]

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.

Immitation is the sincerest form of flattery

[Schezar]

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.

Not impressed

[Anonymous Coward]

Until I can get my Linux box rootkitted by Sony DRM.

Well, there you go...

[stinky wizzleteats]

All applications launched inside Wine, Cedega, or Cross-Over Office are technically still exploitable

That's 3 Unix/Linux vulnerabilities to 1 for Windows. Windows is more secure.

Cedega is not affected by this exploit

[gavriels]

Cedega is not affected by this exploit, as we don't support any META_ESCAPE commands in WMF playback at all.

And Marcus Messier's fix for WineHQ was checked in earlier today. 8-)

  -Gav

IT'S FIXED IN THE CVS

[Krach42]

Revision 1.12 / (download) - [select for diffs], Fri Jan 6 20:52:46 2006 UTC (111 minutes, 55 seconds ago) by julliard
Branch: MAIN
CVS Tags: HEAD
Changes since 1.11: +7 -0 lines
Diff to previous 1.11 (colored)

Marcus Meissner
gdi: Filter GETSCALINGFACTOR and SETABORTDOC proc in metafile
Escapes.

Which changed wine/dlls/gdi/metafile.c from:

case META_ESCAPE:
        Escape(hdc, mr->rdParm[0], mr->rdParm[1], (LPCSTR)&mr->rdParm[2], NULL);
        break;

To:

case META_ESCAPE:
        switch (mr->rdParm[0]) {
        case GETSCALINGFACTOR: /* get function ... would just NULL dereference */
            return FALSE;
        case SETABORTPROC:
            FIXME("Filtering Escape(SETABORTPROC), possible virus?\n");
            return FALSE;
        }
        Escape(hdc, mr->rdParm[0], mr->rdParm[1], (LPCSTR)&mr->rdParm[2], NULL);
        break;

This is first day response.

The thing here is...

[williamyf]

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