
Java Cryptography Uses in the Wild - adulau
https://arxiv.org/abs/2009.01101
======
hamiltont
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).

~~~
SahAssar
> 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:

[https://www.bleepingcomputer.com/news/security/cisco-
botches...](https://www.bleepingcomputer.com/news/security/cisco-botches-fix-
for-rv320-rv325-routers-just-blocks-curl-user-agent/)

~~~
hamiltont
good lord that's terrible

------
lol768
I'm confused. I've downloaded the dataset from [http://crypto-
explorer.com/cryptomine/](http://crypto-explorer.com/cryptomine/) but I can't
see relevant issues on GitHub for many of these projects that are mentioned in
the CSV (e.g.
[https://github.com/4thline/seamless](https://github.com/4thline/seamless) or
[https://github.com/4thline/seamless](https://github.com/4thline/seamless))

What gives?

------
vbezhenar
I was not able to find a list of issues that their static tool was supposed to
look for. List of links to github issues would be interesting as well.

~~~
lol768
A lot of them seem pretty low-quality automated reports...

It would not surprise me if it turns out some of the issues had been deleted.

> First parameter (with value "MD5") should be any of {SHA-256, SHA-384,
> SHA-512}

Well, surely that depends? If it's being used as a cache key or otherwise not
in a security-critical application, who cares?

> First parameter (with value "EC") should be any of {RSA, DSA, Diffie-
> Hellman}

You mean the tool doesn't understand what elliptic curve crypto is?

------
mdaniel
> 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](https://github.com/eclipse-cognicrypt/CogniCrypt) ) is
an Eclipse plugin, and thus has the Eclipse frame of mind that it's a "valid"
project?

