Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security Software Wine Linux

WINE Still Vulnerable to WMF Exploit 240

Posted by Zonk from the patch-up-young-linux-users dept.
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."
This discussion has been archived. No new comments can be posted.

WINE Still Vulnerable to WMF Exploit More

WINE Still Vulnerable to WMF Exploit

Comments Filter:

  • Finally! (Score:4, Funny)

    by A beautiful mind ( 821714 ) on Friday January 06, 2006 @05:34PM (#14412197)
    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... (Score:5, Funny)

    by MichaelSmith ( 789609 ) on Friday January 06, 2006 @05:36PM (#14412211) Homepage Journal

    ...that wine provided so much of the normal windows user experience. I must start recommending it to my friends

  • So... (Score:5, Interesting)

    by ImaLamer ( 260199 ) <john.lamar@gma[ ]com ['il.' in gap]> on Friday January 06, 2006 @05:36PM (#14412213) Homepage Journal
    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?

    • Re:So... (Score:4, Interesting)

      by Craig Davison ( 37723 ) on Friday January 06, 2006 @05:57PM (#14412393)
      You don't need to be root to send out 1000 spams/minute.
    • most likely they can get whatever privilages wine is running with. so in a normal linux desktop that would probablly mean the users data and normal user level network access (so it could hit any non-secured rescourses on the lan, send spam etc but couldn't mess arround with low level packets or listen on a privilaged port).

      and if the user ever uses su/unrestricted sudo then they could get root by laying a trap.

  • Uh, oh . . . somebody had better notify CERT. (Score:3, Funny)

    by mmell ( 832646 ) on Friday January 06, 2006 @05:36PM (#14412221)
    So that they can add it to their already lengthy list of known LINUX exploits!

  • Kudos to WINE (Score:5, Interesting)

    by DrXym ( 126579 ) on Friday January 06, 2006 @05:37PM (#14412227)
    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?

    • You add a configuration flag, defaulting it to OFF.

      I would also guess that it's quite uncommon that the same exploting code actually works, as many addresses will be different from a normal XP system. The same vector, i.e. a malformed WMF file resuling in a call to the abort proc of choice, is still possible, though.

    • Re:Kudos to WINE (Score:5, Funny)

      by Afecks ( 899057 ) on Friday January 06, 2006 @05:52PM (#14412348)
      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!
      • And GNU is Not Unix...
      • WINE IS NOT AN EMULATOR!

        I hear quite often how WINE is merely an implementation of the Win32 APIs, etc, but this begs one question:

        If Microsoft made some error in implementing their own Win32 API, i.e. not to the correct specification, would the WINE developers implement the Win32 API as it 'should be' (thus breaking applications that use it), or would they 'emulate' the broken code? I have a distinct feeling that it'd be the latter.

        • If Microsoft made some error in implementing their own Win32 API, i.e. not to the correct specification,

          According to Microsoft, if such a situation were to arise, the specification would be in error. Where differences exist between Microsoft's documentation and Microsoft's implementation, the implementation is correct. (At least in released code.)

    • Re:Kudos to WINE (Score:2, Informative)

      by Quantam ( 870027 )
      What I want to know is whether Wine is vulnerable to this [uninformed.org] design flaw that allows hardware enforced data execution protection to be remotely disabled by a clever buffer overflow (one that injects no code of its own, so cannot be prevented by DEP). I should mention that I submitted this story to Slashdot, but it was rejected.

  • Make a copy? (Score:5, Interesting)

    by vandon ( 233276 ) on Friday January 06, 2006 @05:37PM (#14412232) Homepage
    Can't you just make a copy of the fixed gdi32.dll from a working windows machine?

    • Re:Make a copy? (Score:5, Informative)

      by cnettel ( 836611 ) on Friday January 06, 2006 @06:05PM (#14412441)
      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 :-)
  • 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.

    • Re:That's just wrong... (Score:4, Insightful)

      by Fordiman ( 689627 ) * <fordiman@g[ ]l.com ['mai' in gap]> on Friday January 06, 2006 @06:11PM (#14412475) Homepage Journal
      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.

    • So in this situaion, Windows systems updated with the most recent patch are more secure than machines running WINE.

      Possibly in theory, but not likely in practice. I would bet that most people who have Wine installed don't actually even use it. The rest of the people that do use it likely only use it for a handful of specific programs.

      • Well i don't use ie in windows, but that doesn't mean I can't get attacked through it. :)

        I think its sad that Microsoft beat open source to a patch. Lets get it together people!

  • Transmeta Crusoe (Score:5, Informative)

    by suso ( 153703 ) * on Friday January 06, 2006 @05:38PM (#14412242) Journal
    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.

  • Isn't that the Goal? (Score:3, Interesting)

    by lordofthechia ( 598872 ) on Friday January 06, 2006 @05:38PM (#14412244)
    After all, from winehq.org: "Wine has always strived for "bug for bug" compatibility"

  • Perfect emulation (Score:5, Funny)

    by miscz ( 888242 ) on Friday January 06, 2006 @05:39PM (#14412255)
    This shows how great Wine is. It even emulates exploits and being late with the patches! Hurray for Wine!

  • serious question (Score:3, Interesting)

    by js3 ( 319268 ) on Friday January 06, 2006 @05:40PM (#14412261)
    does anyone use wmf files?
    • it doesn't have to be a wmf file to be effected. jpg, gif, bmp, that use wmf headers can still execute code.
    • Yes.

      This website for example has quite a bit of WMF files. The internet is teeming with them. Oh, you think they have to end in .wmf, I see. Well, you'd be mistaken. Any image format (_any_) that Windows understands is a WMF file. That's right, all of them. Not only that, but quite a few document formats also fall under that umbrella, but most of them are Windows-proprietary anyways.

      Thanks for trolling!

      • Re:serious question (Score:2, Informative)

        by cnettel ( 836611 )
        Nice story, but it's wrong. A Windows meta file is a spooled set of GDI commands, nothing more, nothing less. That said, some high-level picture libraries will look for several types of image headers in the files they're fed, no matter the extension. The LoadBitmap API in GDI will not. You can load a BMP, JPG or PNG that way in any recent Windows release.

        Get your facts straight or stop feeding the trolls.

      • Re:serious question (Score:2, Informative)

        by jlarocco ( 851450 )

        A WMF file is a very specific file format that contains a list of Windows GDI calls that describe how to draw an image. So obviously, most images on the interweb are not WMF files.

        It is possible to make a WMF file that lists the GDI calls to display a GIF/JPG/whatever file, but that still doesn't make the GIF/JPG/whatever files themselves WMF files.

    • A small business that I do some consulting for has stacks (literally) of CD's containing clipart in WMF format. Based on that, I would say that WMF appears to be a common format for commercial-off-the-shelf clipart disks.

  • I don't understand (Score:5, Interesting)

    by overshoot ( 39700 ) on Friday January 06, 2006 @05:43PM (#14412278)
    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 (Score:3, Interesting)

      by makomk ( 752139 )
      I expect it's like Windows 98 - you can't get infected by websites, but you can get infected by viewing a WMF using some program that uses the Windows API to display them. (For example, most Word clipart is WMFs, IIRC.)

    • Re:I don't understand (Score:2, Informative)

      by Anonymous Coward
      The flaw is in gdi32.dll; WINE implements gdi32.dll I'm not sure if WINE implements shimgvw.dll, but that is not where the flaw technically is; that just happens to be the easiest way to exploit the flaw.

    • Re:I don't understand (Score:4, Funny)

      by A beautiful mind ( 821714 ) on Friday January 06, 2006 @05:50PM (#14412332)
      "/* Heavy wizardry */"

      (If you know Perl, you'll understand)

    • Re:I don't understand (Score:5, Insightful)

      by cnettel ( 836611 ) on Friday January 06, 2006 @05:54PM (#14412369)
      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.

    • I seem to remember that if you have Windows installed on another partition, WINE can optionally use the original Windows DLLs. Presumably, this is the configuration that is vulnerable.

    • Re:I don't understand (Score:3, Informative)

      by Tim Browse ( 9263 )
      I very much suspect that WINE does implement the parsing/decoding of WMF files, and that is where the problem is. The WMF format allows the file to specify an error handler, which is the cause of the problem.

      Don't get hung up on gdi32.dll or shimgvw.dll or whatever - it's the API itself that WINE implements, not specific DLLs and entry points (although it might provide shim for those for some apps) and that's where the problem is.

    • The WINE libraries don't even include an equivalent of the DLL that causes the problem for Microsoft.

      http://cvs.winehq.org/cvsweb/wine/dlls/gdi/ [winehq.org]

      WTF are you talking about?
  • So all you have to do is run the WINE autoupdater? :-)
    • So all you have to do is run the WINE autoupdater? :-)

      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 a

  • Immitation is the sincerest form of flattery (Score:5, Insightful)

    by Schezar ( 249629 ) on Friday January 06, 2006 @05:46PM (#14412308) Homepage Journal
    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.
    • You're just the first one I came across, so:

      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 origina

  • Not impressed (Score:5, Funny)

    by Anonymous Coward on Friday January 06, 2006 @05:50PM (#14412333)
    Until I can get my Linux box rootkitted by Sony DRM.

  • Why should they realize it's a problem? (Score:5, Insightful)

    by Weaselmancer ( 533834 ) on Friday January 06, 2006 @05:52PM (#14412352)

    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.

    • The point was that if they spent the time working with this format and re-implementing it in WINE, they should have seen the potential exploit. Instead they blindly implemented it without analyzing the format (which you can't really blame them, considering how much crap they have to parse through).
      • Even if one assumed that they did see it, they'd still have to implement it, because it is part of the API, which they're trying to clone. It's not too hard to get that concept, is it???
        • A formal API is basically published documentation about how it works. Since Microsoft hadn't published the docs about every quirk of their implementation of their APIs, there's a lot of flexibility in how it will be implemented.

          WINE takes that a step farther, though.. they're trying to implement the undocumented behaviors too. They do this mostly by running known-working windows software and seeing where it breaks in WINE. Where it breaks, this indicates a place where the WINE implementation of the API e
          • Have you actually read how the exploit works? WMF allows arbitrary access to the graphics system and thus code execution by design. That is not "undocumented"...
            • While technically right, it's more like "they allow access to most of GDI, including one devastating method that allows you to feed a pointer to a callback proc if rendering fails".

              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

  • GDI DLL Exploit Method (Score:2, Informative)

    by c0d3r ( 156687 )
    Apparently the exploit method in the GDI DLL is SETABORT (vector 9).
    http://blogs.securiteam.com/index.php/archives/184 [securiteam.com]
    -c0d3r-

  • Well, there you go... (Score:5, Funny)

    by stinky wizzleteats ( 552063 ) on Friday January 06, 2006 @06:16PM (#14412504) Homepage Journal
    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? (Score:5, Funny)

    by Jugalator ( 259273 ) on Friday January 06, 2006 @06:18PM (#14412524) Journal
    For WINE users, here's a patch [microsoft.com].

    Wow, I could never imagine this time would come, after all those here's a patch [mozilla.com] jokes!
  • This just goes to show the WINE project's dedication to accurately reproducing the Windows libraries.

    *drum hit*

    Thank you, thank you, next show at 10!

  • Cedega is not affected by this exploit (Score:5, Informative)

    by gavriels ( 55831 ) on Friday January 06, 2006 @06:45PM (#14412807)
    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
  • Doesn't this revelation kinda fly in the face of one of the arguments of OSS that it is more secure because more eyes are seeing it?

    Here we've got at least two sets of eyes that missed it, not just the folk(s) who wrote the Wine code, but also the one(s) who wrote the original implementation for Windows... and the only time the flaw was discovered in Wine was AFTER the Windows one was... presumably because someone looked to see if Wine was vulnerable as well.
  • Well, I can't say I'm very surprised to read this news :) [slashdot.org]

    However, I can't quite shake off the creeping suspicion that I've got something terribly, terribly wrong in my model of the world, though, that I feel I have to point out that I told you so. Please, say it isn't just me!!

  • 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 wi
    • 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
    • It is partly right, but this is a vulnerability just like being able to write a Javascript that alters files on your HD is a vulnerability. Javascript is even Turing complete (WMF isn't), but the important point is the domain you are executing in. There are plenty of GDI functions that you CAN'T call from a WMF, like setting an abort proc in another manner than the one used here, or getting a device context to draw in another window in the same session. In fact, I think you are not supposed, or allowed, to

  • My favorite review of this subject... (Score:3, Funny)

    by jeremy_white ( 598942 ) * on Friday January 06, 2006 @06:55PM (#14412918) Homepage
    ...is on Newsforge [newsforge.com].

  • How long should a fix take? (Score:3, Interesting)

    by MeBot ( 943893 ) on Friday January 06, 2006 @06:57PM (#14412942)
    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?

  • Programming Issue? No way! (Score:3, Informative)

    by Heembo ( 916647 ) on Friday January 06, 2006 @07:20PM (#14413152) Journal
    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.

    • Re:Programming Issue? No way! (Score:2, Insightful)

      by Anonymous Coward
      Except that the WMF format was created, what, more than 15 years ago? Not many people had computers then. Or the Internet. Or the bandwidth to share pictures through BBS's. Even if someone had found the exploit, it wouldn't have spread over more than, say, two or three computers worldwide. High-security programming? WTF? There was no *NEED* for high-security programming back then.

      WMF became obsolete soon, and was forgotten. It's perfectly normal to forget to review code that old, especially if the programme
    • Yeah, that was a big concern back in the late 80's when WMF was developed for Windows 3.0 (AKA DOS but prettier). There was no elevated privleges, memory protection, or even networking to speak of. Heck, if you wanted to screw with something, all you had to do was write a TSR to hook into an interrupt.

      I agree, it probably should have been taken care of in the interim, but I wouldn't classify it as poor design (for the times).

  • The thing here is... (Score:5, Insightful)

    by williamyf ( 227051 ) on Friday January 06, 2006 @10:23PM (#14414482)
    ... 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

Slashdot Top Deals

One man's constant is another man's variable. -- A.J. Perlis

Close