Public reproduction cases in ClusterFuzz security crbugs

92 views
Skip to first unread message

Alesandro Ortiz

unread,
Jul 22, 2021, 5:00:19 PM7/22/21
to Security-dev
Hello,

There are many interesting security crbugs submitted by ClusterFuzz; however, the reproduction cases and other interesting details are not publicly accessible even after the issue is fixed and the crbug is made public. This results in most public ClusterFuzz crbugs having little to no value to external security researchers (like myself) unless it's a simple bug which can be analyzed based on the fix or comments.

External security reports which are fixed are made public by default, and Chromium considers "attachments/pocs included with reports to be an integral part of the report" for external reports.

Can fixed ClusterFuzz reports also be treated in the same way, with generated PoCs included in public reports?

This would be helpful to properly analyze previous bugs and help discover new bugs in the affected areas.

A few crbugs which would benefit from public PoCs:

Regards,
Alesandro Ortiz
Security Researcher

Amy Ressler

unread,
Jul 22, 2021, 5:59:33 PM7/22/21
to Alesandro Ortiz, Security-dev
Hi Alesandro, 

Thanks for your email. 
I'm responding on-list to allow others to respond as well, but there are a couple of things here:

1) The specific ClusterFuzz reports you linked, are not at all external reports. These are internal reports based on bugs discovered by our internal fuzzing infrastructure from fuzzers contributed by internal team members.

2) We welcome and do have external researchers who contribute to our fuzzer infrastructure with fuzzers of their own and are paid a fuzzing bonus for valid security bugs found for by their externally contributed fuzzers. The bugs from those reports are treated as external security reports in that we consider them for VRP rewards. 
The report in the bug tracker is the summary of the report that the specific fuzzer within the greater automated internal fuzzing infrastructure produces. 

These ClusterFuzz reports, however, are not the same as reports from external researchers as they are internal findings based on the output of a particular fuzzer in the fuzzer infrastructure. An automated report is produced in our internal system that is part of that greater fuzzing infrastructure and is not able to be shared externally.  

These bugs fall into this internal summary categorization as stated in our Chrome release notes: 

As usual, our ongoing internal security work was responsible for a wide range of fixes:

  • [1231294] Various fixes from internal audits, fuzzing and other initiatives


Many of our security bugs are detected using AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, Control Flow Integrity, libFuzzer, or AFL.


Amy  

Alesandro Ortiz

unread,
Aug 6, 2021, 5:56:01 AM8/6/21
to Amy Ressler, Security-dev
Hi Amy,

Thanks for the response. I understand ClusterFuzz reports are automated and run on internal infrastructure. However, when developing the logic to create eventually-public crbugs based on ClusterFuzz reports, an intentional decision was made to not attach the PoC to the crbugs (a restricted link was added instead).

To rephrase my initial question: Is it technically feasible to add the currently-restricted PoCs to the public crbugs? If yes, is there a non-technical reason to not add them to the public crbugs?

Even if the PoC doesn't run as-is due to internal non-shareable dependencies, having a partial PoC helps to understand the bug and create a working PoC. This in turn might help a researcher find more issues in that area that wouldn't be found otherwise. I already do this for interesting public reports, even those manually reported by Chromium contributors (not external), and has allowed me to find new security bugs I wouldn't find otherwise (or not as quickly).

Regards,
Alesandro

Abhishek Arya

unread,
Aug 6, 2021, 10:10:47 PM8/6/21
to Alesandro Ortiz, Amy Ressler, Security-dev
This was a limitation of monorail api when filing bugs. there is no logic to add attachments in a programmatic fashion.

--
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

Adam White

unread,
Aug 29, 2021, 3:40:04 PM8/29/21
to Security-dev, Abhishek Arya, amyre...@chromium.org, Security-dev, Alesandro Ortiz
I agree with Alessandro. Small PoCs should be public.
7 Ağustos 2021 Cumartesi tarihinde saat 05:10:47 UTC+3 itibarıyla Abhishek Arya şunları yazdı:
Reply all
Reply to author
Forward
0 new messages