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."
We can say now that Linux is truly ready for desktop because it catched up to Windows in these important features aswell!
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
...that wine provided so much of the normal windows user experience. I must start recommending it to my friends
http://michaelsmith.id.au
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?
Get your Unix fortune now!
So that they can add it to their already lengthy list of known LINUX exploits!
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?
Can't you just make a copy of the fixed gdi32.dll from a working windows machine?
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.
After all, from winehq.org: "Wine has always strived for "bug for bug" compatibility"
Georgia Tech, the leader in Chia(tm) technology.
This shows how great Wine is. It even emulates exploits and being late with the patches! Hurray for Wine!
How does WINE manage to duplicate a flaw in a function that WINE doesn't even implement?
Lacking <sarcasm> tags,
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!
Until I can get my Linux box rootkitted by Sony DRM.
it doesn't have to be a wmf file to be effected. jpg, gif, bmp, that use wmf headers can still execute code.
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.
Well, if you run as the same user as your normal home directory, it can be devastating enough. It's not like you need to be root to send out a thousand mails with your "personal" pictures transformed into virus vectors.
Think statistics.
How many applications that pass WMFs (ie: email clients and browsers) do you use under linux that require Wine? Now how many do you use under windows that would be potentially exploited?
This is far less serious for Linux users than Windows users.
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
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.
For WINE users, here's a patch.
Wow, I could never imagine this time would come, after all those here's a patch jokes!
Beware: In C++, your friends can see your privates!
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
Which changed wine/dlls/gdi/metafile.c from:To:This is first day response.
I am unamerican, and proud of it!
Six days after m$ft learned of the vulnerability, we were all yelling that it shouldn't take that long for a fix and thank heavens that open source projects could always churn out fixes so much quicker. Well, the open source wine has now had 3 days. Does that mean that if wine takes another 3 days, then we've proven that open source isn't always faster with fixes?
Just: cvs update && make World && sudo make install
Patched, Fixed, Done.
If you RTFA, you'll even see that the very person to report that WINE was flawed the same as Windows submitted a patch to fix the problem along with his notice that it was broken.
THAT is how fast OSS is. The very vulnerability announcement says how to fix it.
I am unamerican, and proud of it!
slashdot design looks strange today
You just want me to commit a felony by refreshing it to see if I see what you see, don't you?
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
... 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!
But the facts are that the original design was made pre-Win3.0, long before the rise of the internet as we know it today. It's not surprising that the design flaw arose in that environment, and the design was used to deal with the hodge-podge of various printer behaviors from those days. And I don't particularly blame the actual handful of Wine devs that implemented the "whole API" and therefore inherited this design flaw.
Are you being smug or are you trolling on purpose? There was no pre-Win3.0 gdi32.dll. There was no hodge-podge of printer support. They all printed to LPT1 with thier own escape-codes that the software developers implemented. I print to my year old Samsung laser using my twenty year old AppleWorks. You do know that WINE can use its own built-in DLLs or Win32 native DLLs, don't you? I can switch Wine to use the Gdi32.dll that Microsoft just provided for free.
This flaw was staring the OSS community right in the face for all this time, yet the OSS community failed to find it.
I don't think the Wine Developers are looking for flaws. Most of us use Wine to play Windows Games. In what aspect is my WINE/Linux environment compromised by this Microsoft flaw? There is no kernel to infect. Are the rootkit trojans going to infect my Starcraft session and turn the Zerg into lemmings? Are you mentally challedged?
We appreciate that you like Windows, stay there. When your ready to switch to a environment that doesn't believe that you owe a fee every three years and that you own your own stuff, let us know.
Enjoy.
It's just the normal noises in here.