| Summary: | app-emulation/wine is vulnerable to wmf exploit (CVE-2006-0106) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Carsten Lohrke (RETIRED) <carlo> | ||||||
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | normal | CC: | ari, basic, eldad, flash3001, genbug, johnherdy, m.debruijne, toto | ||||||
| Priority: | High | ||||||||
| Version: | unspecified | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | B2 [glsa] DerCorny | ||||||||
| Package list: | Runtime testing required: | --- | |||||||
| Attachments: |
|
||||||||
|
Description
Carsten Lohrke (RETIRED)
2006-01-06 14:08:26 UTC
Created attachment 76431 [details, diff] upstream patch for wmf exploit Patch already checked into WineHQ's cvs. http://cvs.winehq.org/cvsweb/wine/dlls/gdi/metafile.c Created attachment 76432 [details]
wine-0.9.5 ebuild bumped to -r1 applying upstream fix
Updated wine-0.9.5 ebuild to include the upstream fix. Applied cleanly, building now and I'm not expecting any problems so submiting ebuild.
ok, waiting for an ebuild that is ready to be marked stable (ie. approved by the wine herd and if possible, commited to portage) The version numbering issue blocks this, since users won't get the fixed Wine version. There's also the question, if WineX/Cedega/Transgaming stuff is affected, too. mhh, maybe backport the fixes and makes a revbump of the 2005XXXX ebuilds as workaround for the version number issue? I can't check cedega/transgaming and so on, because i don't own a copy, so i guess wine herd has to find that out. we dont maintain cedega, that is all handled upstream ive added the patch to all ebuilds and moved wine-20050930 to stable as for unstable, i dont really see the big deal with waiting for a 0.9.6 release to pushout the version bump (In reply to comment #6) > we dont maintain cedega, that is all handled upstream We do care for it by hard masking the vulnerable ebuilds, when upstream doesn't provide an update in an acceptable amount of time. ready for glsa *** Bug 118373 has been marked as a duplicate of this bug. *** the patch is applied to ebuilds without a rev.bump, this results in glsa-check not being able to detect if a system is vulnerable, by all means don't be offended, but there is a lot of noise on the dev.list about enterprise gentoo, first must be sure that users can rely on glsa's and related tools for no less then 100%, if it isn't standard procedure that security fixes are rev.bumped then enterprise gentoo will never be a reality, changing glsa-check to be able to detect if a system is vulnerable without depending on ebuild-versions is off course also a posibility. All the stable versions were rev-bumped, unstables are fixed but as you can see in comment #7, we're waiting for a new upstream release. SpanKY (or somebody else) could you commit a simple rev-bump of the latest unstable so everybody is happy? (Btw, i'm not payed for this, so i dont care too much about enterprise gentoo) i'll revbump if a new wine release isnt made along their normal timeframe GLSA 200601-09 is out. I just checked my system with glsa-check and GLSA-200601-09 is wrong. a) all versions of wine-0.9* have the wmf-patch included, but are marked as vulnerable in the GLSA b) the wine-20050930 is marked as not vulnerable, but does NOT contain the patch (The commit http://www.gentoo.org/cgi-bin/viewcvs.cgi/app-emulation/wine/wine-20050930.ebuild?r1=1.7&r2=1.8 has the comment 'Add upstream patch for WMF exploit #118101', but only marks this ebuild stable without adding the epatch line!) Thx for the report Torsten. Back to ebuild, vapier please apply patch. @ a) If patches are are applied to older ebuilds without rev-bumping them, installs from before the update are still vulnerable. hmm, must have changed all of the 200x on the remote test box and forgot to commit local versions 200* are all now -* 0.9.x are all now stable stable users will be upgraded to 0.9.5 now ready for errata >> I just checked my system with glsa-check and GLSA-200601-09 is wrong. >>a) all versions of wine-0.9* have the wmf-patch included, but are marked as vulnerable in the GLSA >>b) the wine-20050930 is marked as not vulnerable, but does NOT contain the patch OK, that is pretty slack work for Gentoo security team just banging out the usual comment "please update to most recent version" without even checking what verson they were advising people to use. But now this is a security issue HOW ABOUT someone actually dealing with the version nonsense in wine. This 20050930>0.9.x thing has been a bug in portage for six wine versions now. I posted it in October. Reposted to it twice since then. The reason it was not dealt with correctly was probably that it was marked FIXED when the fix was not to fix it. :? Maybe now would be a good time to get half of gentooland past 20050930. regards. > But now this is a security issue HOW ABOUT someone actually dealing with the > version nonsense in wine. This 20050930>0.9.x thing has been a bug in portage > for six wine versions now. hey jackass why dont you read what has changed > Maybe now would be a good time to get half of gentooland past 20050930. already done, why dont you sync up your tree and check the facts before complaining (In reply to comment #20) > > But now this is a security issue HOW ABOUT someone actually dealing with the > > version nonsense in wine. This 20050930>0.9.x thing has been a bug in portage > > for six wine versions now. > > hey jackass why dont you read what has changed > > > Maybe now would be a good time to get half of gentooland past 20050930. > > already done, why dont you sync up your tree and check the facts before > complaining > yeah right dickhead, if you want to get really grown up about this, you made a change to gentoo cvs six hours ago. [Sat Jan 14 18:39:32 2006 UTC] So how about giving it time to get to the mirrors before throwing insults. According to my system my last sycn was 18:50:01 CET , so I should not even be thinking of loading the mirrors again so soon. If my system did not pick up the changes it's probably because you forgot to commit them. It took you four friggin months to move on this and now you're getting smart because I dont sync 4 times a day. kind regards, jackass. Let's drop the insults now ,eh? the reason for my pissyness was how you so offhandly refer to the security team this isnt their fault, it was mine and really i could care less about the time frame of the wine stuff, i sat on it because any solution to the issue sucked (In reply to comment #22) > the reason for my pissyness was how you so offhandly refer to the security team > > this isnt their fault, it was mine > > and really i could care less about the time frame of the wine stuff, i sat on > it because any solution to the issue sucked > Thanks, I think the calmer approach is better. I'm not sure this is the most suitable place to go into the details of the security post but I think they could have been more rigourous in serveral respects, putting aside your mistake. However I dont believe that the earlier outburst was on their behalf , people usually react like that when they feel themselves critisised not others. It seems in keeping with your ingenuous attitude I have seen before, you slip a mod through then start sounding off at people hoping no-one will notice the timing. I recall a very similar instance with the reiser4progs ebuild. That aside, I give you credit for fairly accepting your mistake on this one and for coming back with a more reasonable tone. I admit I was expecting another flame, beg your pardon. I accept that in view of the glsa issue you had to do the quickest thing that did not require too much checking but I think a better solution could/can be found for wine. Wine can be very fickle and the older versions are quite often needed. Best regards. 0.9.5-r1 in portage to push out the patch changes crossover-office-*-5.0.0 is also effected, a fix was issued with 5.0.1. http://crossover.codeweavers.com/pipermail/announce/2006-January/000031.html BTW, regarding cedega, since portage doesn't carry the cedegea "engine", only the wrapper (the -small package), the upgrade is up to the users to update their engine. crossover office cannot be upgraded unless someone gives me the file name/size/md5 information as i have no access to said files just mailed codeweavers for the info, but also got the md5sum/size from #crossover on freenode: MD5 96bea3142fd096db88186f7233c5d43c install-crossover-standard-5.0.1.sh 16160351 MD5 847d4a3d7cb23d4931fc5e04ea243f53 install-crossover-pro-5.0.1.sh 16177282 Crossover office will be handled in bug #119107 thanks, added 5.0.1 to portage ERRATA issued. Thx for the notification. |