Cisco found a security bug in libebml labeled TALOS-CAN-0036, but not yet available to the public at http://talosintel.com/vulnerability-reports/ The fix is in libebml 1.3.3 and in git: https://github.com/Matroska-Org/libebml/commit/88409e2a94dd3b40ff81d08bf6d92f486d036b24 Reproducible: Steps to Reproduce:
Blocks: (none) => 17005
Thanks for the report. Update is checked into SVN. Hopefully we won't have to wait until 60 days after 10-08-2015 for details. I'd be interested to know how you found this info and if you know when we can expect any more details.
Summary: security issue in libebml => libebml new security issue TALOS-CAN-0036
It was referenced in the libebml 1.3.3 announcement. It is public.
Thanks. If you could provide a link to such announcements in the future, it would help. The release announcements are here: http://lists.matroska.org/pipermail/matroska-users/2015-October/006981.html http://lists.matroska.org/pipermail/matroska-users/2015-October/006985.html The security fixes are only in libebml, so I'll close the other bug.
Blocks: 17005 => (none)Summary: libebml new security issue TALOS-CAN-0036 => libebml new security issues TALOS-CAN-0036 and TALOS-CAN-0037
*** Bug 17005 has been marked as a duplicate of this bug. ***
Saving the advisory for later as the build system is not usable. Advisory: ======================== Updated libebml packages fix security vulnerabilities: In EbmlMaster::Read() in libebml before 1.3.3, when the parser encountered a deeply nested element with an infinite size then a following element of an upper level was not propagated correctly. Instead the element with the infinite size was added into the EBML element tree a second time resulting in memory access after freeing it and multiple attempts to free the same memory address during destruction (TALOS-CAN-0037). In EbmlUnicodeString::UpdateFromUTF8() in libebml before 1.3.3, when reading from a UTF-8 string in which the length indicated by a UTF-8 character's first byte exceeds the string's actual number of bytes the parser would access beyond the end of the string resulting in a heap information leak (TALOS-CAN-0036). The libebml package has been updated to version 1.3.3, which fixes these issues and other bugs, including another invalid memory access issue. The libmatroska package has also been rebuilt against the updated libebml and updated to version 1.4.4, which also fixes an invalid memory access issue and other bugs. See the release announcements for details. References: http://talosintel.com/vulnerability-reports/ http://lists.matroska.org/pipermail/matroska-users/2015-October/006981.html http://lists.matroska.org/pipermail/matroska-users/2015-October/006985.html
Updated packages uploaded for Mageia 5. Advisory in Comment 5. libebml4-1.3.3-1.mga5 libebml-devel-1.3.3-1.mga5 libmatroska6-1.4.4-1.mga5 libmatroska-devel-1.4.4-1.mga5 from SRPMS: libebml-1.3.3-1.mga5.src.rpm libmatroska-1.4.4-1.mga5.src.rpm
CC: (none) => luigiwalserAssignee: bugsquad => qa-bugs
The primary consumers of these libraries are mkvtoolnix and vlc. You can use mkvtoolnix for doing whatever it is that it does for testing this, or use VLC to play a Matroska video (.mkv) file.
Whiteboard: (none) => has_procedure
There are some sample Matroska video files here: http://download.wavetlan.com/SVV/Media/HTTP/http-mkv.htm Working fine Mageia 5 i586.
Whiteboard: has_procedure => has_procedure MGA5-32-OK
mga5 - x86_64 - Mate Upgraded from: lib64ebml4-1.3.0-5 lib64matroska6-1.4.1-5 to: lib64ebml4-1.3.3-1 lib64matroska6-1.4.4-1 and pulled these in from the command line: lib64ebml-devel-1.3.3-1 lib64matroska-devel-1.4.4-1 Downloaded six mkv files from the Matroska test suite and played them with vlc. All played fine, with sound and subtitles where given, and a noticeable sound gap in test8.mkv. mkvtoolnix installed OK but had no idea how to run it. It turns out that it is a set of tools: mkvmerge, mkvinfo, mkvextract, mkvpropedit and a separate mkvtoolnix-gui which I could not find, possibly in another RPM. $ mkvinfo test2.mkv returned a lot of information about the attributes and structure of the file.
CC: (none) => tarazed25
The audio gap in test8.mkv is reported on the Matroska website and detected by mkvinfo: | + Simple | + Name: COMMENT | + String: Matroska Validation File 8, audio missing between timecodes 6.019s and 6.360s Anyway, the update works for 64-bit.
Whiteboard: has_procedure MGA5-32-OK => has_procedure MGA5-32-OK MGA5-64-OK
Keywords: (none) => validated_updateWhiteboard: has_procedure MGA5-32-OK MGA5-64-OK => has_procedure MGA5-32-OK MGA5-64-OK advisoryCC: (none) => davidwhodgins, sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2015-0430.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
URL: (none) => http://lwn.net/Vulnerabilities/663514/
Looks like these got CVE-2015-8790 and CVE-2015-8791: http://lwn.net/Vulnerabilities/677964/
Apparently the commit in libmatroska that Götz linked in Bug 17005 got CVE-2015-8792: http://lwn.net/Vulnerabilities/681098/
CVE-2015-8789 was also fixed in this update: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8789 It was referenced in this Debian advisory: https://lists.debian.org/debian-security-announce/2016/msg00112.html https://www.debian.org/security/2016/dsa-3538
(In reply to David Walser from comment #14) > CVE-2015-8789 was also fixed in this update: > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8789 > > It was referenced in this Debian advisory: > https://lists.debian.org/debian-security-announce/2016/msg00112.html > https://www.debian.org/security/2016/dsa-3538 LWN reference: http://lwn.net/Vulnerabilities/681990/
According to the TALOS pages themselves: http://www.talosintel.com/reports/TALOS-2016-0036/ http://www.talosintel.com/reports/TALOS-2016-0037/ these are CVE-2016-1514 and CVE-2016-1515 (which doesn't make sense since they should be 2015 CVEs). So, it looks like someone wrongly assigned some duplicate CVEs. LWN reference: http://lwn.net/Vulnerabilities/692380/