CVEs have been assigned for several security issues fixed in gstreamer 1.10.3:
Five of those affect plugins-good. Mageia 5 may be affected.
Assigning to all packagers collectively, since there is no registered maintainer for this package.
gstreamer0.10-plugins-good also affected:
openSUSE has issued an advisory for this on April 19:
pushed in updates_testing
Updated gstreamer0.10-plugins-good and gstreamer1.0-plugins-good packages fix
A crafted AAC audio file could have caused an invalid read and thus corruption
or denial of service (CVE-2016-10198).
A crafted mp4 file could have caused an invalid read and thus corruption or
denial of service (CVE-2016-10199).
A crafted AVI file could have caused an invalid read and thus corruption or
denial of service (CVE-2017-5840).
A crafted AVI file with metadata tag entries (ncdt) could have caused invalid
read access and thus corruption or denial of service (CVE-2017-5841).
A crafted AVI file could have caused an invalid read access resulting in denial
of service (CVE-2017-5845).
Note that GStreamer 0.10 was only affected by CVE-2016-10198 and CVE-2017-5840.
Updated packages in core/updates_testing:
MGA5-32 on Asus A6000VM
No installation issues.
Tried to figure out how to test these.
Played .wav file with mplayer, parole and vlc, but only parole shows calls to gstreamer in the trace.
From Comment 5, it looks as if the least we can do is try these things with .aac .mp4 .avi files. Surprised that .mp4 does not require tainted/bad plugins.
$ urpmq --whatrequires gstreamer0.10-plugins-good | sort | uniq
$ urpmq --whatrequires gstreamer1.0-plugins-good | sort | uniq
If nobody else has a strong interest I shall test these on mga5:x86_64.
There are poc files available which need to be run but given our past experience with such things they may not prove to be very useful.
0.10: gnac can be used for audio conversions
1.0: parole, totem.
Looks like the PoCs could be useful. A preliminary look shows one of them segfaulting before the update and being handled cleanly afterwards.
To be continued....
There are a few plugins from tainted but they don't belong to this update.
Tried running inside valgrind but did not find that particularly useful.
Ran the files with totem to pinpoint the 1.0 plugins - the full set of 0.1 plugins not yet installed. All tests are before updating.
"This file contains no playable streams"
A program requires an additional plugin to decode this file
= audio/x-gst-fourcc-000 decoder
Do you want to search for this now? -> Cancel
In the terminal:
** Message: PackageKit: structure: gstreamer1(decoder-audio/x-gst-fourcc-0000)()(64bit)
<This may be covered in tainted - something to do with the aac codec ??>
Played 5 second clip which restarted automatically, played and stopped.
A bit of a puzzle here. The gstreamer0.10-plugins-good and others listed in comment 5 seem to be in core updates already, not in updates testing, so it is difficult to look at anything before the updates.
$ rpm -qa | grep gstreamer0.10
# urpmi gstreamer0.10-plugins-good
To satisfy dependencies, the following packages are going to be installed:
Package Version Release Arch
(medium "Core Updates (distrib3)")
gstreamer0.10-plugins-good 0.10.31 9.1.mga5 x86_64
gstreamer0.10-soup 0.10.31 9.1.mga5 x86_64 (recommended)
4.8MB of additional disk space will be used.
1.3MB of packages will be retrieved.
Proceed with the installation of the 2 packages? (Y/n) n
I agree with Len Comment 11. Looking at the RPMs link, all the 'gstreamer0.10' pkgs are already in Updates, issued.
Setting feedback for this point.
The 'gstreamer1.0' pkgs are indeed updates from the current issue '-1.4.3-2.1.mga5'.
To complicate things further, I have packages installed from both groups which are not in these packages lists, at different or advanced versions - presumably from other SRPMs; and several listed packages missing from my system! Without ever having meddled in this area, beyond enabling 'tainted' where a few such packages exist in both lists for my installed system.
A veritable worm's nest.
The subrel was defined in the wrong place in the SPEC by the previous update (by Shlomi) for gstreamer0.10-plugins-good so Nicolas missed it and redefined in the correct place as 1 again. I've fixed that and rebuilt it.
Now the SRPMS are:
Beyond that, I can't follow what Lewis is talking about.
> Beyond that, I can't follow what Lewis is talking about.
Not sure now myself! I think confusion about other gstreamer0.10 packages with different version numbers, from different SRPMs.
But we are still at the undisputable point where all alleged updated gstreamer0.10 packages listed in comment 5 as version -0.10.31-9.1.mga5 are *already* issued at this version. Having installed normally the packages I did not already have, my list is:
i.e. the same as in this update. So something is wrong.
We are only questioning that these packages seem to have not been updated, hence should not be in this update at all. Indeed, the RPMs bug link shows for these pkgs 'core-updates' (issued), while the gstreamer1.0 lot are indeed in 'core-updates_testing' (to test).
It makes quite a difference to what we should test, and touches the Advisory.
No, the subrel has been increased on the 0.10 one. Looks like I typoed that in my last comment.
Now the SRPMS are:
As for the other gstreamer packages from other SRPMS, those are in other bugs and aren't relevant to this one.
(In reply to David Walser from comment #15)
> Now the SRPMS are:
And at last the 'gstreamer0.10' things are indeed at -0.10.31-9.2.mga5 and in 'core-updates_testing' for the first time. So the updated packages list now looks like:
We can resume testing. Reminder: "it looks as if the least we can do is try these things with .aac .mp4 .avi files" (none of which I have); application lists comment 7.
@Len : since you researched the PoCs used in comment 10, can you give their URLs?
URLs for the PoC images referred to in comment 8
CVE-2016-10198 : https://bugzilla.gnome.org/show_bug.cgi?id=775450
CVE-2016-10199 : https://bugzilla.gnome.org/show_bug.cgi?id=775451
CVE-2017-5840 : https://bugzilla.gnome.org/show_bug.cgi?id=777469
CVE-2017-5841 : https://samples.mplayerhq.hu/ffmpeg-bugs/trac/ticket3279/DSC_0131.AVI
CVE-2017-5845 : https://samples.mplayerhq.hu/ffmpeg-bugs/trac/ticket3330/DSC_0902.AVI
These files are intended to be tested within an ASAN framework so may not provide any extra information after an update if simply opened, using identify for instance. Sometimes the only difference that can be seen is the absence of segfaults or aborts which in itself indicates that the particular patch has addressed the vulnerability.
Sidebar: What is ASAN?
ASAN = Address Sanitization which is an option for the GCC and Clang compilers (and maybe others) which overrides malloc to provide checks for buffer overflows and use-after-free issues. One reason it is not used by default is the extra time and memory required for the checks and its use within QA is not recommended because it involves local builds, which could go wrong and which would tend to overload testers.
Back on this, starting from version 1.4.3-2.1 for the 1.0 plugins.
Testing on mga5 for x86_64
Before the update gstreamer1.0-plugins-good were at version 1.4.3-2.1.
$ valgrind totem gst_aac_parse_sink_setcaps.aac
(gst-plugin-scanner:28281): GStreamer-CRITICAL **: gst_structure_new_empty: assertion 'gst_structure_validate_name (name)' failed
==28271== Invalid write of size 8
<finishing with HEAP, LEAK and ERROR summaries>
$ valgrind totem qtdemux.mp4
totem window appeared with the message "This file contains no playable streams".
Copious output from valgrind.
$ valgrind totem oob-qtdemux_parse_samples.mp4
The totem window came up noting that an additional plugin was required, presumably for a tainted codec (audio/x-gst-fourcc-0000 decoder)
task-codec-audio-4-4.mga5.tainted.noarch was already installed.
$ valgrind totem DSC_0131.AVI
totem played the clip fine but valgrind reported 284 errors.
$ valgrind totem DSC_0902.AVI
==27186== Invalid write of size 8
totem segfaulted immediately.
Not a lot to go on here.
Ran the update.
$ totem gst_aac_parse_sink_setcaps.aac
This file is corrupt and cannot be played.
$ totem qtdemux.mp4
This file contains no playable streams.
$ totem qtdemux.mp4
** Message: Missing plugin: gstreamer|1.0|totem|audio/x-gst-fourcc-0000 decoder
$ totem DSC_0131.AVI
As before this played fine.
$ totem DSC_0902.AVI0
This also played OK.
Again, not much to go on, although the last test showed no sign of having encountered the error which made totem crash before. When run with valgrind it reported memory leaks and counted 115 errors. There is no way of knowing if valgrind is detecting errors unrelated to the current bug.
General conclusion: the PoCs are not of much help to QA.
Utility tests coming up.
To check gstreamer-plugins for various audio formats totem seems as good as any.
Tried it out on various music files, some with video, using bluetooth audio and keeping an eye on pavucontrol.
$ totem TheLassOfFyvie.mp3
$ totem TheCreaturesOfPrometheus_overture.flac
$ totem ToccataEfuga_BWV565_KarlRichter.mp4
$ totem CherryOhBaby.ogg
$ totem Chiomiscordidite.aac
$ totem sunday.xm
$ totem marseillaise.aiff
$ totem HarpConcerto_inBflatmajor.wav
$ totem CharlotteChurch_MenOfHarlech.flv
No problems with any of these. Note that the earlier PoC tests with valgrind contained references to the gstreamer-plugins. Running the following and checking the trace file with grep turned up multiple references to gstreamer1.0 along with instances of libgstflac.so, libgst1394.so, libgstsouphttpsrc.so, libgstjack.so, libgstspeex.so, libgstwavpack.so and so on.
$ strace totem RedRedWine.ogg 2> trace
Which demonstrates that totem is heavily involved with gstreamer1.0 plugins.
Giving this the 64-bit OK.
Advisory from comments 5 & 15.
Thanks Len for doing this thorny one. Validating.
An update for this issue has been pushed to the Mageia Updates repository.