[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.
