Updating the version of log4j2

[pgomulka]

Updating to latest 2.12.1

closes #45523

[elasticmachine]

Pinging @elastic/es-core-infra

[pgomulka]

I am facing some problems with security permission with this log4j2 version
It appears that it now requires getClassLoader permission
this was introduced in this commit https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;a=commitdiff;h=dfced48;hp=a15b58450c4afcb9a7604308e0d3d81872226953

the discussion https://jira.apache.org/jira/browse/LOG4J2-2266

the test that is failing

java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")

    at __randomizedtesting.SeedInfo.seed([E11D7EE195541C22:C13E3F81DC84F92D]:0)
    at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
    at java.base/java.security.AccessController.checkPermission(AccessController.java:1044)
    at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408)
    at java.base/java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:2048)
    at java.base/java.lang.ClassLoader.getParent(ClassLoader.java:1805)
    at org.apache.logging.log4j.util.LoaderUtil.getClassLoaders(LoaderUtil.java:121)
    at org.apache.logging.log4j.util.PropertiesUtil$Environment.<init>(PropertiesUtil.java:334)
    at org.apache.logging.log4j.util.PropertiesUtil$Environment.<init>(PropertiesUtil.java:312)
    at org.apache.logging.log4j.util.PropertiesUtil.<init>(PropertiesUtil.java:71)
    at org.apache.logging.log4j.simple.SimpleLoggerContext.<init>(SimpleLoggerContext.java:70)
    at org.elasticsearch.common.logging.DeprecationLoggerTests$1.<init>(DeprecationLoggerTests.java:337)
    at org.elasticsearch.common.logging.DeprecationLoggerTests.testLogPermissions(DeprecationLoggerTests.java:337)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at 

@pugnascotia Should we add a security grant for log4j to allow this?
Oddly I only see this failing in test. When running a server I don't see this problem

[pugnascotia]

Let's ask @rjernst.

[rjernst]

Logging is initialized before we set the security manager, which is why this does not fail in production. I think the permission could be avoided if we mock or subclass the LoggerContext interface in the test instead of extending SimpleLoggerContext?

Separately, this looks like a regression in log4j, as there is special handling there to detect security manager and do best effort when it does not allow certain permissions. The problem here is the loop traversing the hierarchy of classloaders. The calls to getParent() should be protected in LoaderUtil.getClassLoaders() so that if a security manager is installed without this permission, only the classloader of LoaderUtil gets returned. We should at least report this issue back to log4j.

[pgomulka]

I suspect the problem with getClassLoader and security permissions we were facing should be fixed by apache/logging-log4j2@fbde9cd

I am getting a lot of thirdpartyaudit problems though..

edit: the fix is actually scheduled for version 3.0.

[pgomulka]

@rjernst

Logging is initialized before we set the security manager, which is why this does not fail in production. I think the permission could be avoided if we mock or subclass the LoggerContext interface in the test instead of extending SimpleLoggerContext?

But is this correct? if we initialise logging before security manager, then some of the logging static settings will be incorrect. Like with class loading. See here in old 2.11 version - the same logic is in latest log4j version
https://github.com/apache/logging-log4j2/blob/rel/2.11.1/log4j-api/src/main/java/org/apache/logging/log4j/util/LoaderUtil.java#L59

[pgomulka]

awaits a fix within log4j

[L3P3]

We need another quick update to patch Elastic against the new #log4shell hack vector!

[nik9000]

Have a look at https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476 we're trying to keep all the communications for log4jshell in one spot we can patch as things change.

…

On Sun, Dec 12, 2021, 4:26 PM Len ***@***.***> wrote: We need another quick update to patch Elastic against the new #log4shell hack vector! — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#47298 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABUXIRRIOBYHVEX5XU27WLUQUHPBANCNFSM4I33UR3A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[pgomulka]

We discussed this with @ChrisHegarty and @arteam
We have analysed the use of LoaderUtil and how it differs in between versions 2.11 and 2.16. Even though we do not agree with how the classloader hierarchy is traversed we think it is safe to use it.

The failing DeprecationLoggerTests.testLogPermissions is removed in latest versions, I raised an issue to analyse if we still need it #81708

[ChrisHegarty]

We discussed this with @ChrisHegarty and @arteam
We have analysed the use of LoaderUtil and how it differs in between versions 2.11 and 2.16. Even though we do not agree with how the classloader hierarchy is traversed we think it is safe to use it.

Agreed. From the perspective of LoaderUtil, there are no substantive differences relating to how permissions are determined and checked. The code does not take into account the dynamic nature of the security manager, and permission stack walking, but that is not new in 2.15, it's there in prior versions too. We'll proceed with the upgrade, and circle back to the aforementioned issue in log4j at some future point.

[pgomulka]

closing as log4j was updated to 2.17