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

Finally!

[A beautiful mind]

We can say now that Linux is truly ready for desktop because it catched up to Windows in these important features aswell!

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!

Re:Kudos to WINE

[IamTheRealMike]

FWIW I've spent several years as a Wine developer, and I definitely consider it to be emulation.

That said, this story is just a lot of scaremongering from ZDNet. Sure, you could be hacked through this if you run IE in Wine and use it as a general web browser (which I doubt anybody does), but the damage would be limited to the virtual Windows environment which can be blown away and reset in 20 seconds. It's not like the reinstall from scratch job a real Windows would require. Wine also ignores any startup entries software may install.

Still, it should be fixed, probably in the same way that MS did it. And in fact Marcus has already posted a patch that would do this, so I expect it'll be fixed soon enough.

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

Transmeta Crusoe

[suso]

This reminds me of the initial press release on the Crusoe, one of the clueless reporters in the audience thought that the Crusoe would somehow avoid Windows crashing. One of the Transmeta people pointed out to him that if Windows crashes, the Crusoe will faithfully crash in the same way.

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.

Why should they realize it's a problem?

[Weaselmancer]

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.

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.

The traditional "joke", with a twist?

[Jugalator]

For WINE users, here's a patch.

Wow, I could never imagine this time would come, after all those here's a patch jokes!

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 "if your second wife doesn't scream" test

[MarkusQ]

"a set of bundled libraries designed to be API compatible"

"designed to mimmick the behaviour of another piece of hardware or software in order to achieve the same functionality"

What's the difference?

Aren't the libraries bundled with WINE written to mimmick the responses of the equivalent Windows APIs? Sounds like emulation to me.

I've always assumed that they were making the first wife / second wife distinction.

Your second wife may provide all the services that you first wife did ("Please pass the salt" gets the salt handed to you just as before) but that is only an implementation of the same API--it doesn't mean that your second wife is "emulating" your first wife.

If, on the other hand, your second wife discovers that your first wife used to have some bizarre behaviour (say, she would occasionally wake up screaming "Now Dasher! now, Dancer! now Prancer and Vixen! On, Comet! on, Cupid!" etc. in an overly excited voice even when it was nowhere near christmas) and your second wife decided to start doing it too solely because it's what your first wife did, that would be emulation.

To give a less whimsical example: a browser such as Opera isn't "emulating" Firefox just because they both render HTML, support javascript, etc. Only if the Opera folks were to add a "Firefox quirks mode" that also attempted to duplicate all the overt behaviour of Firefox would they be "emulating" it. (And to be "simulating" they would have to be duplicating the overt behaviour by virtue of having in some sense the "same" internal structure.)

-- MarkusQ

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