| Summary: | media-libs/win32codecs <win32codecs-20071007-r2 - multiple vulnerabilities in included quicktime dll | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Carsten Lohrke (RETIRED) <carlo> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ansla80, fauli, flameeyes, jaervosz, media-video, pacho, wendallc, ziga.boehm |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | B2 [glsa] jaervosz | ||
| Package list: | Runtime testing required: | --- | |
|
Description
Carsten Lohrke (RETIRED)
2006-10-06 07:48:31 UTC
media-video, pls comment media-video, are there updated packages available? this bug is becoming old (In reply to comment #2) > media-video, are there updated packages available? Not from upstream, no, there havent been any updates http://www.mplayerhq.hu/MPlayer/releases/codecs/ChangeLog Setting it to upstream for now. Any news from upstream on this one? MPlayer has been patched to address this issue. You can get the patch here: http://www.mplayerhq.hu/MPlayer/patches/asmrules_fix_20061231.diff Announcement here: http://www.mplayerhq.hu/design7/news.html HTH, Wendall (In reply to comment #6) > MPlayer has been patched to address this issue. You can get the patch here: > http://www.mplayerhq.hu/MPlayer/patches/asmrules_fix_20061231.diff > Announcement here: > http://www.mplayerhq.hu/design7/news.html > mplayer is handled on bug 159727, but what about media-libs/win32codecs upstream? i don't know You are correct. I don't know what the status of these are, or even if they are valid. Will report back here. This has been outstanding for a very long time, and should either be masked or fixed if valid. Wendall These vulnerabilities do not effect MPlayer. Comments from MPlayer devs: 1. MOV,SGI format support is non-existent (these are called demuxer) and mplayer cannot use binary demuxer 2. FLC and H.264 is supported only by native. there are few dshow,vfw h264 decoders, but we don't use QT one. 3. FPX is not supported at all. However that said, xine is vulnerable. And this package should be marked with a big "SECURITY UNSUPPORTED" stamp and masked. Maybe instructions on how to unmask. I'm sure as old as the "stable" version of this package is, there are dozens of vulnerabilities. Wendall what about removing the quicktime dll from the win32codec package? (In reply to comment #10) > what about removing the quicktime dll from the win32codec package? > I believe they all natively work in ffmpeg anyway, so it's probably the best solution. I still need to check and get a good list of what has been ported to lavc anyway. (In reply to comment #10) > what about removing the quicktime dll from the win32codec package? Based on how many vid formats end up depending on these codecs. Your suggestion might be the best route to go. The following ebuilds have support for the quicktime USE= flag dev-libs/DirectFB-extra/DirectFB-extra-0.9.22.ebuild dev-libs/DirectFB-extra/DirectFB-extra-0.9.23.ebuild dev-libs/DirectFB-extra/DirectFB-extra-0.9.25.ebuild media-gfx/aoi/aoi-1.4.ebuild media-libs/mlt/mlt-0.2.2.ebuild media-libs/mlt/mlt-20051209.ebuild media-libs/win32codecs/win32codecs-20050216.ebuild media-libs/win32codecs/win32codecs-20060611-r1.ebuild media-libs/win32codecs/win32codecs-20060611.ebuild media-libs/win32codecs/win32codecs-20061022-r1.ebuild media-libs/win32codecs/win32codecs-20061022.ebuild media-tv/xawtv/xawtv-3.95-r1.ebuild media-video/dvgrab/dvgrab-1.8.ebuild media-video/dvgrab/dvgrab-2.0.ebuild media-video/dvgrab/dvgrab-2.1.ebuild media-video/kdenlive/kdenlive-0.3.0.ebuild media-video/kino/kino-0.7.6.ebuild media-video/kino/kino-0.8.1.ebuild media-video/kino/kino-0.9.2.ebuild media-video/kino/kino-0.9.5.ebuild media-video/mjpegtools/mjpegtools-1.8.0-r1.ebuild media-video/mjpegtools/mjpegtools-1.8.0-r2.ebuild net-www/mplayerplug-in/mplayerplug-in-3.31-r1.ebuild net-www/mplayerplug-in/mplayerplug-in-3.35.ebuild ok, we need to find a solution here. I think we should use.mask the quicktime useflag and remove the quicktime.dll. Does the quicktime useflag mean that every package depends on the .dll, or is it also used for other things? Please note that the quicktime useflag is not usually in reference to win32codecs's quicktime useflag, but rather quicktime4linux/libquicktime/whatever_you're_using_I_forgot_about . xine-lib's win32codecs support is quite similar to mplayer's so xine is vulnerable as long as mplayer is (see the DMO loader thing for xine-lib-1.1.4-r2 that is directly taken from MPlayer's SVN); we also don't use the demuxer, nor I think we use the rest of it, as xine does not really do anything that MPlayer doesn't. I can't speak for VLC, but I trust similitude apply to them. Still, I do think that win32codecs package is far from being security supportable. You don't have access to the code, you don't have an upstream to answer for it (as most of the codecs are simply cp'd from Windows installs). So my ex-dev suggestion about it is to either declare it security unsupported, or to mask it and mask the useflag, giving the user the ability to unmask it if he wants it, although I admit this is far from being a simple task, and for sure there will be people whining about it. Diego, thx for your comments. Declaring it unsupported security wise would be the same as masking the USE flag. This would probably lead to a lot of noise. Security what is your opinion? I have an alternative suggestion which most people probably won't agree with me, and should be discussed with media-video team before actually doing it. I would remove the win32codecs use flag completely, and rekeyword the binary package as unstable, with the clear notice that it is not cannot be supported since we can't be responsible or fix known or unknown vulnerabilites. The packages that depend on them can still enable support for them (at least, I know MPlayer can) without actually having them installed, and then leave it up to the user to decide whether or not to install them. Very bad idea: you end up enabling code that the user didn't request, and that might as well have its share of vulnerabilities (think of the DMO loader bug); plus for both xine and vlc it means one plugin always enabled that people might not want to use at all, which is also waste of memory resource. Security please comment. There's a new build in the tree that *might* resolve this - it's hard to tell. This is pretty much the same any other binary package - we are totally dependent on upstream for updated packages, and since the real upstream is two layers away, it's probably not going to be responsive. Security, any further comments? Just an elog and be done with it? i like what beandog said in comment #16 - we need to find a way to make it clear to users (unstable keywords, elog, mask?) that we are not responsible, since there is no way for us to support this binary stuff properly. we may also want to issue a GLSA or so once that is done? I think a GLSA would be required as I think quite a few of our users are using this one. Also I think the package should be masked with a clear security notice as per comment #14. video/security any comments? No other comments about masking win32codecs? more issues with quicktime http://docs.info.apple.com/article.html?artnum=305947 Another "More issues with quicktime": http://docs.info.apple.com/article.html?artnum=306896 (In reply to comment #14) > Still, I do think that win32codecs package is far from being security > supportable. That's what I've always thought, too. That would mean it should be masked or at least never go stable. Committed win32codecs-20071007-r2 without Quickime support until this is sorted out. I have no idea to what degree the mplayer guys care for security updates of these third party codecs or if it even matters to mplayer. The last time someone looked¹ at it, it seemed there're enough problems with mplayer itself. A future ebuild should probably drop the real codec dlls, given that we have the Real Player ebuild optionally installing its codecs only. [1] http://sam.zoy.org/zzuf/ x86 stable, what about amd64codecs? amd64codecs is only unix realplayer stuff (I still dislike the name for being too confusing). removing amd64 as we don't stable win32codecs, and amd64codecs is not affected (In reply to comment #22) > I think a GLSA would be required as I think quite a few of our users are using > this one. > > Also I think the package should be masked with a clear security notice as per > comment #14. > > video/security any comments? > Agreed, maskglsa request filed. (In reply to comment #29) > removing amd64 as we don't stable win32codecs Nice one. You do realize that this a breach of the ebuild policy, do!? It is not allowed to mark ebuilds stable without all of its dependencies being marked stable, in this case win32codecs being a dependency of mplayer, vlc,... > and amd64codecs is not affected if its really only providing the realplayer codecs, it should be removed entirely in favor of media-video/realplayer (In reply to comment #30) > (In reply to comment #22) > > I think a GLSA would be required as I think quite a few of our users are using > > this one. > > > > Also I think the package should be masked with a clear security notice as per > > comment #14. > > > > video/security any comments? > > > Agreed, maskglsa request filed. > Once again: Breach of ebuild policy and therefore not possible, unless all ebuilds depending on it are either masked or ebuild revisions are stable without the win32codec dependency. (In reply to comment #31) > (In reply to comment #29) > > removing amd64 as we don't stable win32codecs > > Nice one. You do realize that this a breach of the ebuild policy, do!? It is > not allowed to mark ebuilds stable without all of its dependencies being marked > stable, in this case win32codecs being a dependency of mplayer, vlc,... > Err, unless I'm missing something, win32codecs has currently no stable version for amd64, so I don't see any problem with this. Maybe there was a previous keywords problem though. Anyway, holding back glsa part until we sort things out. Carlo I suggest you to count about 10 and think twice before sending a comment, pretty please. AMD64 does not have anything depending on win32codecs because, surprisingly, you can't run windows 32-bit code from a 64-bit Linux process. The USE flag is masked for vlc, mplayer, xine, gstreamer for every architecture but x86 (and x86-fbsd). Also, realplayer does not provide 64-bit binaries in its ebuild last time I checked, because they are not released by Real itself. So the ebuild can't go away. And finally, you can mask win32codecs and then mask the USE flag (or rather remove the unmask) directly in profiles. No need to change the ebuilds and users who know the security risk can unmask the USE flag at their own risk together with the package. (In reply to comment #33) > Carlo I suggest you to count about 10 and think twice before sending a comment, > pretty please. Feel free to give good advices to yourself, Diego. I have no problem standing corrected, when I'm wrong. It's much better than seeing our userbase suffer in case. > AMD64 does not have anything depending on win32codecs because, surprisingly, > you can't run windows 32-bit code from a 64-bit Linux process. The USE flag is > masked for vlc, mplayer, xine, gstreamer for every architecture but x86 (and > x86-fbsd). Thought it would be used via emul stuff - why the heck was it keyworded ~amd64 at all then? > Also, realplayer does not provide 64-bit binaries in its ebuild last time I > checked, because they are not released by Real itself. So the ebuild can't go > away. Wasn't aware of it. Shame on RealNetworks. > And finally, you can mask win32codecs and then mask the USE flag (or rather > remove the unmask) directly in profiles. No need to change the ebuilds and > users who know the security risk can unmask the USE flag at their own risk > together with the package. Yes, that's a possibility. I'm in general not fond of "hiding" dependencies noted in ebuilds via profiles and would prefer removing support entirely, though. The userbase is exactly why I asked you to think twice before posting. You don't seem to know very much about the use of win32codecs, nor you seem to know very much about realplayer, and last I checked you weren't involved in media-video. Surely reporting security bugs and trying to get them fixed is good, but if you want to be part of the solution you'd have to at least understand why there is a problem in the first place. With respect to realcodecs, that's also OT and should not even be discussed it. With respect to win32codecs (and I do know how it works, where it's used, I used to maintain till last year two out of three its main users; hell I'm a xine-lib developer too, so I see also from an upstream pov), I can tell you at least this: - mplayer-bin has it enabled by default as the only reason why it exists _is_ to use win32codecs; I already disagreed about its presence in the past, because the use of win32codes is GPL-incompatible, although the code itself should be (so distribution of mplayer-bin alone, depending on win32codecs externally, is fine); It should then be masked together with win32codes if they were; - users still like to have win32codecs because a) WMV3 is not yet completely implemented in FFmpeg, although it's coming very near and b) because WMV is not the only encoding that needs them; Indeo comes as an example of an encoding that is not currently available through FFmpeg; I refer to FFmpeg because all the three main users of win32codecs are also users of FFmpeg as a decoding library (mplayer, xine and vlc); - removing an option to users because we consider it unsafe or security unsupported is good, if the option does not have real needs, but it's bad in this case because it's a feature so requested by users that AMD64 team had to prepare the mplayer-bin package! I can repeat ad infinitum it, but I prefer my health anyway, so I'll stop after this one: the proper solution is to declare win32codecs (and mplayer-bin) security unsupported; to do so, use package.mask to mask the win32codecs and mplayer-bin packages, and then remove the use.unmask of win32codecs in the x86 profiles. This way the default install _will_ provide users with security supported flags, and _will not_ disallow them from enabling it if they know about the security issue. Now I'm neither media-video (anymore) nor security, and I can only suggest a course of action, so I'd rather see what the video team prefer between the two options, rather than having to discuss again about this (I got asked _twice_ an opinion about this, by the way). (In reply to comment #35) > I can repeat ad infinitum it, but I prefer my health anyway, so I'll stop after > this one: the proper solution is to declare win32codecs (and mplayer-bin) > security unsupported; to do so, use package.mask to mask the win32codecs and > mplayer-bin packages, and then remove the use.unmask of win32codecs in the x86 > profiles. This way the default install _will_ provide users with security > supported flags, and _will not_ disallow them from enabling it if they know > about the security issue. I'm against that course of action, myself. Ideally, imo, no binary only releases should ever be marked stable, but as a matter of practicality it's a burdensome approach. @media-video, If no one objects, I'll remove the older versions from the tree (In reply to comment #37) > @media-video, > > If no one objects, I'll remove the older versions from the tree > what about the glsa part? should it be masked or not? We need to find an acceptable solution, this bug has been open for way too long :( (In reply to comment #38) > (In reply to comment #37) > > @media-video, > > > > If no one objects, I'll remove the older versions from the tree > > > > what about the glsa part? should it be masked or not? We need to find an > acceptable solution, this bug has been open for way too long :( > I dont think so, the new version doesnt even install the quicktime libs. (In reply to comment #37) > @media-video, > > If no one objects, I'll remove the older versions from the tree > gone CVE-2007-6166: Stack-based buffer overflow in Apple QuickTime 7.2 and 7.3 allows remote attackers to execute arbitrary code via a long Real Time Streaming Protocol (RTSP) Content-Type header. CVE-2007-4674: An "integer arithmetic" error in Apple QuickTime 7.2 allows remote attackers to execute arbitrary code via a crafted movie file containing a movie atom with a large size value, which triggers a stack-based buffer overflow. request was filed. GLSA 200803-08, sorry for the long delay. *** Bug 237364 has been marked as a duplicate of this bug. *** |