libEBML v1.3.3, libMatroska v1.4.4 released: important fixes
Moritz Bunkus <[email protected]> Tue, 20 Oct 2015 15:20:52 +0200
| Newsgroups | gmane.comp.multimedia.matroska.user,gmane.comp.multimedia.matroska.devel |
|---|---|
| Message-ID | <[email protected]> |
Hey, I've released new versions of libEBML (v1.3.3) and libMatroska (v1.4.4). Download links for the impatient: http://dl.matroska.org/downloads/libebml/libebml-1.3.3.tar.bz2 http://dl.matroska.org/downloads/libmatroska/libmatroska-1.4.4.tar.bz2 Both are binary-compatible to their respective previous releases and did not have their .so version bumped. Both release contain several fixes for possible invalid memory access with specially crafted or damaged files. Among them are two issues reported by Cisco's Talos Security Intelligence and Research Group (TALOS-CAN-0036 and TALOS-CAN-0037) on 2015-10-20. As both libraries are often used for parsing files from arbitrary sources I highly recommend all users to upgrade. The next release of MKVToolNix will require these two versions at least. Here's libEBML's ChangeLog since the previous release (v1.3.2): ---------------------------------------------------------------------- 2015-10-20 Moritz Bunkus <[email protected]> * Released v1.3.3. * EbmlMaster::Read(): 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. Fixes the issue reported as Cisco TALOS-CAN-0037. * EbmlElement::ReadCodedSizeValue(): Fixed an invalid memory access. When reading a EBML variable length integer value a read access beyond the end of the available buffer was possible if fewer bytes were available than indicated by the first byte resulting in a heap information leak. * EbmlUnicodeString::UpdateFromUTF8(): Fixed an invalid memory access. 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. Fixes the issue reported as Cisco TALOS-CAN-0036. ---------------------------------------------------------------------- Here's libMatroska's ChangeLog since the previous release (v1.4.3): ---------------------------------------------------------------------- 2015-10-20 Moritz Bunkus <[email protected]> * Released v1.4.4. * KaxInternalBlock::ReadData(): Fixed an invalid memory access. When reading a block group or a simple block that uses EBML lacing the frame sizes indicated in the lacing weren't checked against the available number of bytes. If the indicated frame size was bigger than the whole block's size the parser would read beyond the end of the buffer resulting in a heap information leak. ---------------------------------------------------------------------- Have fun. Kind regards, mosu _______________________________________________ Matroska-users mailing list [email protected] http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-users Read Matroska-Users on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.user
signature.asc
(application/pgp-signature, 819 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWJj+zAAoJEHSvAK3y4yyFGQAP/ApIFrWKU4unwU0U1kQ5MzLF 11GB1DFiCuNJyJ2xiIYh1skzwyE5AeOfQtGe5T2OvoGSQh73Iec54pZ88/NJJDs5 nFc4oAfmTlv1A+Vu1p+fEdQJW7YI86jyO1GDOe5mlQmk9+B1ELZ3rN0nLOnHfzVm l+tcZQkGri3qRQmVnAj1z/SOhb+ZAzZIN2PIfb9FJCEzggBcLQfKhh+aOgjTj5+G Jmvy817YU5tlAuyBFYF69uvC4CB1dYcWrWCUuaVmqMpHbRs9mwgj6Lyx1epYZ/HS J6ATvW5MrkovFjIeyff2ZF7aTBcQ7SFa9bRU7z/74Yz8mxeBzr5DX7KHs/oXBsi1 HC9Zs6IQmghNp9UNVZgbU5zR2EBjfo8VgKI3aftuCyzHSmQYrxXtyBdvU9lXLds9 YkPOFOg9qWCrUlC2d2kd0/JdCNOmxCkEC94lUnA+f4nw/+n/nLyoIUJbJC3xtSLX RjxE6QRdiHls3CIhxXbcrbyn0LIdPKvrzboBto2oHaZUX30/ClNzGydKUfFDd6pT R3jgnRv+TOaFzkgeCAoZCG8zroOTQ67ADJhJ6I40lq4XFWO4ySdh3jAwp5f80YYN 8qWlbiX14MRIUXO4j0gK6BigEep+Ieg4Mo6VEmE7AdusT1J4gylUWcvwArpO5Bkb +DNGu8Vi5ZDCqsrEDVVR =2Zs/ -----END PGP SIGNATURE-----