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?

Thanks @xcorail for looking into this issue. Yes, it's related to PR github/codeql#3090.

@luchua-bc

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 .

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

@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.

Hi @aibaars ,

I've submitted a new PR 3487 to merge the change for JBoss logging. Thanks again for your help.

@luchua-bc

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

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?

Thanks @aibaars . I've added CVE-2019-10212 and the second PR to the pull request description above.

@luchua-bc

@xcorail Please let me know if you need some information like my HackerOne email address and/or account name from me.

Thanks,
@luchua-bc

Hey @luchua-bc sorry for the delay.
Yes, please provide your hackerone email address privately.

Thanks @xcorail . I've sent my hackerone email address to your GitHub email address.

Cheers,
@luchua-bc

Got it!

Created Hackerone report 886287 for bounty 220141 : [55] Java: CWE-532 sensitive info logging 🎉

Thanks @xcorail for the bounty.

@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" in getACredentialRegex?

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.

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.