Log4j / Log4shell vulnerability

[AndiDog]

Describe the bug
log4j 2.15.x does not fully solve it – see https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/:

Log4j 2.16.0 completely mitigates this issue by removing support for message lookup patterns and disabling JNDI functionality by default

Software versions

• ZAP: 2.11.1

[thc202]

That issue does not affect ZAP. It was already updated in #6979.

[steers]

Further details have come to light regarding CVE-2021-45046, resulting in its severity being upgraded to a CVSS score of 9 (from 3.7)

The latest stable zaproxy release (v2.11.1) still uses log4j2 < 2.16.0, with log4j-core (containing JndiLookup.class)

I think the mere potential of latent attack vectors in the latest stable release warrants cutting a new v2.11.2 release using log4j2 v2.16.0 (or potentially v2.17.0 that may be releasing soon) https://logging.apache.org/log4j/2.x/security.html

The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors.

[psiinon]

At the moment I disagree.
Based on the information we currently have and the fact that ZAP actually does very little logging out of the box I think ZAP is not vulnerable to this or related attack vectors.
Releases take time and distract us from everything else we are doing.
Happy to revisit this if new evidence comes to light or if they is a very strong push from the ZAP community.
And if anyone can get an RCE on ZAP 2.11.1 then they are welcome to submit it via our Bug Bounty program: https://bugcrowd.com/owaspzap - it would be worth $1000

[steers]

Unfortunately RCE is not the only concern, there may still exist the potential for data exfiltration or unintended network activity for any Java software that logs external input via log4j2 <2.16.0

For the benefit of anyone else who's paranoid about the current log4j2 situation, a recommended mitigation for log4j2 releases prior to 2.16.0 is to remove JNDILookup.class from log4j-core-$log4jVersion.jar

zip -q -d /zap/lib/log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

[kingthorin]

Re-opening to facilitate discussion and hopefully prevent further duplicates.

[globeone]

Could we change the title to just
Log4J / Log4shell vulnerability
, please? It will make it clearer that all the CVE's are being handled here. Plus adding the official name of the Vulnerability will help security researchers.
If there is something like a sticky post in Github. Then it would be nice if the CVE's were also mentioned, to assist with the Search function in GitHub.

CVSS-10 | CVE-2021-44228 | 2.x | Unauthenticated Remote Code Execution
CVSS-9 | CVE-2021-45046 | 2.15 | Denial of Service and Remote Code Execution
CVSS-7.5 | CVE-2021-45105 | 2.16 | Denial of Service

[nikola6789]

Any target days when a new official release will be out with updated log4j libs?

[kingthorin]

As previously stated we do not currently plan to have another release related to this. If someone is able to perform an RCE vs ZAP please report it via BugCrowd.

[psiinon]

Or if you can find any other non RCE Log4j related problem vs ZAP then just raise a new issue here.

[pburkholder]

I know you've said:

As previously stated we do not currently plan to have another release related to this. If someone is able to perform an RCE vs ZAP please report it via BugCrowd.

However, I'm obligated within the US Federal Govt to demonstrate that we've fully mitigated https://nvd.nist.gov/vuln/detail/CVE-2021-44228. And while you're correct that log4j 2.15.0 in ZAP is not vulnerable, that CVE still lists 2.16.0 and newer as the appropriate mitigation. So....

If you could cut a new release, it would save me, and others in a similar boat, from having to litigate this over and over again.

If not, I can let folks here work on deploying from the weekly, which is suboptimal, but still works for us.

In short: 2.17 would save us a lot of hassle. Thanks for considering!

Or if you can find any other non RCE Log4j related problem vs ZAP then just raise a new issue here.

Yes - compliance drones following directives without nuance is a "non-RCE Log4J related problem" 😁

[psiinon]

Cutting a new release is time consuming for us and not something we want to do unless we really need to.
And I'm on holiday until the New Year 😀
I think using the weekly release is the best option for you right now

[pburkholder]

Got it.

Should I open a new issue for bumping to 2.17.0 or newer in a full release? If there are a lot of other folks in the same boat I am, they can comment/vote there, and you can decide on what's best.

[kingthorin]

Should I open a new issue for bumping to 2.17.0 or newer in a full release?

No this is the spot.

[htenhoor]

I need a release with version 2.17.0 of log4j as well to be compliant with the policies in my organization as well.

[kingthorin]

Thanks for letting us know. Feel free to refer your compliance team to this issue, and don't forget to read the User Group post that @psiinon mentioned.

[wrenashe]

The new release with log4j 2.17.1 is highly appreciated. @psiinon

[psiinon]

@wrenashe sponsorship of ZAP is greatly appreciated :)
https://groups.google.com/g/zaproxy-users/c/Wg-fKIZ2w6I/m/fPbI8wxuAwAJ

[kingthorin]

I’m going to unpin this. It seems no one was concerned enough in the end to sponsor a fix/build.

I believe the issue can actually be closed, we have upgraded dependencies to 2.17.1 and there does not currently seem to be anything newer.

[thc202]

Sounds good.

[psiinon]

+1

[Jeeppler]

What @psiinon did not explain in his statement is: Why it is so difficult and time consuming to create a new release for OWASP ZAP?

Especially, in regards to log4j:

• CVE-2021-45046
• CVE-2021-45105

