Bugzilla Bug 150288

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.

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. ***