Now that I have been granted the commit bit, I see that there are 15 confidential open issues. Is it a mistake that these are confidential? Many of these were filed by Google Autofuzz and I assume it was not their bot’s intention to mark these confidential.
I think they’re marked confidential because many autofuzz-found issues can be exploitable.
True, but then why are some of the others not confidential? It is not obvious to me that the confidential ones have been assessed to be more exploitable than the others.
Should we be assessing the security impact of issues like the fuzzer-found ones? My plan of attack has basically been “fix all the bugs” with an assumption that we don’t have the resources to also assess the security impact of each one.
[just moved this to the Dev forum as we’re discussing potentially exploitable security issues]
Looking at the autofuzz-reported issues, I think I see a pattern that segfaults and out-of-bounds memory accesses and buffer overflow writes are marked as confidential, while number overflows are not.
I think out of bounds pointer reads and writes and seg faults are generally more exploitable than number overflows, in that they can sometimes lead to data exfiltration or arbitrary code execution in a way that’s much harder to do with number overflows.
In a perfect world, we should probably investigate whether they’re exploitable and assign CVEs and quickly release security fixes and notify distribution maintainers to ship the security fixes. That said, all of that takes time and effort which is in pretty short supply without someone working full-time on this. Just fixing the bugs would be a good place to start, once we get more confident in our ability to fix the bugs then we could look at assessing security impact and filing CVEs etc.
In the spirit of ‘great artists steal’, If we wanted to improve our security posture, I think the cURL project has a pretty good security process documented here: curl - Security process.
There have been a few CVEs reported against graphviz in the past: Graphviz : Security vulnerabilities
Ah yes, you’re right, it’s these ones that are marked confidential. Good spotting.
I’m inclined to skip the CVE, distros, etc process for now, with the view that we don’t have the bandwidth for this. We can take a “guilty until proven innocent” approach and conservatively assume every bug fix is security-relevant. I.e. if you’re not on the latest Graphviz release, you should assume you may be missing some security patches. Maybe this is the other maintainers’ status quo already.
For some reason it’s not mentioned on Curl’s website, but they’re also pretty diligent about posting every security fix to the full disclosure and/or oss-security lists.
2 Likes