To the Apache Software Foundation Security Discussion Group, Hello, my name is Jonathan Leitschuh. I’m an OSS Security Researcher and recipient of the first-ever Dan Kaminsky Fellowship <https://www.humansecurity.com/blog/our-first-dan-kaminsky-fellow>. I’m reaching out today to discuss some issues I’ve had in the past with the ASF regarding vulnerability disclosure and coordinating that disclosure.
First off, I want to communicate that I clearly understand that in OSS, nobody is owed anything, including when engaging with a volunteer run foundation like the ASF. All software is provided as-is and OSS maintainers are under no obligation to fix any bug or vulnerability identified by the wilder OSS community. In that same light, for a security researcher, the easiest and most straightforward way to get a vulnerability resolved is to publicly disclose the vulnerability via full-disclosure. However, doing so allows attackers time to leverage these vulnerabilities to exploit end-users. In general, I prefer to avoid this option if possible and would rather coordinate disclosure with the maintainers. Mark Thomas recently communicated to me: > As a volunteer org providing stewardship for 350+ projects and 200+ million lines of code we do not have the resources to implement a bespoke disclosure process for each reporter. On my side, I’m looking for vulnerabilities that are endemic to the OSS ecosystem. As a part of the Dan Kaminsky Fellowship, my mission for the next year is to work to eliminate entire classes of security vulnerabilities from OSS leveraging CodeQL and bulk PR generation. Since I’m trying to work on these endemic problems, I’m in an inverted situation at a similar scale. I’m looking at hundreds or thousands of vulnerabilities with a smattering of disclosure channels per organization, between email, TalkTalk, Google Groups, Hacker1, BugCrowd, Google’s Disclosure Process via Monorail, ect... keeping track of all these disclosure channels and the various disclosure states is overwhelming. As a result of my security research, I’m usually looking at hundreds or thousands of impacted OSS projects and I have to be selective about the projects I disclose to. As a result of my experience, not only with the ASF, but other organizations and OSS projects, I’ve decided to change my disclosure process to centrally locate my vulnerability disclosure. It is my intention to establish automation around disclosure of vulnerabilities to consistently enforce my 90-day disclosure timeline. These new policies can be found here: https://github.com/JLLeitschuh/security-research/blob/main/README.md These new policies I’ve established have already caused some conflict. I hope that this email helps explain that my new policies and practices are coming from a place of frustration with the current ASF process, not that I’m trying to intentionally upset anyone. I don’t hold any grudges against anyone specifically at the ASF, but I have struggled enough with the ASF process that I’ve thrown up my hands and decided to forge my own disclosure path. I’ve been told that the ASF has a “if it didn’t happen in email, it didn’t happen” culture, which I understand and respect. I offer the ASF the following suggestion: set up a dummy GitHub account that gets notifications sent to [email protected]. That way, The ASF can get a nice searchable papertrail which will work with your existing infrastructure. Here are the core set of issues I’ve experienced surrounding disclosure regarding the ASF: - Emails being sinkholed without any response for months - Lack of collaboration/communication with the original reporter - Not verifying fixes are sufficient with the original reporter - Lack of collaboration with the original reporter with respect to the vulnerability disclosure contents & CVE body - Disclosures lack important information like the signatures of methods that are impacted or REST endpoints that are vulnerable. - Disclosures lack links to the commits that actually resolve the issue. - Vulnerabilities not being handled within the previously communicated disclosure timeline. - The ASF security team siding with the ASF project maintainers over the researcher regarding vulnerability presence/impact when a vulnerability is clearly present. The ASF has an established Vulnerability Handling Process: https://www.apache.org/security/committers.html However, looking through my email today I very quickly found examples of cases where the ASF had not followed this process. In particular: - CVE-2020-35451: Apache Oozie - Skipped steps 12 & 13 - CVE-2021-36151: Apache Goblin - Skipped steps 5, 6, 7, 12, & 13 In this case, the vulnerability wasn’t ever even confirmed by anyone. I did receive an apology from the ASF security team regarding these issues, which I greatly appreciate, however they are good examples of the problems I’ve experienced with the ASF. Net result from my previous interaction with the ASF: I feel disrespected and ignored and feel like my contributions aren't valued. This has led me to a feeling of resentment towards the ASF and an overall feeling of distrust towards the established ASF vulnerability handling process. The point of this email is to explain my perspective and feelings of frustration I’ve experienced with the ASF. Hopefully through this dialogue a constructive outcome can be achieved. Respectfully, Jonathan Leitschuh Dan Kaminsky Fellowship
