Hello again, I forgot to mention that if you want to see the patch you can do so directly without having to bother with that RPM. Just go to: https://github.com/jboss-logging/log4j-jboss-logmanager/pull/15/commits/2b425859f4218b32fe450fe4de5cfeeea1564ab3
On Sun, 15 Dec 2019 at 22:06, Andrew Marlow <[email protected]> wrote: > On Sun, 15 Dec 2019 at 21:47, Gary Gregory <[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. > > >> 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. > > > >> Gary >> >> >> On Sun, Dec 15, 2019 at 4:13 PM Ralph Goers <[email protected]> >> wrote: >> >> > While Gary is correct that we wouldn’t want to discuss a specific >> security >> > vulnerability in public we can discuss the policy here. >> > >> > For a number of reasons I would say the answer is “No”: >> > It gives the impress that Log4j 1.x is not End-of-Life and that future >> > enhancements and bug fixes could be accepted. >> > We provide alternatives so that Log4j 1.x itself is not necessary. If >> > features are missing in Log4j 2’s log4j 1.x binding then we would >> consider >> > fixing those. >> > None of the current committers has probably built Log4j 1 in the last 5 >> > years, much less attempted to perform a release. >> > Log4j 1.x supported an ancient version of the JDK (1.2?). I am not even >> > sure if that is possible any more. The oldest version I have installed >> is >> > 1.7. I would have no idea how to validate that it was still compatible. >> > >> > Ralph >> > >> > > On Dec 15, 2019, at 7:25 AM, Gary Gregory <[email protected]> >> > wrote: >> > > >> > > Security issues should not be discussed in public for obvious reasons. >> > > Please see https://www.apache.org/security/ >> > > >> > > Gary >> > > >> > > >> > > On Sun, Dec 15, 2019 at 7:01 AM Andrew Marlow < >> [email protected]> >> > > wrote: >> > > >> > >> Hello everyone, >> > >> >> > >> I know that log4j-v1 was announced as end of life back in 2015 and >> that >> > all >> > >> effort is on log4j2. However, I would very much like to see a new >> > version, >> > >> presumably it would be called 1.2.18, which addresses a security >> > >> vulnerability. Is this right place to discuss this please? >> > >> >> > >> -- >> > >> Regards, >> > >> >> > >> Andrew Marlow >> > >> http://www.andrewpetermarlow.co.uk >> > >> >> > >> > >> > > > -- > Regards, > > Andrew Marlow > http://www.andrewpetermarlow.co.uk > > -- Regards, Andrew Marlow http://www.andrewpetermarlow.co.uk
