Hello, I’m looking for feedback on whether there would be project interest / support on me creating an initial fuzz test suite for some core GRUB functions and then integrating these fuzzers into the OSS-Fuzz project that would run them and automate bug reporting to project owners / maintainers on some predefined periodic basis. https://github.com/google/oss-fuzz
Fuzzing helps find program correctness issues like out of bounds accesses, use after free, crashes, etc. that can sometimes be used for malicious purposes. To get a sense of what a fuzzer suite looks like you could reference an existing project integrated into oss-fuzz like GNUTLS: https://gitlab.com/gnutls/gnutls/-/tree/master/fuzz?ref_type=heads There is some project setup as well in the oss-fuzz repo similar to: https://github.com/google/oss-fuzz/tree/master/projects/gnutls If there is favorable feedback I would perform the following general steps: 1. Identify core GRUB functions to fuzz first (likely those usable in lockdown and seen as most likely to be widely used at first, and that are seen as a possible source of untrusted input). 2. In a private fork of GRUB (with core GRUB maintainers invited): a. Get a fuzz target added to the build system. b. Implement fuzzers for the core features. c. Fix issues identified by the fuzzers, if any. d. Create docs around how to build the fuzzers, run them, and locally troubleshoot issues e. Submit patches to the maintainers and (if not sensitive due to uncovered vulnerabilities) to this mailing list for review. f. With maintainers support, get the fuzzers merged to GRUB mainline. 3. Open a new project request in the oss-fuzz repo following their documentation: a. https://github.com/google/oss-fuzz/blob/master/docs/getting-started/accepting_new_projects.md b. https://google.github.io/oss-fuzz/getting-started/new-project-guide/ 4. If the project approves I’d be willing to serve as the maintainer of the fuzzing and oss-fuzz components to ensure build failures are corrected and newly identified issues are worked and triaged. 5. Over time we can work to improve code coverage via the fuzzers. Pros: 1. Increase the code robustness 2. Quickly find robustness issues caused by future changes Cons: 1. Requires up front development to get going- I’m happy to do as much of this as I can but it will require support from the busy project maintainers for reviews and such 2. Requires staying on top of new fuzz failures prior to the oss-fuzz disclosure deadline (I’m happy to support this as much as I can) - ref https://google.github.io/oss-fuzz/getting-started/bug-disclosure-guidelines/ Please let me know your thoughts. Thanks, Andrew
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
