Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 150288 - media-libs/win32codecs <win32codecs-20071007-r2 - multiple vulnerabilities in included quicktime dll
Summary: media-libs/win32codecs <win32codecs-20071007-r2 - multiple vulnerabilities in...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B2 [glsa] jaervosz
Keywords:
: 237364 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-10-06 07:48 UTC by Carsten Lohrke (RETIRED)
Modified: 2008-09-10 20:14 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Carsten Lohrke (RETIRED) gentoo-dev 2006-10-06 07:48:31 UTC
CVE-2006-4382

Two buffer overflow vulnerabilities are present in QuickTime MOV format
support.

CVE-2006-4384

On heap overflow vulnerability is present in QuickTime FLC format
support.

CVE-2006-4385

One buffer overflow vulnerability is present in QuickTime SGI format
support.

CVE-2006-4386

One buffer overflow vulnerability is present in QuickTime MOV H.264
format support.

CVE-2006-4388

One buffer overflow vulnerability is present in QuickTime FlashPix (FPX)
format support.

CVE-2006-4389

One uninitialized memory access vulnerability is present in QuickTime
FlashPix (FPX) format support.


--


Fix would be to have binary stuff from Quicktime 7.1.3 included (needs someone to contact the mplayer guys or with a win box to evaluate, if this is the case already) or to drop it.
Comment 1 Matthias Geerdsen (RETIRED) gentoo-dev 2006-10-11 05:44:49 UTC
media-video, pls comment
Comment 2 Matthias Geerdsen (RETIRED) gentoo-dev 2006-11-06 03:22:54 UTC
media-video, are there updated packages available?

this bug is becoming old
Comment 3 Steve Dibb (RETIRED) gentoo-dev 2006-11-06 07:25:54 UTC
(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
Comment 4 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-11-20 23:41:54 UTC
Setting it to upstream for now.
Comment 5 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-12-11 08:30:08 UTC
Any news from upstream on this one?
Comment 6 Wendall Cada 2007-02-20 04:13:22 UTC
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
Comment 7 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-02-23 17:57:32 UTC
(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
Comment 8 Wendall Cada 2007-02-23 19:06:06 UTC
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
Comment 9 Wendall Cada 2007-02-23 19:48:23 UTC
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
Comment 10 Stefan Cornelius (RETIRED) gentoo-dev 2007-02-23 20:12:12 UTC
what about removing the quicktime dll from the win32codec package?
Comment 11 Steve Dibb (RETIRED) gentoo-dev 2007-02-23 20:27:26 UTC
(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.
Comment 12 solar (RETIRED) gentoo-dev 2007-02-23 20:45:11 UTC
(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
Comment 13 Stefan Cornelius (RETIRED) gentoo-dev 2007-02-26 14:15:09 UTC
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?
Comment 14 Diego Elio Pettenò (RETIRED) gentoo-dev 2007-03-23 17:01:35 UTC
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.
Comment 15 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-03-24 12:37:54 UTC
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?
Comment 16 Steve Dibb (RETIRED) gentoo-dev 2007-03-24 13:48:18 UTC
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.
Comment 17 Diego Elio Pettenò (RETIRED) gentoo-dev 2007-03-24 13:56:42 UTC
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.
Comment 18 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-03-30 20:46:03 UTC
Security please comment.
Comment 19 Matt Drew (RETIRED) gentoo-dev 2007-04-05 01:49:05 UTC
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.
Comment 20 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-06-03 15:33:14 UTC
Security, any further comments? Just an elog and be done with it?
Comment 21 Stefan Cornelius (RETIRED) gentoo-dev 2007-06-10 08:15:26 UTC
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?
Comment 22 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-06-10 10:50:47 UTC
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?
Comment 23 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-07-01 02:09:40 UTC
No other comments about masking win32codecs?
Comment 24 Carsten Lohrke (RETIRED) gentoo-dev 2007-07-14 01:06:11 UTC
more issues with quicktime

http://docs.info.apple.com/article.html?artnum=305947
Comment 25 Robert Buchholz (RETIRED) gentoo-dev 2007-11-07 13:43:22 UTC
Another "More issues with quicktime":
http://docs.info.apple.com/article.html?artnum=306896
Comment 26 Carsten Lohrke (RETIRED) gentoo-dev 2007-11-07 15:23:44 UTC
(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/
Comment 27 Christian Faulhammer (RETIRED) gentoo-dev 2007-11-08 07:58:25 UTC
x86 stable, what about amd64codecs?
Comment 28 Diego Elio Pettenò (RETIRED) gentoo-dev 2007-11-08 10:54:52 UTC
amd64codecs is only unix realplayer stuff (I still dislike the name for being too confusing).
Comment 29 Steve Dibb (RETIRED) gentoo-dev 2007-11-13 21:03:28 UTC
removing amd64 as we don't stable win32codecs, and amd64codecs is not affected
Comment 30 Pierre-Yves Rofes (RETIRED) gentoo-dev 2007-11-13 22:48:23 UTC
(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.

Comment 31 Carsten Lohrke (RETIRED) gentoo-dev 2007-11-13 23:13:27 UTC
(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.
Comment 32 Pierre-Yves Rofes (RETIRED) gentoo-dev 2007-11-13 23:26:38 UTC
(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.

Comment 33 Diego Elio Pettenò (RETIRED) gentoo-dev 2007-11-13 23:29:24 UTC
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.
Comment 34 Carsten Lohrke (RETIRED) gentoo-dev 2007-11-14 12:29:57 UTC
(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.
Comment 35 Diego Elio Pettenò (RETIRED) gentoo-dev 2007-11-14 13:13:03 UTC
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).
Comment 36 Steve Dibb (RETIRED) gentoo-dev 2007-11-14 14:37:02 UTC
(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.
Comment 37 Steve Dibb (RETIRED) gentoo-dev 2007-11-14 16:14:02 UTC
@media-video,

If no one objects, I'll remove the older versions from the tree
Comment 38 Pierre-Yves Rofes (RETIRED) gentoo-dev 2007-11-20 22:16:13 UTC
(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 :(
Comment 39 Steve Dibb (RETIRED) gentoo-dev 2007-11-21 00:16:20 UTC
(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.

Comment 40 Steve Dibb (RETIRED) gentoo-dev 2007-11-21 00:19:10 UTC
(In reply to comment #37)
> @media-video,
> 
> If no one objects, I'll remove the older versions from the tree
> 

gone
Comment 41 Robert Buchholz (RETIRED) gentoo-dev 2007-11-29 19:57:04 UTC
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.
Comment 42 Robert Buchholz (RETIRED) gentoo-dev 2007-11-29 19:59:54 UTC
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.
Comment 43 Robert Buchholz (RETIRED) gentoo-dev 2007-12-02 12:38:41 UTC
request was filed.
Comment 44 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-03-04 22:12:39 UTC
GLSA 200803-08, sorry for the long delay.
Comment 45 Jeroen Roovers (RETIRED) gentoo-dev 2008-09-10 20:14:25 UTC
*** Bug 237364 has been marked as a duplicate of this bug. ***