[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAA=AuEenQx_oGZcY3iEwbp+frtfb1cw+fSaNH_kLQmv9+BkJKg@mail.gmail.com>
Date: Sat, 18 Mar 2017 12:51:50 +0300
From: Jerome Athias <athiasjerome@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Dealing with CVEs that apply to unspecified
package versions
We also have this "Is File Version Comparison Sufficient Over Time?"
discussion in the OVAL Developer ml.
Yes, a reference to a commit is good to have, if you have time/resources
for manual vulnerability analysis
There is a trade-off, but I guess the point here is more on how to increase
automation for mitigation/remediation of software vulnerabilities.
Operation Rosehub is one example illustrating why it's important
On Sat, Mar 18, 2017 at 10:36 AM, Brian May <brian@...uxpenguins.xyz> wrote:
> Ludovic Courtès <ludo@....org> 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 <brian@...uxpenguins.xyz>
> https://linuxpenguins.xyz/brian/
>
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.
