A new advisory for ffmpeg affects internal ffmpeg in blender. It is on Bug 4147. This Ubuntu advisory for other issues may be relevant as well: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/ffmpeg/maverick-security/revision/54
Blocks: (none) => 4146
Hi, thanks for reporting this bug. Assigned to the package maintainer. (Please set the status to 'assigned' if you are working on it)
Keywords: (none) => TriagedAssignee: bugsquad => dmorganec
Ping ?
CC: (none) => doktor5000
CC: (none) => shlomif
CC: (none) => fundawang
(In reply to comment #2) > Ping ? On #blender on Freenode, I was told that Blender-2.62: <<< Looks like SVN is using v0.10 from 1/31/2012 >>> So I think it should be OK, also given that blender-2.62 was released on 16-February, and it is in Cooker. Should we put the new Blender in Mageia 1 too? Regards, -- Shlomi Fish
Status: NEW => ASSIGNED
(In reply to comment #3) > (In reply to comment #2) > So I think it should be OK, also given that blender-2.62 was released on > 16-February, and it is in Cooker. Should we put the new Blender in Mageia 1 > too? IIRC we don't have python3 in mageia 1 so I don't know :s
blender was patched for an update in January, so we should be able to just patch it with the same patches that were applied to the other packages (ffmpeg, mplayer, etc, see Bug 4146).
Shlomi, is the blender package you built today ready for QA?
It's causing a hard lockup on my i586 system, which didn't happen when I was testing for bug 4001. I'm not sure how to get more info, as even the magic sysrq keys do not work. It requires pressing the reset button to reboot.
CC: (none) => davidwhodgins
(In reply to comment #7) > It's causing a hard lockup on my i586 system, which didn't happen > when I was testing for bug 4001. > > I'm not sure how to get more info, as even the magic sysrq keys > do not work. It requires pressing the reset button to reboot. Didn't you have the same problem on the previous update (Bug 3983)?
Ah yes, sorry. Mixed up the mplayer report with the blender report. I knew I'd had it on some package in the past, but couldn't remember which one, hence I looked back, but looked at the wrong package. Sorry for the mistake. No regression, but again, I won't be able to help with qa testing for this one.
Reassigning the bug to qa-bugs so they can publish an update. The SRPM is now in updates_testing: http://mirrors.kernel.org/mageia/distrib/1/SRPMS/core/updates_testing/blender-2.49b-11.1.mga1.src.rpm Sorry for bumping the release instead of the subrel - that was an overlook on my part, but Mageia 2 ships Blender 2.6x anyhow. Regards, -- Shlomi Fish
Assignee: dmorganec => qa-bugs
Can you give an advisory Shlomi please.
On IRC, Shlomi said the bundled ffmpeg was upgraded to 0.5.8. Looking at the upstream changlogs, it looks like the following CVEs would be addressed: - CVE-2011-3362 - CVE-2011-3973 - CVE-2011-3974 - CVE-2011-3504 - CVE-2011-4352 - CVE-2011-4579 - CVE-2011-4353 - CVE-2011-4351 - CVE-2011-4364 - CVE-2011-3892 - CVE-2011-3893 - CVE-2011-3895 Does this sound right Shlomi? We have descriptions for all but the first three of those in the advisory on Bug 4154.
- CVE-2011-3362 Integer signedness error in the decode_residual_block function in cavsdec.c in libavcodec in FFmpeg before 0.7.3 and 0.8.x before 0.8.2, and libav through 0.7.1, allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via a crafted Chinese AVS video (aka CAVS) file. - CVE-2011-3973 cavsdec.c in libavcodec in FFmpeg before 0.7.4 and 0.8.x before 0.8.3 allows remote attackers to cause a denial of service (incorrect write operation and application crash) via an invalid bitstream in a Chinese AVS video (aka CAVS) file, related to the decode_residual_block, check_for_slice, and cavs_decode_frame functions, a different vulnerability than CVE-2011-3362 - CVE-2011-3974 Integer signedness error in the decode_residual_inter function in cavsdec.c in libavcodec in FFmpeg before 0.7.4 and 0.8.x before 0.8.3 allows remote attackers to cause a denial of service (incorrect write operation and application crash) via an invalid bitstream in a Chinese AVS video (aka CAVS) file, a different vulnerability than CVE-2011-3362.
(In reply to comment #12) > On IRC, Shlomi said the bundled ffmpeg was upgraded to 0.5.8. 0.5.X, really? That would be pretty old, it should be at least equal to ffmpeg in Mageia 1, so 0.6.5, or it would be susceptible to all those security flaws that got fixed by last round of ffmpeg updates.
(In reply to comment #14) > (In reply to comment #12) > > On IRC, Shlomi said the bundled ffmpeg was upgraded to 0.5.8. > > 0.5.X, really? That would be pretty old, it should be at least equal to ffmpeg > in Mageia 1, so 0.6.5, or it would be susceptible to all those security flaws > that got fixed by last round of ffmpeg updates. He said he found out that the bundled ffmpeg that was already with blender was 0.5.x. 0.5.8 fixes all of those security bugs, just like 0.6.5 did. Who knows if the old version of blender even works with ffmpeg 0.6.
(In reply to comment #6) > Shlomi, is the blender package you built today ready for QA? Yes, it is. I did some rudimentary testing of it on my i586 Mageia 1 VM (my x86-64 Mageia 1 VM does not work very well - possibly due to lack of RAM), and it appears to work fine. Regards, -- Shlomi Fish
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #12) > > > On IRC, Shlomi said the bundled ffmpeg was upgraded to 0.5.8. > > > > 0.5.X, really? That would be pretty old, it should be at least equal to ffmpeg > > in Mageia 1, so 0.6.5, or it would be susceptible to all those security flaws > > that got fixed by last round of ffmpeg updates. > > He said he found out that the bundled ffmpeg that was already with blender was > 0.5.x. 0.5.8 fixes all of those security bugs, just like 0.6.5 did. Who knows > if the old version of blender even works with ffmpeg 0.6. The old version of blender does not work with ffmpeg 0.6.x because I tried building it with this version of ffmpeg replacing the existing version and it failed. It worked fine after updating only to 0.5.8, because that version of Blender shipped with 0.5.x. Regards, -- Shlomi Fish
(In reply to comment #12) > On IRC, Shlomi said the bundled ffmpeg was upgraded to 0.5.8. Looking at the > upstream changlogs, it looks like the following CVEs would be addressed: > - CVE-2011-3362 > - CVE-2011-3973 > - CVE-2011-3974 > - CVE-2011-3504 > - CVE-2011-4352 > - CVE-2011-4579 > - CVE-2011-4353 > - CVE-2011-4351 > - CVE-2011-4364 > - CVE-2011-3892 > - CVE-2011-3893 > - CVE-2011-3895 > > Does this sound right Shlomi? Yes, it sounds right. > > We have descriptions for all but the first three of those in the advisory on > Bug 4154.
For the first one, here is mine from avidemux: - CVE-2011-3362 (arbitrary code execution via malformed CAVS file) http://www.ocert.org/advisories/ocert-2011-002.html For the other two: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3973 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3974
Testing x86_64 using the Video Sequence Editor and the tutorial below http://www.youtube.com/watch?v=caIg7sIX6d4 Set output to mp4 with mp3 audio, with an xvid avi, a jpg image and an mp3 audio file added. Rendering seems Ok.. Starting output to /home/claire/test/blendtest0001_0500.mp4(ffmpeg)... Using type=2, codec=2, audio_codec=86017, video_bitrate=6000, audio_bitrate=128, gop_size=15, multiplex=0, autosplit=0 render width=720, render height=576 Using global header Writing frame 1, render width=720, render height=576 Video Frame PTS: 0 Append frame 1 Time: 00:00.04 Writing frame 2, render width=720, render height=576 Video Frame PTS: 1 Append frame 2 Time: 00:00.02 Writing frame 3, render width=720, render height=576 .... Writing frame 500, render width=720, render height=576 Video Frame PTS: 499 Append frame 500 Time: 00:00.02 Closing ffmpeg... Blender quit When I playback the file it created, there is no audio. $ mplayer blendtest0001_0500.mp4 MPlayer SVN-1.rc4.0.r32713.5.3.mga1.tainted-4.5.2 (C) 2000-2010 MPlayer Team Playing blendtest0001_0500.mp4. libavformat file format detected. [lavf] stream 0: video (mpeg4), -vid 0 VIDEO: [MP4V] 720x576 24bpp 25.000 fps 1939.6 kbps (236.8 kbyte/s) Clip info: major_brand: isom minor_version: 512 compatible_brands: isomiso2mp41 creation_time: 1970-01-01 00:00:00 encoder: Lavf52.31.0 ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4) ========================================================================== Audio: no sound Starting playback... Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [xv] 720x576 => 1024x576 Planar YV12 [zoom] V: 10.1 0/ 0 15% 1% 0.0% 0 0 I think the ffmpeg being used is incapable of mp3. If that is the case then there should probably be a tainted version of blender for Mageia 1. I'll check with non-mp3 format input files.
It seems to accept wav and mp3 input files but output formats are very limited in both audio and video. I have only managed to save files with AC3 or MP2 audio, other formats cause it either to lock or crash. It doesn't fail gracefully. Video is limited in a similar fashion. I think this is because support for these are not built into ffmpeg. I have noticed it say support is not built into ffmpeg for certain input file types but when an unsupported output format is selected it either crashes or just locks up. IMO we need a tainted version of blender also, with the tainted ffmpeg built in. Thankfully recent versions of blender make use of the system ffmpeg libraries so mga 2 will be unaffected if tainted ffmpeg is installed
Please note that in comment 20 I had forgotten to click the Multiplex Audio button :\ Comment 21 is valid.
Testing with the same procedure that Claire used, with the i586 package. I got it to work, using an mpegv1 video and png image as input, output to an AVI with mp2 audio. I can confirm that it just freezes basically with another audio output format. I tried choosing Vorbis as the output format, and just get what looks like an infinite loop (maybe I just didn't wait long enough, but the render window freezes) of "Audio Frame PTS: 0" being printed to the console. Strange. So I guess it basically works, sometimes :o)
(In reply to comment #23) > Testing with the same procedure that Claire used, with the i586 package. > > I got it to work, using an mpegv1 video and png image as input, output to an > AVI with mp2 audio. > > I can confirm that it just freezes basically with another audio output format. > I tried choosing Vorbis as the output format, and just get what looks like an > infinite loop (maybe I just didn't wait long enough, but the render window > freezes) of "Audio Frame PTS: 0" being printed to the console. Strange. > > So I guess it basically works, sometimes :o) Hi, can you check if these problems with the Audio output happen with the previous version of the Blender package, before the change - the one in the "updates" section - blender-2.49b-10.1.mga1.i586.rpm . Regards, -- Shlomi Fish
(In reply to comment #24) > Hi, > > can you check if these problems with the Audio output happen with the previous > version of the Blender package, before the change - the one in the "updates" > section - blender-2.49b-10.1.mga1.i586.rpm . > > Regards, > > -- Shlomi Fish Yes, it does the same thing, so this is not a regression. I believe this can be validated.
I believe this needs a tainted version as I said in comment 21..
I think we should ship a version with the security updates in ffmpeg, and not wait for a tainted variant to be ready. Regards, -- Shlomi Fish
I'm not sue why there is a reluctance to provide a tainted version and why it should create any delay. I mentioned the need some 11 days ago. It is not very good to release this in this state. There is little point us performing QA when problems we find are ignored simply because it was just as bad in the last release, especially when all that is needed is a tainted build. As this seems to be going nowhere though I'll validate. We don't even have a complete advisory. Bug 5033 created and assigned to Shlomi for a tainted version. Advisory (As best I can make out) -------------- This update addresses numerous security issues with the ffmpeg used by blender. - CVE-2011-3362 Integer signedness error in the decode_residual_block function in cavsdec.c in libavcodec in FFmpeg before 0.7.3 and 0.8.x before 0.8.2, and libav through 0.7.1, allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via a crafted Chinese AVS video (aka CAVS) file. - CVE-2011-3973 cavsdec.c in libavcodec in FFmpeg before 0.7.4 and 0.8.x before 0.8.3 allows remote attackers to cause a denial of service (incorrect write operation and application crash) via an invalid bitstream in a Chinese AVS video (aka CAVS) file, related to the decode_residual_block, check_for_slice, and cavs_decode_frame functions, a different vulnerability than CVE-2011-3362 - CVE-2011-3974 Integer signedness error in the decode_residual_inter function in cavsdec.c in libavcodec in FFmpeg before 0.7.4 and 0.8.x before 0.8.3 allows remote attackers to cause a denial of service (incorrect write operation and application crash) via an invalid bitstream in a Chinese AVS video (aka CAVS) file, a different vulnerability than CVE-2011-3362. - CVE-2011-3504 - CVE-2011-4352 - CVE-2011-4579 - CVE-2011-4353 - CVE-2011-4351 - CVE-2011-4364 - CVE-2011-3892 - CVE-2011-3893 - CVE-2011-3895 A tainted version of blender will be provided with added ffmpeg functionality See https://bugs.mageia.org/show_bug.cgi?id=5033 ----------------------- SRPM: blender-2.49b-11.1.mga1.src.rpm Could sysadmin please push from core/updates_testing to core/updates Thankyou!
Keywords: Triaged => validated_updateCC: (none) => sysadmin-bugsHardware: i586 => All
As noted in Comment 12, we have descriptions for the other CVEs in Bug 4154. Here's a more complete advisory: Advisory -------------- This update addresses numerous security issues with the ffmpeg used by blender. - CVE-2011-3504: denial of service and possible code execution via malformed Matroska file - CVE-2011-4351: denial of service and possible code execution via malformed file containing QDM2 stream - CVE-2011-4352: denial of service and possible code execution via malformed file containing VP3 stream - CVE-2011-4353: denial of service and possible code execution via malformed file containing VP5 or VP6 streams - CVE-2011-4364: denial of service and possible code execution via malformed VMD file - CVE-2011-4579: denial of service and possible code execution via malformed file containing svq1 stream - CVE-2011-3892: denial of service via malformed stream for the VP3 decoder - CVE-2011-3893, CVE-2011-3895: denial of service and possible code execution via malformed stream for the vorbis decoder and matroska demuxer - CVE-2011-3362: Integer signedness error in the decode_residual_block function in cavsdec.c in libavcodec allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via a crafted Chinese AVS video (aka CAVS) file. - CVE-2011-3973: cavsdec.c in libavcodec allows remote attackers to cause a denial of service (incorrect write operation and application crash) via an invalid bitstream in a Chinese AVS video (aka CAVS) file, related to the decode_residual_block, check_for_slice, and cavs_decode_frame functions. - CVE-2011-3974: Integer signedness error in the decode_residual_inter function in cavsdec.c in libavcodec allows remote attackers to cause a denial of service (incorrect write operation and application crash) via an invalid bitstream in a Chinese AVS video (aka CAVS) file. References: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/ffmpeg/maverick-security/revision/54 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3892 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3893 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3895 http://www.ocert.org/advisories/ocert-2011-002.html http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3973 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3974 ----------------------- SRPM: blender-2.49b-11.1.mga1.src.rpm
(In reply to comment #28) > I'm not sue why there is a reluctance to provide a tainted version and why it > should create any delay. I mentioned the need some 11 days ago. > > It is not very good to release this in this state. There is little point us > performing QA when problems we find are ignored simply because it was just as > bad in the last release, especially when all that is needed is a tainted build. First I want to say, as I have said before, that the thoroughness of the testing that you do for QA is very impressive and much appreciated. It is very helpful that you are able to find some of the issues that you do, so that they can either be fixed, or noted in advisories when this is not possible. I think Shlomi's contention with this update is that it fixes security issues and doesn't cause any regressions, so getting the update out, even in this state, is a lot better than not doing it, or waiting for a tainted version to be developed. At least this way we can get some security fixes out to vulnerable users. Of course, sometimes it's better to fix the issues first so that you don't have to issue two updates, so I know that's one possible objection here. The problem in this case, however, is that this is not just a simple as submitting a build to the tainted section. Adding a tainted build requires further research and development to find the right configure options for this version of ffmpeg (which doesn't match the system version) and make the additions to the SPEC to properly support a tainted build with the needed capabilities added. It will take time to get this work done.
Thankyou David for the advisory, although I'm sure Shlomi can speak for himself if he desires. I fully understand the issue with security updates being important. Blender is already a long way behind others with ffmpeg in this regard. In this case though it had already waited for 11 days in QA for a tainted build after it was requested. As the additional options for ffmpeg should be well known from the likes of avidemux and other applications with statically linked ffmpeg there is little real reason for such a delay or presumption it would necessarily cause any delay. The idea that 'it is not a regression' is a good enough reason to release broken updates in these circumstances is IMO not a good one.
Update pushed
Status: ASSIGNED => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED