Integrating with OSS-Fuzz

[Google-Autofuzz]

Greetings flex developers and contributors,

We’re reaching out because your project is an important part of the open source ecosystem, and we’d like to invite you to integrate with our fuzzing service, OSS-Fuzz. OSS-Fuzz is a free fuzzing infrastructure you can use to identify security vulnerabilities and stability bugs in your project. OSS-Fuzz will:

• Continuously run at scale all the fuzzers you write.
• Alert you when it finds issues.
• Automatically close issues after they’ve been fixed by a commit.

Many widely used open source projects like OpenSSL, FFmpeg, LibreOffice, and ImageMagick are fuzzing via OSS-Fuzz, which helps them find and remediate critical issues.

Even though typical integrations can be done in < 100 LoC, we have a reward program in place which aims to recognize folks who are not just contributing to open source, but are also working hard to make it more secure.

We want to stress that anyone who meets the eligibility criteria and integrates a project with OSS-Fuzz is eligible for a reward.

If you're not interested in integrating with OSS-Fuzz, it would be helpful for us to understand why—lack of interest, lack of time, or something else—so we can better support projects like yours in the future.

If we’ve missed your question in our FAQ, feel free to reply or reach out to us at [email protected].

Thanks!

Tommy
OSS-Fuzz Team

[SamB]

Hmm. Wouldn't it be more useful to fuzz somewhat realistic lexers generated in various configurations, in order to exercize both the skeleton code and the generated stuff that flex tends to put into them?

That seems to be where all the juicy attack surface would come from - unless you've seen projects that actually run flex on untrusted lexer definitions?

And that's only the obvious part: next, you'd need to somehow give the fuzzers a clue about the state machine, so they can tell if a new input adds anything "interesting" to the corpus: their usual approach of monitoring the control flow graph wouldn't really know one DFA state from another, so they would likely "get bored" and stop exploring long before hitting the ACCEPT states that would cause actions to run, and you kind of need the actions to run in order to test the APIs that flex provides to action code.

In other words: a reasonable integration for flex seems far from typical.

[szhorvat]

Wouldn't it be more useful to fuzz somewhat realistic lexers generated in various configurations

Indeed. We are currently having difficulties with running Flex-generated lexers on OSS-fuzz when using full scanner tables. See #627 and #628.