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

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.

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

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