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?
So in this situaion, Windows systems updated with the most recent patch are more secure than machines running WINE.
TGIF cause stuff like this makes my head hurt.
"We make our world significant by the courage of our questions and by the depth of our answers." Carl Sagan
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!
does anyone use wmf files?
did you forget to take your meds?
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.
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.
What is this license you speak of and why would I need one for software?
"We make our world significant by the courage of our questions and by the depth of our answers." Carl Sagan
Apparently the exploit method in the GDI DLL is SETABORT (vector 9).4
http://blogs.securiteam.com/index.php/archives/18
-c0d3r-
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!
It's been a while since I've written any WMF software, but if I remember correctly, the problem here is with the general principle of a WMF, not a bug in any libraries, hence windows and wine both being vulnerable.
A wmf is not a graphics format in a traditional sense, but rather a list of API calls to the GDI libraries that when fired off one after another will recreate an image.
For this reason, saying that the WMF insecurity is a bug, is like saying that the fact that you can make a malicious EXE for windows is a bug also.
I'm not saying it shouldn't be fixed, becuase it is a vulnerability, I'm just trying to shine some light on why similar vulnerabilities exist in WINE.
If I have given an incorrect explanation of WMF, please feel free to comment.
Big ones, small ones, some as big as yer 'ead!
Give 'em a twist, a flick o' the wrist...
...is on Newsforge.
To answer another question I keep seeing:
"Does anyone actually use WMF anyway?"
There are actually some common uses of WMF on windows, but becuase it is a metafile of GDI calls, its not very portable (although it is easy to convert).
Since displaying a WMF is nothing more than enumerating the list into a 'select case' statement (not a very long one either) it is very easy and VERY fast to display on Windows. (Really no processing is required). For this reason, microsoft uses WMF for all the MS Office clipart, and you'll find many other very-microsoft centric applications using it as well.
Big ones, small ones, some as big as yer 'ead!
Give 'em a twist, a flick o' the wrist...
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?
I'm pretty sure a more accurate expansion of WINE is: Wine Is Not a (CPU) Emulator. See the Wine FAQ. As you correctly point out, Wine emulates (implements?) the Windows API, using the native CPU to execute code.
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!
Alan Paller at SANS keeps calling this a "programming error" which I think is a load of BS. This WINE article only proves it - this is poor design from management folks. The trick is, security needs to be a core part of system design from the initial phases of the software lifecycle, and then at every step of the software lifecycle. This is not something only for Programmers and pure-tech folks. Now your Project Managers, Analysts, and even your upper management needs to understand the COSTS AND ADDITIONAL TIME ASSOCIATED WITH HIGH-SECURITY PROGRAMMING.
Horns are really just a broken halo.
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?
It's not really a bug. It is in fact the documented function of the WMF files, and nobody (neither at Microsoft or WINE) noticed that it was in fact a security hole. Since it is documented there was no trouble replicating it's behavior.
exactly. to run the "WINE autoupdater" open a console and type the following commands:
export CVSROOT=:pserver:cvs@cvs.winehq.org/home/wine
cvs login
the password is "cvs"
cvs -z 3 checkout wine
cd wine
./configure
make
su
enter root password
killall -s KILL wineserver
make uninstall
make install
exit
cd..
rm -rf wine
wineconfig
that's all! ;-) (the exploit is fixed in the cvs tree)
;-)
of course you can make this even more "auto-ish" if you put the above commands into a textfile, call "chmod +x" on that file and click on it
It's more complicated than WMF just being able to call anything inside GDI32.dll. This is demonstrated by the fact that SetAbortProc was never allowed, the way to do it in WMF was using the Escape function, which has an obsolete escape code for adding an abort proc in the context where it makes sense, for printer spooling.
So the oversight is that an escape code was included for setting an abort proc, and there were valid uses for escape codes in WMF. The explicit and current way to set an abort proc was never allowed.
WMF is not supposed to be any kind of code affecting the display and certainly not arbitrary x86 code. Therefore, this is a bug, but the bug was caused by the format design omission to allow the specific escape code used.
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.
But I do place blame on the OSS community.
Allow me to quote from Engaging with The Open Source Community:
This flaw was staring the OSS community right in the face for all this time, yet the OSS community failed to find it. Of course, I'm being too hard on the OSS community. I wouldn't expect that community to find this problem. But nor should you. The "many eyes" claim is a canard because in truth very few people not involved in the actual development of a particular piece of code actually examine that code for flaws, and even fewer can identify a flaw even if it's staring them in the face as clearly as this one.
-- "I never gave these stories much credence." - HAL 9000
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.
I have the latest test files created from version 1.17 both OFFLINE and ON-LINE as well as zip files for the last two prior releases 1.16 and 1.14 located here: http://www.dslreports.com/forum/remark,15188688#15 188722
They can be used for testing, also there is an patch NOT supported by Microsoft for those running Windows 98 here:
http://www.nod32.ch/en/download/tools.php
It should be noted that these files have been used for many days and are safe for testing.
Black Gray White Hats Unite to protect http://testing.OnlyTheRightAnswers.com