The work is focused on the human element, e.g. accidental and intentional misuse. Here's a summary of Section 3.2 on developer response (the team manually filed 216 github issues)
> 76 did not respond, and 140 reacted to the issues within 20 days. We evaluated all of the responses for 140 repositories in order to identify developer perceptions concerning cryptographic APIs.
Developer responses:
* 46 - It's not really a vulnerability
* 32 - Request for more explanation
* 17 - Open a PR
* 15 - Repo no longer maintained
* 10 - Oracle JCA documentation is ambiguous w.r.t. issue raised
* 7 - I will get to it later
* 5 - It's a dependency, not my code
* 3 - Repo has vulns for learning purposes
A lot of these are fair plays for an open source maintainer. IMO the quotes from the maintainer responses are quite interesting. The authors have a bit of an axe to grind in their rebuttals to each point.
The largest bullet ("It's not really a vulnerability") is a bummer, and it mirrors some of my own experiences with reporting security issues internally. With about half of my reports, the response is "because of X, this is not a problem", where X IMO boils down to "I cannot imagine how this could be abused, so I don't think it's a problem". Basically, send a proof-of-concept or GTFO. In some cases I have gone on to make a PoC just to get the issue resolved. In others I get too tired of arguing that the code is clearly broken and the fix is easy to apply and just move on.
Sometimes there is no help. For one of my customers I submitted a simple curl PoC. It broke into their stack and got sensitive data easily. They "fixed" the issue, but did not bother re-running the PoC. It still worked. I pointed out the fix was incomplete, and was told "that issue was already fixed". I re-submitted the PoC as a new issue, this time with a one-line code patch that resolved it (a broken regex that allowed partial matches). It's still pending.
It's not my intention to say "it's all bad developers" - in the work they also point out that the majority of developers trust and rely on the official Oracle JCA documentation. It was referenced commonly in the github issue responses. The authors point out that the JCA docs are quite incomplete, not mentioning typical constraints for common parameters (e.g. should "iterations" be 1, 10, or 10000? You don't know from the docs, it's just asking for an integer value).
> They "fixed" the issue, but did not bother re-running the PoC. It still worked. I pointed out the fix was incomplete, and was told "that issue was already fixed".
That reminds me of when cisco "fixed" a bug by blocking the curl user agent:
> We exclude any projects that cannot be compiled due to unresolved dependencies.
That's weird -- I would think that static analysis would be enough for what I understand to be the scope of the analysis. I wonder if it's because CogniCrypt (which isn't linked from their paper: https://github.com/eclipse-cognicrypt/CogniCrypt ) is an Eclipse plugin, and thus has the Eclipse frame of mind that it's a "valid" project?
The largest bullet ("It's not really a vulnerability") is a bummer, and it mirrors some of my own experiences with reporting security issues internally. With about half of my reports, the response is "because of X, this is not a problem", where X IMO boils down to "I cannot imagine how this could be abused, so I don't think it's a problem". Basically, send a proof-of-concept or GTFO. In some cases I have gone on to make a PoC just to get the issue resolved. In others I get too tired of arguing that the code is clearly broken and the fix is easy to apply and just move on.
Sometimes there is no help. For one of my customers I submitted a simple curl PoC. It broke into their stack and got sensitive data easily. They "fixed" the issue, but did not bother re-running the PoC. It still worked. I pointed out the fix was incomplete, and was told "that issue was already fixed". I re-submitted the PoC as a new issue, this time with a one-line code patch that resolved it (a broken regex that allowed partial matches). It's still pending.
It's not my intention to say "it's all bad developers" - in the work they also point out that the majority of developers trust and rely on the official Oracle JCA documentation. It was referenced commonly in the github issue responses. The authors point out that the JCA docs are quite incomplete, not mentioning typical constraints for common parameters (e.g. should "iterations" be 1, 10, or 10000? You don't know from the docs, it's just asking for an integer value).