Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