only the log4j dependency would need to be upgraded to 2.17.2. This has probably no impact on OWASP ZAP. I partly understand the argument regarding Apache HttpClient 3.1. However, I would still argue, that upgrading dependencies should not be so difficult.

Especially, statements like:

"ZAP 2.11.1 uses Apache Commons HttpClient v3.1 - this is no longer maintained and also has at least one CVE against it"

Source: https://groups.google.com/g/zaproxy-users/c/Wg-fKIZ2w6I/m/fPbI8wxuAwAJ

I am not sure what is more concerning, the fact that Apache Commons HttpClient is not maintained or it has a CVE? In my case clearly both.

[kingthorin]

The dependencies are already upgraded, feel free to use a weekly or support ZAP as discussed earlier.

[Jeeppler]

What is the price tag? 200 $ worth in money or time and we get the log4j release?

I do understand and I agree, the companies using OWASP ZAP should give back in time or money. However, there are two aspects to consider:

1. How to balance the influence of money and the community?
2. How do you measure given time in money?

Furthermore, if I invest time or money personally or as an organization my goal would be sustained growth. Paying, for a feature does not ensure the long term growth of the project.

[Jeeppler]

@kingthorin

The dependencies are already upgraded, feel free to use a weekly or support ZAP as discussed earlier.

Your answer is not helpful at all. I read the discussion and still decided to comment on this issue. Try again, maybe you can give me a better answer on the question: Why it is so time consuming to create a new release?

I really do not understand, why you are easily able to release every week, but creating full release is such a huge issue.

[kingthorin]

The real question is why you feel entitled to an answer?

We've stated it's a time sink, you can trust that or not. We would rather you do, but if you don't then okay.....

We're all volunteers with other jobs.

To give you a bit of insight. Doing a full release requires:

• Co-ordination and ticketing with other parties.
• Updating of documentation.
• A bunch of testing.
• Updating API clients.
• Publishing JavaDoc
• Versions files.
• CFU URLs.
• etc

[psiinon]

I dont have an accurate figure on how much a release costs us but its non trivial.
I'm sure we could make it less timeconsuming, but that would also take time.
Right now we aim to release ZAP at least once per year, ideally more, but we havnt done so well with that recently.
The fact that we dont really want to do more than 2 releases a year should give you an idea of the effort involved.
If we had more core team members then we could share the pain around and maybe do them more frequently...

[psiinon]

What is the price tag? 200 $ worth in money or time and we get the log4j release?

TBH we hadnt got as far as putting a price on it.
We had a small number of individuals complain.
To see how much it mattered to them I pointed out that they could contribute to ZAP.
To date no one has, that tells me everything I need to know.

Furthermore, if I invest time or money personally or as an organization my goal would be sustained growth. Paying, for a feature does not ensure the long term growth of the project.

How much are you talking about? $200? $2,000? $20,000? More?
Realistically a relatively small donation will not ensure sustained growth.
To ensure that you would really need to sponsor a member of the ZAP Core Team (existing or new) for a significant sum of money.
If you're looking to do that then please let me know and we can talk about it. Its exactly the sort of thing I want to encourage.

[tspearconquest]

@Jeeppler IMHO, we should discuss more about this on the user list rather than in this closed issue. It will definitely gain more visibility on the user list.

[psiinon]

Thats what the groups are for - much better than discussions on closed issues :D

[Jeeppler]

@psiinon and @kingthorin thank you for the explanation. To summarize your explanation, the problems releasing a new version of Owasp Zap with an updated Log4j dependency is non-trivial as it requires a huge effort for the following reasons:

• coordination with other parties
• testing
• lack of human resources
• publishing several artifacts
• updating documentation

Furthermore, I would like @psiinon or @kingthorin to change the title to: Upgrade log4j to 2.17+ - Log4Shell or just Upgrade log4j to 2.17+. Additionally, it would be nice to keep this issue open, as it is not solved. Once there is a release with log4j 2.17+ you can close this.

Owasp Zap 2.11.1 uses Log4j 2.15.

Log4j 2.15 is vulnerable to:

• CVE-2021-45046 (fixed with Log4j 2.16)
• CVE-2021-45105 (fixed with Log4j 2.17)

as @psiinon mentioned OWASP ZAP is not vulnerable to any of those vulnerabilities.

Workarounds:

• Use the latest weekly Owasp Zap pre-release: https://github.com/zaproxy/zaproxy/releases
• Remove JndiLookup.class: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class (source: https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45046)

[thc202]

Issues are closed once the changes that address them are merged, as is the case.

[Jeeppler]

@thc202 can you link to the pull request?

[thc202]

The pull requests are linked above.

[kingthorin]

Owasp Zap 2.11.1 uses Log4j 2.15.
Log4j 2.15 is vulnerable to:
CVE-2021-45046 (fixed with Log4j 2.16)
CVE-2021-45105 (fixed with Log4j 2.17)

If you can prove some relevant impact from these details please submit it via BugCrowd.

[Jeeppler]

@thc202 if you are referring to is most likely: #6979. This only upgrades log4j to 2.16 not to log4j 2.17.

[kingthorin]

There the two latest have been linked 🔼

The 2.17.1 set are linked earlier in this issue (Dec 28). (They might be in a hidden comment block....GitHub Web UI folds things up at various points when there's lots of activity.)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.