Security actions to mitigate future vulnerabilities

Security actions to mitigate future vulnerabilities

[Luís Ferreira]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

During my fuzzing test with libfuzzer I found out that GCC is not part
of OSS-Fuzz project. Would be cool to discuss here a bit more about
fuzzing GCC codebase in order to mitigate some future vulnerabilities
that may appear. I can volunteer myself to add the necessary steps to
fuzz GCC on the OSS Fuzz side, but I would like to get some status on:

- Does GCC build system support at least AFL or libfuzzer?
- Is there any infrastructure to automatically test this?
- How to test GCC with fuzzing, if possible

-- 
Sincerely,
Luís Ferreira @ lsferreira.net


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Security actions to mitigate future vulnerabilities

[Jonathan Wakely]

On Tue, 28 Sept 2021 at 17:23, Luís Ferreira <contact@lsferreira.net> wrote:
>
> During my fuzzing test with libfuzzer I found out that GCC is not part
> of OSS-Fuzz project. Would be cool to discuss here a bit more about
> fuzzing GCC codebase in order to mitigate some future vulnerabilities
> that may appear. I can volunteer myself to add the necessary steps to
> fuzz GCC on the OSS Fuzz side, but I would like to get some status on:
>
> - Does GCC build system support at least AFL or libfuzzer?
> - Is there any infrastructure to automatically test this?
> - How to test GCC with fuzzing, if possible

I'd like the libstdc++ <iostream> and <regex> code to get fuzzed, and
maybe std::filesystem::path construction. I've discussed it with
people before, but none of us got around to setting it up.

Re: Security actions to mitigate future vulnerabilities

[Luís Ferreira]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

On Tue, 2021-09-28 at 17:59 +0100, Jonathan Wakely wrote:
> On Tue, 28 Sept 2021 at 17:23, Luís Ferreira <contact@lsferreira.net>
> wrote:
> > 
> > During my fuzzing test with libfuzzer I found out that GCC is not
> > part
> > of OSS-Fuzz project. Would be cool to discuss here a bit more about
> > fuzzing GCC codebase in order to mitigate some future
> > vulnerabilities
> > that may appear. I can volunteer myself to add the necessary steps
> > to
> > fuzz GCC on the OSS Fuzz side, but I would like to get some status
> > on:
> > 
> > - Does GCC build system support at least AFL or libfuzzer?
> > - Is there any infrastructure to automatically test this?
> > - How to test GCC with fuzzing, if possible
> 
> I'd like the libstdc++ <iostream> and <regex> code to get fuzzed, and
> maybe std::filesystem::path construction. I've discussed it with
> people before, but none of us got around to setting it up.

My idea would be to start with libiberty mangling, since it is what I'm
tackling right now. this can be further expaneded to libstdc++, if
needed. Adding the infrastructure for that to automatically fuzz GCC
components easily, would be desired as a first step, IMO.

-- 
Sincerely,
Luís Ferreira @ lsferreira.net


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Security actions to mitigate future vulnerabilities

[Jonathan Wakely]

On Tue, 28 Sept 2021 at 18:15, Luís Ferreira <contact@lsferreira.net> wrote:
>
> On Tue, 2021-09-28 at 17:59 +0100, Jonathan Wakely wrote:
> > On Tue, 28 Sept 2021 at 17:23, Luís Ferreira <contact@lsferreira.net>
> > wrote:
> > >
> > > During my fuzzing test with libfuzzer I found out that GCC is not
> > > part
> > > of OSS-Fuzz project. Would be cool to discuss here a bit more about
> > > fuzzing GCC codebase in order to mitigate some future
> > > vulnerabilities
> > > that may appear. I can volunteer myself to add the necessary steps
> > > to
> > > fuzz GCC on the OSS Fuzz side, but I would like to get some status
> > > on:
> > >
> > > - Does GCC build system support at least AFL or libfuzzer?
> > > - Is there any infrastructure to automatically test this?
> > > - How to test GCC with fuzzing, if possible
> >
> > I'd like the libstdc++ <iostream> and <regex> code to get fuzzed, and
> > maybe std::filesystem::path construction. I've discussed it with
> > people before, but none of us got around to setting it up.
>
> My idea would be to start with libiberty mangling, since it is what I'm
> tackling right now. this can be further expaneded to libstdc++, if
> needed. Adding the infrastructure for that to automatically fuzz GCC
> components easily, would be desired as a first step, IMO.

Loads and loads of people seem to fuzz the demangler, judging by the
number of bugs that get reported against it with reproducers that
obviously come from a fizzer.

It might be more useful to fuzz somethign else that everybody isn't
already doing.

Re: Security actions to mitigate future vulnerabilities

[Luís Ferreira]

[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]

On Tue, 2021-09-28 at 19:18 +0100, Jonathan Wakely wrote:
> On Tue, 28 Sept 2021 at 18:15, Luís Ferreira <contact@lsferreira.net>
> wrote:
> > 
> > On Tue, 2021-09-28 at 17:59 +0100, Jonathan Wakely wrote:
> > > On Tue, 28 Sept 2021 at 17:23, Luís Ferreira
> > > <contact@lsferreira.net>
> > > wrote:
> > > > 
> > > > During my fuzzing test with libfuzzer I found out that GCC is not
> > > > part
> > > > of OSS-Fuzz project. Would be cool to discuss here a bit more
> > > > about
> > > > fuzzing GCC codebase in order to mitigate some future
> > > > vulnerabilities
> > > > that may appear. I can volunteer myself to add the necessary
> > > > steps
> > > > to
> > > > fuzz GCC on the OSS Fuzz side, but I would like to get some
> > > > status
> > > > on:
> > > > 
> > > > - Does GCC build system support at least AFL or libfuzzer?
> > > > - Is there any infrastructure to automatically test this?
> > > > - How to test GCC with fuzzing, if possible
> > > 
> > > I'd like the libstdc++ <iostream> and <regex> code to get fuzzed,
> > > and
> > > maybe std::filesystem::path construction. I've discussed it with
> > > people before, but none of us got around to setting it up.
> > 
> > My idea would be to start with libiberty mangling, since it is what
> > I'm
> > tackling right now. this can be further expaneded to libstdc++, if
> > needed. Adding the infrastructure for that to automatically fuzz GCC
> > components easily, would be desired as a first step, IMO.
> 
> Loads and loads of people seem to fuzz the demangler, judging by the
> number of bugs that get reported against it with reproducers that
> obviously come from a fizzer.
> 
> It might be more useful to fuzz somethign else that everybody isn't
> already doing.

The problem right now is that those fuzzing tests need to be done by
hand. With the support of fuzzing + sanitization on the build system
and with OSS Fuzz this is done continuously by Google clusters.

I also see your point about prioritizing more critical things first.

-- 
Sincerely,
Luís Ferreira @ lsferreira.net

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]