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
