Date: Thu, 2 Nov 2017 23:30:38 +0100 From: Lionel Debroux <lionel_debroux@...oo.fr> To: oss-security@...ts.openwall.com Subject: Many issues in "module" / "track" music decoders... -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Summary ======= Another family of decoders for a bunch of old, complex binary music formats, whose code bases are written in C/C++ and originate in the 1990s, has received more or less advertised fixes for many security issues over the past few years. The issues are mostly DoS (divide by zero, heap-based / wild OOB reads), but a number of stack-based and heap-based memory corruptions can be found in the mix. Some issues remain unfixed. These decoders usually run outside a sandbox, one of them is widely distributed (not just on *nix). Patching (especially backports of fixed versions to older, still maintained distros) is insufficient, as is usage and packaging of the newer, more secure and more accurate decoders (libopenmpt, libxmp). That might be partially because few of the "recently" fixed issues received CVEs. Detailed description ==================== The "old, complex binary music formats" I'm referring to are module / track files. Most of these formats were created in the 1980s and 1990s, sometimes as part of intros / demos; the most popular formats are MOD, S3M, XM and IT. Track music is less popular nowadays, but they can still be decoded by many Windows, MacOS X, Linux, *BSD desktop computers thanks to VLC, GStreamer and others. There are large collections of freely downloadable modules, e.g. ModArchive. Portable C/C++ code bases readily usable on modern Linux / *BSD distros which deal with these formats include: * players: libmodplug, libmikmod, libxmp, libopenmpt, libdumb, Open Cubic Player, as well as the closed-source libbass; * trackers (editors + players): OpenMPT (through Wine), Milky Tracker, Schism Tracker. All of the open source code bases are maintained by volunteers on their spare time, AFAICT. Decoders for popular image, music and video formats have received, and still receive, their share of fuzzing work, yielding a steady stream of fixes. Likewise, fuzzing is behind many of the recent fixes on module decoders. Sadly, the availability of: * fixed versions of libmodplug (0.8.9.0 + fixes in Git), libmikmod (3.3.11+), libxmp (nowadays 4.4.x) and libdumb (2.0.x); * libopenmpt (nowadays 0.3), which was derived from the original ModPlug as well, loses several minor features, but provides better rendering accuracy than libmodplug, higher robustness as a result of design + implementation changes followed by long, deep fuzzing rounds, and also a perfect compatibility layer for libmodplug's C API (I gather that deviations in the C API compat layer would be considered bugs by libopenmpt maintainers) remains limited downstream, especially on older distros. Many projects still depend on libmodplug (VLC, GStreamer, etc.) or libmikmod, whereas, as mentioned above, libopenmpt and nowadays libxmp do better jobs. FWIW (the data is imperfect), the popularity of libmodplug in Debian's popcon rivaled that of the X server libraries in late 2016... Summary of the timeline ======================= * 2015, 2016: libxmp received multiple fuzzing rounds, at least by myself (zzuf for the first round, afl later) and Jonathan Neuschäfer (afl); the hard-working maintainer Claudio Matsuoka made fixes for issues uncovered by fuzzing and issues reported by Coverity Scan. He also improved the rendering accuracy further, beating libmodplug at e.g. Saga Musix's (one of the OpenMPT maintainers) complex IT files; * probably 2015: I tried several broken files generated by old fuzzing rounds on Open Cubic Player, found a crash but failed to report it; * November 2016: Hanno Böck sent a patch for issues in libmodplug found by using an asan build; * December 2016 - January 2017: I fuzzed libxmp, libmodplug, libmikmod and libopenmpt with afl, and the closed-source libbass with afl and honggfuzz in dumb mode. I reported the issues upstream. Only libopenmpt didn't segfault; the only issue I had with it was when it attempted to commit (not just allocate) 5+ GB of RAM to play a broken file... fortunately, the Linux OOM killer kicked in quickly, and the host computer didn't suffer much, but that was still DoS. It doesn't seem to occur anymore in newer versions on that sample. There were few libxmp crashes, too. However, libmikmod crashed quite a bit, and libmodplug crashed more, with evidence of memory corruption (bitter complaints from the memory allocator and valgrind). At some point, afl-fuzz's map coverage suddenly jumped to 100%; this was the only time I experienced such behaviour in core-years of fuzzing runs, and libmodplug definitely wasn't the only memory-corrupting code base. * January 2017: I wrote privately to Debian Security + package maintainers, SUSE Security, VLC Security, GStreamer Security, Hanno Böck about libmodplug's issues. In February, to avoid potential fuzzing work duplication before fixes appeared, I notified Agostino Sarubbo. One of the visible effects was the packaging of libopenmpt's libmodplug compat layer, and the Debian VLC package being switched to build against that compat layer, in time for the Stretch release - AFAICT (and unsurprisingly) without ill effects. libmodplug's popularity dropped a hundred spots in Debian popcon (number of installs), but it's still within the top 1000, on nearly half of the small subset of Debian- running computers which report to popcon. Under the current Debian sid, the libavformat57 package depends on libopenmpt0, i.e. FFmpeg seems to have switched to libopenmpt. * 2017: new releases of libmodplug, libmikmod containing fixes for issues I reported. The libmodplug Git repository contains a bunch of additional fixes for less severe issues, not yet part of a release. * April 2017: I requested CVEs to DWF for a subset of the issues fixed by libmodplug 0.8.9.0. For multiple reasons, including my own sloppiness (in August, sitting for ~3 weeks on Kurt Seifried's e-mail requesting commit IDs for the fixes, hoping that the libmodplug maintainer would have some time to push a new release in the meantime), they don't seem to have been assigned yet. * August - September 2017: I used afl on the original, unmaintained libdumb packaged by Debian and others, and kode54's newer libdumb fork packaged basically nowhere. kode54 quickly fixed the crashes I reported and produced new releases. Allegro depends on libdumb. I do not yet have data on the accuracy of kode54/libdumb. * early October 2017: I tried some broken files from old fuzzing rounds in Milky Tracker and Schism Tracker, and sure enough, they don't like it either: segfaults, memory allocator aborts upon corruption. Reported upstream alongside the crash in Open Cubic Player. The Schism Tracker and Milky Tracker maintainers acknowledged receipt. The latter pointed to Jonathan Neuschäfer's issue from over two years ago: https://github.com/milkytracker/MilkyTracker/issues/35 A month later, no fixes have appeared yet in any of the Git repositories. * early November 2017: this post, only ~30 days after the initial reports to three upstreams, but 300+ days after the initial reports to the most popular upstreams, and more than 120 days after versions of libmodplug and libmikmod fixing the most pressing issues were released. Several notes ============= * unsurprisingly, the well-known FLOSS maintainership sustainability problem occurs for module / track handling code as well: while maintainers do try to go out of their way to fix issues, they can only spend so much time on the FLOSS projects they're maintaining. Large batches of issues found by fuzzers usually represent a significant, sometimes too large, strain on their resources; * more patching is needed, especially for older distros, which consumes packager and security maintainer resources; * more fuzzing is warranted, especially for the most popular targets, which have stripped-down load-only modes, and could efficiently be integrated into the likes of OSS-Fuzz. However, fuzzing does limited good when maintainers can't spend enough time to deal with the fallout; * sandboxing would arguably be useful, and lack thereof is partially, well, a maintainer resource issue... Thanks ====== * Sam Hocevar and others for zzuf, Michal Zalewski for afl, Robert Święcki for honggfuzz; * Hanno Böck for TFP and associated work, as well as the disclosure process for one of the first batches of vulnerabilities I found with a fuzzer, in Oracle Berkeley DB; * the upstream maintainers, and downstream packagers, of the libraries and programs I fuzzed; * security teams; * other persons who were part of / aware of this journey :) Regards, Lionel Debroux. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE3bt9Bno1p6KT7q/zE2Z0SUsm6A4FAln7m1sACgkQE2Z0SUsm 6A6KZQ//WBv5pqXK/GjewCvwz2SZd9t717pNGf10gDHxTpynAI4dd1fQx/NXo+Q/ LcFg12JDaC0QRZ0uJxhk81N+T+YNzRKqzV3JHV8OJRFwpiT+WjvUa3Qym03bGVU7 1FJXHT3qYGNAuKPQWRBp2iouTXpzECJu+G52DFwPn5n/XoRal3ijDSBGCddk8BzJ BsKNeM+tHh88Z6C1uVhMTa+hvnKW87wbxiZ/PVktxxlm0T5ZJ0oN/0qkxMBsnVBX 4o/8pHNOFOnKxflGVyOfoTjMosxr2s7K3Bmayik4essDv1+JOBaHo1AYi5Gl47dz wL8+TTiOTHOJO43pK61XS+KRXFONE6bGQdkBC1gyjAlU+OTYJXWRjdkeW61Y0qF8 22BXPaYv+Ynr+egY0CqLqUlLE5zK+Ww3tdq5MsPGXyMfaQGwjl0EInnVZTIWJ7jl BJmkuC2K3QLpwSWjVdSTPq2g4Ay5CX2BqmQsTGBsHncLxU/s/8Ylm6ZFtN5MkJVa CWMEKCm5b5Y2OcPqFKaqG2ULjJFBiZqUSdcmG80gsefBEHFVRC//Z46nTnP5tJq5 wsa94pXzFigvjfQPW1t3n3ZQJ5ATSxMp0XMlpcyOTvEUkYP+GaFdik9cbwsdLi60 WnruiiJcch6EssscK+FwAZZBOU4DpOedqSesBwuKNeKNiX8hAPk= =3ueK -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.