-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Java: QL Query Detector for JHipster Generated CVE-2019-16303 #4312
Java: QL Query Detector for JHipster Generated CVE-2019-16303 #4312
Conversation
2ad0c8b
to
b86e88e
Compare
b86e88e
to
ab618dc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this query be in the experimental folder?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great to see a pull request for a query that's been used to find so many real problems in open source projects.
The Pull-Request-Check/QHelp-Preview failure looks as if it's due to some missing <p>
tags. I've added suggestions that I hope will fix this test. Once the preview is available, I can review the help topic.
Co-authored-by: Felicity Chapman <[email protected]>
Co-authored-by: Felicity Chapman <[email protected]>
For this submission, it's my goal for this query to meet the additional requirements under the 'supported queries' category by also including help and tests. |
Thank you @felicitymay for the rapid feedback on these pull requests. It's really appreciated!! |
Co-authored-by: Felicity Chapman <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for this contribution and for your efforts to make open source software more secure!
|
||
from VulnerableJHipsterRandomUtilMethod the_method | ||
select the_method, | ||
"RandomUtil was generated by JHipster Generator version vulnerable to CVE-2019-16303" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This query catches cases of badly generated RandomUtil
classes. However, it would be possible to generalise this query even further. If I am not mistaken the actual problem is the use of java.util.Random
(or wrapper classes like RandomStringUtils
) in places where you're doing something crypographically sensitive.
It is of course very hard to write a query that finds all "crypographically sensitive" pieces of code. However, we could start by treating methods named generatePassword
, generate%Token%
, generate%Key
, etc. as likely to be sensitive. That way the query should flag up the generated JHipster classes and potentially many more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi - thanks for merging the fixes to the qhelp format and allowing us to see the generated output 😄 Thanks also for including a help file for this query, and especially for including example code.
Looking at the references, it strikes me that the help topic covers the vulnerability and potential for attack well, but that it doesn't say much about the underlying cause of poor "random" number generation. I think would be a good idea to update the content to explain briefly what the problem is with the RandomUtil
class generated by vulnerable versions of JHipster. This might help people be more aware of the problem as they're working on future projects.
|
||
<example> | ||
|
||
<p>The example below shows the vulnerable <code>RandomUtil</code> class generated by JHipster.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Presumably this is what vulnerable versions of JHipster generate? If so, we should mention this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can do
<sample src="JHipsterGeneratedPRNGVulnerable.java" /> | ||
|
||
<p>Below is a fixed version of the <code>RandomUtil</code> class.</p> | ||
<sample src="JHipsterGeneratedPRNGFixed.java" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We usually use comments to highlight the GOOD
and BAD
code in examples. Is this possible here? If not, it might be worth highlighting the area that's different?
I'm not looking at a diff of the two code examples here, and I'm not a developer, so this may be a daft suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can add this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
github#4312 Co-authored-by: Felicity Chapman <[email protected]> Co-authored-by: Arthur Baars <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the most recent updates. Unfortunately, there's a typo 😞
java/ql/src/Security/CWE/CWE-338/JHipsterGeneratedPRNGVulnerable.java
Outdated
Show resolved
Hide resolved
java/ql/src/Security/CWE/CWE-338/JHipsterGeneratedPRNGVulnerable.java
Outdated
Show resolved
Hide resolved
java/ql/src/Security/CWE/CWE-338/JHipsterGeneratedPRNGVulnerable.java
Outdated
Show resolved
Hide resolved
java/ql/src/Security/CWE/CWE-338/JHipsterGeneratedPRNGVulnerable.java
Outdated
Show resolved
Hide resolved
java/ql/src/Security/CWE/CWE-338/JHipsterGeneratedPRNGVulnerable.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Felicity Chapman <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your patience with all the content updates. All LGTM now.
/** Definitions related to the Apache Commons Lang library. */ | ||
import semmle.code.java.Type |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like there's an autoformat failure in this file:
ql/java/ql/src/semmle/code/java/frameworks/apache/Lang.qll is not correctly formatted
I think it's just missing an empty line between the file-level qldoc and the first import, but autoformat will tell.
Also, while we're at this file, could you replace the import with import java
? We prefer always starting with import <lang>
as the very first import in each file and this will include semmle.code.java.Type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why import all of java
when I only need the one import? That sounds like creating tighter coupling to more imports than this class truly needs.
Exec.qll
also only imports semmle.code.java.Type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've fixed it the way you've requested, but I'd still like to better understand the rationale here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The optimiser will remove anything that's imported but not used, so no worries there. However, even though the optimiser tries its best to be as deterministic as possible, there are certain choices it has to make that needs some sort of arbitrary tiebreaker, which in the end can come down to the order in which declarations are encountered when traversing imports. Mostly this doesn't matter as the generated code will tend to be equivalent, but it might cause cache misses that can force re-evaluation of large parts of the libraries. We have been bitten by this problem before, and a good rule-of-thumb to avoid it is to start all ql files with import <lang>
as the first import.
a9c5551
Woot! All the checks have passed! |
😄 Woot!!! |
This is the query I used to create the list of 5,500 projects used to generate 3,880 pull requests to fix this vulnerability across GitHub.
This query was run against all (21,955) Java projects on LGTM.com and came back with 5,511 results.
https://lgtm.com/query/8455949919266029298
All For One Bounty Submission
This query is submitted as a part of the 'All For One' bounty submission. That submission can be found here:
github/securitylab#180