Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 18 Mar 2017 18:36:50 +1100
From: Brian May <>
Subject: Re: Dealing with CVEs that apply to unspecified package versions

Ludovic Courtès <> writes:

> Some CVE entries do not specify the version of the package(s) they apply
> to.  For instance, the software list for CVE-2016-10165 contains
> “cpe:/a:littlecms:little_cms_color_engine”, which theoretically means
> that it applies to any version of lcms.
> The problem is automated tools cannot exploit such entries in practice
> because they cannot tell which package versions are affected.

I am not sure the software version helps that much. It can lead to
incorrect decision. For example, for security flaw B upstream might say
versions before Y.Y.Y are not applicable - lets say version X.X.X <
Y.Y.Y and as such as OK, because the do not contain the vulnerable
code. In fact, somebody could check the code and mark this security flaw
as not applicable.

Meanwhile, somebody else gets around to adding another (earlier)
security patch for A to Y.Y.Y. This security adds the vulnerable code
for B. Anybody making a quick inspection would not notice now that Y.Y.Y
patched for A is now vulnerable to B. In fact B was already marked as
not vulnerable, so there may not even be need to look at it again (not
sure how to solve this problem).

While a "fixed in version" is useful, a pointer to a commit that fixed
the problem would be even better - and means less speculation on which
commit actually fixes the issue. In fact some upstreams won't even
answer bug reports asking if security issues has been fixed or not.
Brian May <>

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.