Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Date: Wed, 23 Apr 2014 04:28:14 +0000 (UTC)
From: "Jan Tepke (JIRA)" <jira@apache.org>
To: log4j-dev@logging.apache.org
Message-ID: <JIRA.12705604.1396256439994.160659.1398227294591@arcas>
In-Reply-To: <JIRA.12705604.1396256439994@arcas>
References: <JIRA.12705604.1396256439994@arcas>
Subject: [jira] [Comment Edited] (LOG4J2-588) Log4j 2 rc1 executes unsigned
 content by checking for plugins
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LOG4J2-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13977811#comment-13977811 ] 

Jan Tepke edited comment on LOG4J2-588 at 4/23/14 4:26 AM:
-----------------------------------------------------------

Yes.
We had this problem not yet been with Log4j2 beta 9. The problem is not that the our log4j jars are not signed. These signed jars try to execute code from other unsigned jars most likely.


was (Author: j. tepke):
Yes.
We did not had these problems with log4j2 beta 9. The problem is not that the our log4j jars are not signed. These signed jars try to execute code from other unsigned jars most likely.

> Log4j 2 rc1 executes unsigned content by checking for plugins
> -------------------------------------------------------------
>
>                 Key: LOG4J2-588
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-588
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0-rc1
>         Environment: Mac Pro, Mac OS X, Java6
>            Reporter: Jan Tepke
>              Labels: Core, Plugins, ResolverUtil
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> Hey guys,
> In our laboratory infrastructure we launch java applications as java webstarts. These applications have to be signed. 
> This now leads us to the following problem:
> Log4j2 rc1 seems to check for plugins in the java home directory of the operating system and tries to access/execute some code of the contained jar files. These files are not signed.
> These cicumstances lead to a Security Exception which did not occur in all minor Log4j2 versions (including beta 9).
> Let me give you some more details.
> Here is the stacktrace showing the situation before the program crashes:
> "javawsApplicationMain" prio=5 tid=1131a1800 nid=0x13fab6000 in Object.wait()
> [13fab2000]
>     java.lang.Thread.State: WAITING (on object monitor)
>     at java.lang.Object.wait(Native Method)
>     - waiting on <7f47700a0> (a java.lang.Object)
> at java.lang.Object.wait(Object.java:485)
>     at
>     com.sun.javaws.ui.JavawsSysRun.delegate(JavawsSysRun.java:214)
> - locked <7f47700a0> (a java.lang.Object)
>     at
> com.sun.deploy.util.DeploySysRun.execute(DeploySysRun.java:24)
>     at
> com.sun.deploy.util.DeploySysRun$1.run(DeploySysRun.java:46)
>     at
>     java.security.AccessController.doPrivileged(Native
>             Method)
>     at
> com.sun.deploy.util.DeploySysRun.executePrivileged(DeploySysRun.java:42)
>     at
> com.sun.deploy.ui.UIFactory.showMixedCodeDialog(UIFactory.java:673)
>     at
> com.sun.deploy.security.CPCallbackHandler.showMixedTrustDialog(CPCallbackHandler.java:887)
>     at
> com.sun.deploy.security.CPCallbackHandler.access$1200(CPCallbackHandler.java:74)
>     at
> com.sun.deploy.security.CPCallbackHandler$ParentCallback.checkAllowed(CPCallbackHandler.java:352)
>     at
> com.sun.deploy.security.CPCallbackHandler$ParentCallback.check(CPCallbackHandler.java:327)
>     - locked
>     <7f4734908>
>     (a
>      com.sun.deploy.security.CPCallbackHandler$ParentCallback)
>     at
> com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$1800(CPCallbackHandler.java:128)
>     at
> com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(CPCallbackHandler.java:506)
>     at
> com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(DeployURLClassPath.java:816)
>     at
> com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(DeployURLClassPath.java:889)
>     at
> com.sun.deploy.security.DeployURLClassPath$JarLoader.findResource(DeployURLClassPath.java:860)
>     at
> com.sun.deploy.security.DeployURLClassPath$1.next(DeployURLClassPath.java:265)
>     at
> com.sun.deploy.security.DeployURLClassPath$1.hasMoreElements(DeployURLClassPath.java:276)
>     at
> java.net.URLClassLoader$3$1.run(URLClassLoader.java:416)
>     at
>     java.security.AccessController.doPrivileged(Native
>             Method)
>     at
> java.net.URLClassLoader$3.next(URLClassLoader.java:413)
>     at
> java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:438)
>     at
> sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:27)
>     at
> sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:36)
>     at
> org.apache.logging.log4j.core.config.plugins.ResolverUtil.findInPackage(ResolverUtil.java:240)
>     at
> org.apache.logging.log4j.core.config.plugins.PluginManager.collectPlugins(PluginManager.java:174)
>     at
> org.apache.logging.log4j.core.config.plugins.PluginManager.collectPlugins(PluginManager.java:130)
>     at
> org.apache.logging.log4j.core.config.BaseConfiguration.start(BaseConfiguration.java:152)
>     at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:341)
>     - locked
>     <7f42b0750>
>     (a
>      org.apache.logging.log4j.core.LoggerContext)
>     at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:386)
>     - locked
>     <7f42b0750>
>     (a
>      org.apache.logging.log4j.core.LoggerContext)
>     at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:149)
>     at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:84)
>     at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:35)
>     at
> org.apache.logging.log4j.LogManager.getLogger(LogManager.java:444)
>     at
> org.apache.logging.log4j.LogManager.getLogger(LogManager.java:389)
>     at
> de.mmis.utilities.genericPublisher.GenericPublisher.<clinit>(GenericPublisher.java:47)
>     at
> de.mmis.utilities.genericPublisher.GenericPublisherMain.main(GenericPublisherMain.java:44)
>     at
>     sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>             Method)
>     at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>     at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at
> java.lang.reflect.Method.invoke(Method.java:597)
>     at
> com.sun.javaws.Launcher.executeApplication(Launcher.java:1953)
>     at
> com.sun.javaws.Launcher.executeMainClass(Launcher.java:1886)
>     at
> com.sun.javaws.Launcher.doLaunchApp(Launcher.java:1648)
>     at
> com.sun.javaws.Launcher.run(Launcher.java:141)
>     at
> java.lang.Thread.run(Thread.java:695)
> The problem seems to be line 240 in the findPackage(...) method in
> core.config.plugins.ResolverUtil. 
> We set a breakpoint in line 234 and stepped through the program. We found
> out that the Enumeration<URL>  urls->enums->[0] ->val$e -> this$0 ->path (ArrayList) consists of the values: 
> [file:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsfd.jar,
> file:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar,
> file:/System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaRuntimeSupport.framework/Versions/A/Resources/Java/JavaRuntimeSupport.jar,
> file:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar,
> file:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/laf.jar,
> file:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/sunrsasign.jar,
> file:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsse.jar,
> file:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/jce.jar,
> file:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/charsets.jar]
> This (probably) leads the method to try to access code inside the jar files.
> Because these jars ore not signed this causes a warning if you start the
> webstart application that says that you try to run both signed and unsigned
> contents.
> I tried to fix this by commenting the whole method. This caused a Null-Pointer-Exception. I think in this context you might need also to think about the return statement in th catch clause in line 237. If the IOException will be thrown, no global side effects could have happened, so this event will also probably cause a
> Null-Pointer-Exception. 


--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org