> On Dec 15, 2019, at 3:06 PM, Andrew Marlow <[email protected]> wrote: > > On Sun, 15 Dec 2019 at 21:47, Gary Gregory <[email protected] > <mailto:[email protected]>> wrote: > >> Thanks for bring up policy Ralph. For me, a new Log4j 1 release would have >> to patch a pretty catastrophic security vulnerability. >> > > Yes, I believe it is. It's basically the same as CVE-2017-5645. The logger > can listen on a socket and receives a message which it interprets as of > type LoggingEvent. The deserialisation does not checking and so a nefarious > message can make the deserialise go wrong and cause an escalation of > privilege. The code responsible in v1 is SocketNode.java. Red Hat have > published a fix for this but they didn't tell the apache log4j project. I > spoke to Red Hat about this and the reason they gave was they thought the > fix might be rejected due to log4j-v1 being at end of life. I'm not sure > that they even reached out, but I thought I would try.
The fix for this CVE is pretty easy. Don’t use the Socket Server. I am not even sure how RedHat fixed this. https://www.redhat.com/archives/rhsa-announce/2017-August/msg00038.html <https://www.redhat.com/archives/rhsa-announce/2017-August/msg00038.html> mentions Log4j 2, which we have addressed. Part of the fix was to remove the Socket Server from Log4j 2. We have never published the library we moved it to but before we do I am sure we will modify it to not use Java serialization. I suspect RedHat added white listing for the Java classes that can be deserialized. I have no desire to do that in Log4j 1. I have no desire to do anything in Log4j 1. > > >> As Ralph pointed out, the first thing I would do is migrate to Log4j 2 and >> it's support for 1.x. >> > > The component I am using that has the dependency on log4j-v1 is wildfly. > Unfortunately, wildfly will not move to log4j2. jboss has the same issue > and will not move for the same reason. I am aware that there are other > applications servers we could use. I checked tomcat and it moved to log4j2 > some time ago. However, the software I am working on is a proprietary > product where we have to tell the customer which application servers are > supported. I suppose we could tell them they have to stop using jboss and > start using tomcat instead but that would be extremely disruptive for them > so I would rather not. I am trying to persuade the wildfly developers to > change their mind but it doesn't look likely. If you are having trouble getting Log4j 2 to work in Wildfly I am sure we would be happy to help. I do see https://issues.apache.org/jira/browse/LOG4J2-1094 <https://issues.apache.org/jira/browse/LOG4J2-1094> that has been open for a long time that has been causing people grief. Is this what is biting you? Ralph
