You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
List the CVE ID(s) associated with this vulnerability. GitHub will automatically link CVE IDs to the GitHub Advisory Database. CVE-2019-10212 (not reported by me)
There are many other examples of this category in the CVE database.
Describe the vulnerability. Provide any information you think will help GitHub assess the impact your query has on the open source community.
Information written to log files can be of a sensitive nature and give valuable guidance to an attacker or expose sensitive user information. Third-party logging utilities like Log4J and SLF4J are widely used in Java projects. When sensitive information are written to logs without properly set logging levels, it is accessible to potential attackers who gains access to the
file storage.
Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc). We would love to have you spread the word about the good work you are doing
This issue was closed because there was no pull request referenced.
But one of our colleagues pointed out that it might be related to this PR: github/codeql#3090
CVE-2019-3888 can be easily tested with searching variable names requestHeaders and responseHeaders, while CVE-2019-10212 can be tested with this query.
As JBoss logging is not based on Log4j or SLF4j, the query can be easily extended to accommodate it with the following three minor changes as I tried in my fork:
Then the undertow logging issue can be reported by the query:
I think it will be nice to add JBoss logging so that the query can be more comprehensive and inclusive although JBoss logging is only used in RedHat products comparing with the other two logging mechanisms. As the PR was already merged, I'm not sure what's the process to get the new change reviewed, approved, then merged from my fork. Please advise.
@luchua-bc You can create an additional pull-request or even pull requests with improvements to your query. Adding support for JBoss logging sounds a good addition.
Adding the word challenge as a potentially sensitive variable name makes sense. I don't expect too many false positives for that. Another way to catch those challenge strings is to treat anything that flows in or out of an Authorization header as sensitive.
I'm not too convinced about adding special cases for requestHeader or responseHeader variables, though.
Thanks @Marcono1234 for your suggestions to enhance the query, I think they are good ideas. I've submitted a new PR codeql/pull/3600 to incorporate the changes.
Activity
xcorail commentedon Mar 27, 2020
Hello @luchua-bc
This issue was closed because there was no pull request referenced.
But one of our colleagues pointed out that it might be related to this PR: github/codeql#3090
Can you please confirm that?
luchua-bc commentedon Mar 27, 2020
Thanks @xcorail for looking into this issue. Yes, it's related to PR github/codeql#3090.
@luchua-bc
aibaars commentedon May 14, 2020
You might want to test the query against CVE-2019-3888 which I think was fixed by undertow-io/undertow@20cacc9 . Another one CVE-2019-10212 with fix commit undertow-io/undertow@8b63e25 .
luchua-bc commentedon May 15, 2020
Thanks @aibaars for the recommendation.
CVE-2019-3888 can be easily tested with searching variable names requestHeaders and responseHeaders, while CVE-2019-10212 can be tested with this query.
As JBoss logging is not based on Log4j or SLF4j, the query can be easily extended to accommodate it with the following three minor changes as I tried in my fork:

Then the undertow logging issue can be reported by the query:

I think it will be nice to add JBoss logging so that the query can be more comprehensive and inclusive although JBoss logging is only used in RedHat products comparing with the other two logging mechanisms. As the PR was already merged, I'm not sure what's the process to get the new change reviewed, approved, then merged from my fork. Please advise.
Thanks,
@luchua-bc
aibaars commentedon May 15, 2020
@luchua-bc You can create an additional pull-request or even pull requests with improvements to your query. Adding support for JBoss logging sounds a good addition.
Adding the word
challengeas a potentially sensitive variable name makes sense. I don't expect too many false positives for that. Another way to catch those challenge strings is to treat anything that flows in or out of anAuthorizationheader as sensitive.I'm not too convinced about adding special cases for
requestHeaderorresponseHeadervariables, though.luchua-bc commentedon May 15, 2020
Hi @aibaars ,
I've submitted a new PR 3487 to merge the change for JBoss logging. Thanks again for your help.
@luchua-bc
luchua-bc commentedon May 19, 2020
Hi @aibaars ,
As the new PR 3487 has already been merged and closed, is there anything else that I shall do for this issue? Please advise.
Thanks,
@luchua-bc
aibaars commentedon May 19, 2020
Thanks @luchua-bc ! I'd suggest adding the CVEs you can now detect to the pull request description above.
@xcorail can you take it from here?
luchua-bc commentedon May 19, 2020
Thanks @aibaars . I've added CVE-2019-10212 and the second PR to the pull request description above.
@luchua-bc
luchua-bc commentedon May 27, 2020
@xcorail Please let me know if you need some information like my HackerOne email address and/or account name from me.
Thanks,
@luchua-bc
xcorail commentedon May 29, 2020
Hey @luchua-bc sorry for the delay.
Yes, please provide your hackerone email address privately.
luchua-bc commentedon May 29, 2020
Thanks @xcorail . I've sent my hackerone email address to your GitHub email address.
Cheers,
@luchua-bc
xcorail commentedon May 29, 2020
Got it!
xcorail commentedon May 29, 2020
Created Hackerone report 886287 for bounty 220141 : [55] Java: CWE-532 sensitive info logging🎉luchua-bc commentedon May 29, 2020
Thanks @xcorail for the bounty.
Marcono1234 commentedon Jun 2, 2020
@luchua-bc, what do you think about including Log4j 2 (
org.apache.logging.log4j.Logger) as well?And would it make sense to include
"secret"ingetACredentialRegex?luchua-bc commentedon Jun 2, 2020
Thanks @Marcono1234 for your suggestions to enhance the query, I think they are good ideas. I've submitted a new PR codeql/pull/3600 to incorporate the changes.
luchua-bc commentedon Dec 11, 2021
I've written a Medium article for the GitHub queries relevant to the recent critical zero-day vulnerability CVE-2021–44228 affecting Apache Log4j2 that our queries can detect and help to address over one year ago.