Tracking bugs that are not *technically* security bugs, but still security-impacting

[Ariadne Conill]

Hello,

GNU grep 3.7 was released over the weekend with this bugfix:
https://git.savannah.gnu.org/cgit/grep.git/commit/?id=192e59903c7d313bb47de3d5c15b3dc634e98c5f

This was a performance regression caused by a defect in the way patterns
were being cached.

For example, the command `: | grep -Ff <(seq 6400000 | tr 0-9 A-J)` was
characterized as taking multiple days to complete with affected versions,
instead of a few seconds as with non-affected versions.

This is obviously a security impacting issue, because CGI scripts and
whatnot which use grep can possibly be abused to exhaust CPU on a host.

But MITRE, as far as I understand their policies, are unlikely to issue a
CVE for this bug, even though it needs to be handled like any other kind
of security update.

Should we track these kinds of bugs in UVI?

Ariadne

[Kurt Seifried]

Yes. It has a AIC impact (Availability of resources), and more to the point is the kind of thing people need to know about, your web server is slow... why? oh here's a process running, lets google some stuff, oh look, there's some UVI's for this component with performance impact tags, oh cool, now I know what the problem is! 

 

Ariadne

[Josh Bressers]

I think yes. I would also compare this to the fuzzing findings from OSV. The legacy vulnerability databases are constrained by their human handlers, so they have to be overly selective, this is why UVI was created.

The question becomes how to track and handle these. Ideally we don't want humans gatekeeping anything. The DWF project had a web form anyone could fill out to request an ID (it's still in the uvi-tools repo). I'm not against this approach, but I would prefer something more automated. For example, there are probably plenty of other commits in the grep repo

https://git.savannah.gnu.org/cgit/grep.git/log/?qt=grep&q=performance

If we search for performance I see a few others that I think are comparable to this.

I've been thinking about ways to automate digging through git commits for certain keywords. Many projects would have different keywords. "performance" for grep matters but it might not for the compiler. Another favorite example is this query

https://github.com/search?q=%22prototype+pollution%22&type=issues

3.6 million github issues that mention "prototype pollution". There are a bit over 200K CVE IDs ever handed out right now. Even if only 10% of those are problems, that's more IDs than we've ever issued up to this point.

Of course how to consume all of this data is another problem, but we can't really figure that out before we have data :)

--

    Josh

[Ariadne Conill]

Hi,

On Mon, 16 Aug 2021, Josh Bressers wrote:

>
>
> On Mon, Aug 16, 2021 at 1:38 PM Ariadne Conill <ari...@dereferenced.org> wrote:
> Hello,
>
> GNU grep 3.7 was released over the weekend with this bugfix:
> https://git.savannah.gnu.org/cgit/grep.git/commit/?id=192e59903c7d313bb47de3d5c15b3dc634e98c5f
>
> This was a performance regression caused by a defect in the way patterns
> were being cached.
>
> For example, the command `: | grep -Ff <(seq 6400000 | tr 0-9 A-J)` was
> characterized as taking multiple days to complete with affected versions,
> instead of a few seconds as with non-affected versions.
>
> This is obviously a security impacting issue, because CGI scripts and
> whatnot which use grep can possibly be abused to exhaust CPU on a host.
>
> But MITRE, as far as I understand their policies, are unlikely to issue a
> CVE for this bug, even though it needs to be handled like any other kind
> of security update.
>
> Should we track these kinds of bugs in UVI?
>
>
> I think yes. I would also compare this to the fuzzing findings from OSV. The legacy vulnerability databases are constrained by their human handlers, so they have to be overly selective, this is why
> UVI was created.
>
> The question becomes how to track and handle these. Ideally we don't want humans gatekeeping anything. The DWF project had a web form anyone could fill out to request an ID (it's still in the
> uvi-tools repo). I'm not against this approach, but I would prefer something more automated. For example, there are probably plenty of other commits in the grep repo
> https://git.savannah.gnu.org/cgit/grep.git/log/?qt=grep&q=performance
> If we search for performance I see a few others that I think are comparable to this.

Right, exactly, we want to try to map out the entire software defect
ecosystem. Humans can enrich the data already ingested by adding
additional tags and metadata, such as labelling it as a security-impacting
defect.

And that, too, can be automated: if a distribution releases a security
update with UVI-2021-XXXXXXX as an associated identifier, then obviously
that record can be automatically updated to be a security issue.

> I've been thinking about ways to automate digging through git commits for certain keywords. Many projects would have different keywords. "performance" for grep matters but it might not for the
> compiler. Another favorite example is this query
> https://github.com/search?q=%22prototype+pollution%22&type=issues
> 3.6 million github issues that mention "prototype pollution". There are a bit over 200K CVE IDs ever handed out right now. Even if only 10% of those are problems, that's more IDs than we've ever
> issued up to this point.
>
> Of course how to consume all of this data is another problem, but we can't really figure that out before we have data :)

This also sounds really interesting.

Ariadne

[Oliver Chang]

This is interesting! Another related possibility here (and to improve the SNR) might be to define a simple standardized format that can go into a commit message that can be automatically picked up and made into a vulnerability entry. i.e. A "hashtag" of sorts for commit messages which turns the commit into a vulnerability description and then fed into automation to compute affected versions etc. 

e.g. 

Fix buffer overflow in blah. 

#vulnerability #severity-X #introduced-XXX 

 

This also sounds really interesting.

Ariadne

--
You received this message because you are subscribed to the Google Groups "UVI Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uvi+uns...@groups.cloudsecurityalliance.org.