Insufficient Randomness#286
Conversation
| class NonRandomSource extends Source { | ||
| NonRandomSource() { | ||
| exists(CallExpr call | | ||
| this.asExpr() = call and | ||
| call.getTarget().getPackage().getPath() = "math/rand" | ||
| ) | ||
| } | ||
| } |
There was a problem hiding this comment.
| class NonRandomSource extends Source { | |
| NonRandomSource() { | |
| exists(CallExpr call | | |
| this.asExpr() = call and | |
| call.getTarget().getPackage().getPath() = "math/rand" | |
| ) | |
| } | |
| } | |
| class NonRandomSource extends Source, DataFlow::CallNode { | |
| NonRandomSource() { | |
| this.getTarget().getPackage().getPath() = "math/rand" | |
| } | |
| } |
This is a fairly imprecise model. In particular, it assumes that the insufficiently random output is always the result of the function. That is, however, not true for, e.g., Read, which stores its output in the first parameter. FunctionOutput can be used to model that sort of thing.
There was a problem hiding this comment.
Hi @max-schaefer, this is a good point. In that example though, I don't see how it would be any different if Read was used to store a random number in a parameter, and the parameter was later used as a key. This is the only case in which the query would detect this, since it looks for dataflow. However I completely understand your concern about this query in general, and I am not a big fan of it either in its current state. I think insufficient randomness for cryptographic keys is an important issue to tackle though (and is done in other languages), so if you have any advice/ideas regarding how it should be implemented I'd love to hear!
There was a problem hiding this comment.
Apologies, my explanation above was perhaps overly brief. Your current model says that the result of any function in math/rand is a source, from which we then try to find a path to a sink.
The point I was trying to make above is that this is wrong for Read: a path from the result of Read to a sink is uninteresting, since the result of Read doesn't contain the cryptographically problematic data. On the other hand, by restricting ourselves to results we may miss potentially interesting flows from a buffer passed to Read (which after the call does contain the problematic data) to a sink.
There was a problem hiding this comment.
I see @max-schaefer, that completely makes sense. For now I am making fixes for the comments/conflicts in this commit. I will continue to brainstorm ways to tackle this in more detail. I also think it would be very interesting as @smowton mentioned to see what the query discovers experimentally to help discover false positives/negatives.
On that note actually, I am noticing that this PR says this branch has conflicting files (that appear to be files from my other PR) in it, which is very confusing to me. I believe I might have had these files in this branch at some point in the past to help me use similar crypto/dataflow concepts for Go, but they have long since been removed and I am not sure how to fix this (and the "Resolve Conflicts" button next to this conflict is greyed out for me). Do you know what's happening by any chance?
Thanks for all of your help!
There was a problem hiding this comment.
So many git errors :( I am also getting just a merge conflict now with my latest commit to fix things on this thread, and can't even force push it. This may have to do with the conflicting files error I mentioned above, but I'm not sure.
smowton
left a comment
smowton
left a comment
There was a problem hiding this comment.
Looks much better -- @max-schaefer are you happy to go with the quite-broad definitions (anything in math/rand -> anything in cypto/*) for now and perhaps tighten up during promotion from experimental status?
|
Yes, I agree this is fine for an experimental query, so once the conflicts are resolved I think we can merge this. |
|
Try rebasing your branch onto latest |
|
After a bunch of git manipulation it looks like its merging smoothly now. Tests are still running but so far looking good 👍 |
|
Made some trivial fixes as #289, intending to merge than when tests pass |
|
Merged via #289 |
|
@dilanbhalla thanks for your contribution! |
|
@smowton no problem! |
3 participants
Query to detect use of insufficient randomness generated for keys in cryptographic algorithms. So far, a common case of this, using math/rand, is the detected (via dataflow from this here to function names that generally take in cryptographic keys). However, as seen in the insecure randomness queries for other languages, this can be drastically expanded upon through detection of various secure/insecure random sources and cryptographic sinks. Let me know if this could be of use, or if there are any modifications I can make!