WINE Still Vulnerable to WMF Exploit 240
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."
Immitation is the sincerest form of flattery (Score:5, Insightful)
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.
Re:serious question (Score:3, Insightful)
Why should they realize it's a problem? (Score:5, Insightful)
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.
Re:I don't understand (Score:5, Insightful)
Re:Mud Wiggle saith (Score:1, Insightful)
Re:That's just wrong... (Score:4, Insightful)
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.
Re:Kudos to WINE (Score:2, Insightful)
An emulator is a replimentation, but it is not a mere reimplimentation of something. They are reimplimentations at different levels. Normally it's with parts of hardware mimicked by software.
Wine is at basically the same level as the original Windows...it's a bunch of libraries that have functions in them. These libraries do stuff, and sometimes talk to the OS. (And, in the case of Wine, X.)
There are a few parts of it where you could argue there is 'emulating' going on, where the software doesn't actually talk to any hardware, it just claims to, but wine is not itself an emulator, even if small parts are.
1) Whether there is anything beside that that could legitimately be called an emulator is an interesting question.
Re:Uh, oh . . . somebody had better notify CERT. (Score:3, Insightful)
Re:Kudos to WINE (Score:3, Insightful)
"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.
It's already fixed in CVS anyways (Score:4, Insightful)
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.
Re:Immitation is the sincerest form of flattery (Score:2, Insightful)
The responsible thing for the WINE developer(s) to do is to tell Microsoft about this serious hole, and not implement it until there is a sufficient need. Even then, it should be enabled only in a "quirks" or bug-compatibility mode, because it is dangerous. I can't believe the developer(s) are being complimented ("speaks highly of them") for quietly implementing a security hole.
Now, I don't think they should be blamed for not realizing the problem (the original authors did not, either). Being volunteers, they're also under no obligation to do anything. But ignorance or inaction is hardly a cause for compliment, is it?
Just imagine what you'd be saying if Microsoft found a security hole in POSIX, and quietly just implemented the hole to spec. Now imagine what you'd say if they didn't realize that there was a hole there. Would you be complimenting them for either case?
Re:Mud Wiggle saith (Score:1, Insightful)
Re:Programming Issue? No way! (Score:2, Insightful)
WMF became obsolete soon, and was forgotten. It's perfectly normal to forget to review code that old, especially if the programmers who wrote it have probably been retired by then. Hell, many people have probably never seen a WMF file before.
The thing here is... (Score:5, Insightful)
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
Peer review of "many eyes" should've caught this (Score:2, Insightful)
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 [theinquirer.net]:
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.
Re:Kudos to WINE (Score:3, Insightful)
In the technical terminology of Computer Science, an emulator is some system which intentionally behaves like some other system. From a technical perspective, it doesn't matter at all if you are emulating hardware or software... conceptually, it's all the same thing.
The people who argue "Wine is not an emulator" are incorrectly using "emulator" as an abbreviation "hardware emulator", since that was the first place they heard of "emulator" programs.
That's similar to how some people act like "console" means a video-game machine, when really there are many other kinds of consoles.
Re:Kudos to WINE (Score:3, Insightful)