-
Notifications
You must be signed in to change notification settings - Fork 25.1k
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
Upgrade log4j to 2.15.0 #81709
Upgrade log4j to 2.15.0 #81709
Conversation
Originally we tried to a log4j update in elastic#47298, but we were unable to that due to the `DeprecationLoggerTests.testLogPermissions` test failing. The test relied on mocking and got removed in https://github.com/elastic/elasticsearch/pull/61474/files#diff-70de5a6ba5c637e7f19c51341417760d6e957beb5a1fa5703049095ea2719ee0L47 Now we should be able to the upgrade and then we can address the Security Manager permission questions raised in elastic#47298 separately.
Pinging @elastic/es-core-infra (Team:Core/Infra) |
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.
left few questions
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.
LGTM
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.
LGTM, thank you !
We need the `getClassLoader` permissions
7bac392
to
0f07251
Compare
@elasticmachine update branch |
b5b2181
to
42350af
Compare
When you work on this pull request, if you look at Log4j 2.16.0 instead, it looks like the hack from #81629 can probably be removed, if that is something you'd want to do. |
2.15.0 is affected by CVE-2021-45046 to boot, which is thankfully migrated already by the previous removing of JndiLookup class |
cedefa2
to
3811045
Compare
FYI we should revert #81629 as part of this as well as it's no longer necessary, especially if we go strait to 2.16 which disabled JNDI support entirely by default. |
59503e9
to
6b44e5e
Compare
c7728a9
to
268b8f7
Compare
log4j-core has released version 2.16.0, which fixes a denial-of-service attack vulnerability in 2.15.0, would you consider upgrading directly to 2.16.0? @arteam |
adffd20
to
3811045
Compare
@Li4n0 We will do the 2.15.0 to 2.16.0 upgrade separately. Unfortunately, it's not a simple version bump, because 2.16.0 forbids things like EDIT: It seems the failures were caused by stripping the |
ba9b1be
to
ef44c85
Compare
ef44c85
to
309b0d5
Compare
Thanks @ChrisHegarty and @pgomulka! |
We upgraded log4j to 2.15.0 in elastic#81709 and we can do the next upgrade. It makes JNDI opt-in and also fixes [CVE-2021-45046](GHSA-7rjr-3q55-vv33)
Tolerate unprivileged log4j getClassLoaders calls, as if (but not exactly) like they were wrapped in doPriv. This is precautionary step as security permission exceptions have been observed during testing. This change also reverts changes to tests in the log4j 2.15 Upgrade #81709, as they should no longer be needed, given this change and changes in #81851. No explicit new test has been added in this PR, but the code in question is exercised extensively by existing tests, since the policy is set in the test framework. The test reverts mentioned above confirm that the changes are working as expected. This change is a workaround to the issue raised in log4j: https://issues.apache.org/jira/browse/LOG4J2-3236
Originally we tried to a log4j update in #47298, but we were unable to that due to the
DeprecationLoggerTests.testLogPermissions
test failing. The test relied on mocking and got removed as part of refactoring in#61474.
Now we should be able to the upgrade and then we can address the Security Manager permission questions raised in #47298 separately.