[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <0B12AA49-1E09-4C8F-BDF4-F83DF85F9432@dwheeler.com>
Date: Fri, 13 Nov 2020 15:46:01 -0500
From: "David A. Wheeler" <dwheeler@...eeler.com>
To: oss-security@...ts.openwall.com
Subject: Re: Buffer Overflow in raptor widely unfixed in Linux
distros
> On Nov 13, 2020, at 7:33 AM, Hanno Böck <hanno@...eck.de> 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
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.
