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:
Steps to Reproduce:
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.
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:
The security fixes are only in libebml, so I'll close the other bug.
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.
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
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.
Updated packages uploaded for Mageia 5. Advisory in Comment 5.
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.
There are some sample Matroska video files here:
Working fine Mageia 5 i586.
mga5 - x86_64 - Mate
and pulled these in from the command line:
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.
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.
has_procedure MGA5-32-OK =>
has_procedure MGA5-32-OK MGA5-64-OK
has_procedure MGA5-32-OK MGA5-64-OK =>
has_procedure MGA5-32-OK MGA5-64-OK advisoryCC:
An update for this issue has been pushed to Mageia Updates repository.
Looks like these got CVE-2015-8790 and CVE-2015-8791:
Apparently the commit in libmatroska that GÃ¶tz linked in Bug 17005 got CVE-2015-8792:
CVE-2015-8789 was also fixed in this update:
It was referenced in this Debian advisory:
(In reply to David Walser from comment #14)
> CVE-2015-8789 was also fixed in this update:
> It was referenced in this Debian advisory:
According to the TALOS pages themselves:
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.