Re: Buffer Overflow in raptor widely unfixed in Linux distros

                							

                <!--X-Body-Begin-->
<!--X-User-Header-->

oss-sec
mailing list archives
<!--X-User-Header-End-->
<!--X-TopPNI-->

By Date

By Thread

</form>

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
Re: Buffer Overflow in raptor widely unfixed in Linux distros

<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->

From: "David A. Wheeler" &lt;dwheeler () dwheeler com&gt;

Date: Fri, 13 Nov 2020 15:46:01 -0500

<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->

<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->

On Nov 13, 2020, at 7:33 AM, Hanno Böck &lt;hanno () hboeck de&gt; wrote:

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).

I don’t know what you mean by “fluctuating reliability”.
I think the #1 reason a vulnerability doesn’t have a CVE assignment
is that no one has reported the vulnerability to a CVE Numbering Authority (CNA).
If that’s the “reliability” problem, it’s hard to blame CNAs for that.

There *is* a process to alert all affected parties; it’s called CVE assignment.
In the case of an unmaintained package that’s in use it’s *especially* important to
have a CVE assigned; the project itself might never release a fix or alert, so we
*need* an external system like CVEs to track those vulnerabilities.
As you noted, backports are often triggered by CVE assignments.
That’s not a problem, that’s a fact that is getting ignored.
“The standard process to trigger backports (namely CVE assignment) was not used and
now I’m unhappy that backports didn’t occur” sounds almost tautological.

As you well know, CVEs aren’t perfect. Far from it (let me help you make that list).
CVE assignments sometimes backlog, but I think since 2017 is enough time :-).
The CVE process does struggle with projects that update relatively rapidly
(hi Linux kernel!), but that’s not the issue in this case. But while CVEs have their
shortcomings, they would trivially have solved this if the process had been actually used.

I think that in addition, any project that patches an external dependency
(like LibreOffice) should also add to their automated test suite a test that verifies that the
fix is actually correctly applied.  Many system packaging systems have a way
to run a test suite as part of the packaging. The packagers should call test suites if they’re
present, and packagers should provide test suites. That would have prevented this kind
of problem (and many others) in a general way. The reproducer .odt file you
just posted would probably be perfect for this.

--- David A. Wheeler

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->

<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->

By Date

By Thread

Current thread:

Buffer Overflow in raptor widely unfixed in Linux distros Hanno Böck (Nov 13)

Re: Buffer Overflow in raptor widely unfixed in Linux distros David A. Wheeler (Nov 13)

Re: Buffer Overflow in raptor widely unfixed in Linux distros Dave Horsfall (Nov 14)

Re: Buffer Overflow in raptor widely unfixed in Linux distros Dave Horsfall (Nov 14)

Re: Buffer Overflow in raptor widely unfixed in Linux distros Ian Zimmerman (Nov 18)

Re: Buffer Overflow in raptor widely unfixed in Linux distros Marcus Meissner (Nov 14)

Re: Buffer Overflow in raptor widely unfixed in Linux distros David A. Wheeler (Nov 16)

Re: Buffer Overflow in raptor widely unfixed in Linux distros Stephen John Smoogen (Nov 16)
Re: Buffer Overflow in raptor widely unfixed in Linux distros Sam James (Nov 16)

Re: Buffer Overflow in raptor widely unfixed in Linux distros Marius Bakke (Nov 16)
Re: Buffer Overflow in raptor widely unfixed in Linux distros Jeremy Stanley (Nov 16)

Re: Buffer Overflow in raptor widely unfixed in Linux distros Sam James (Nov 16)

(Thread continues...)

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->