You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Andrew Marlow <ma...@gmail.com> on 2019/12/15 12:01:17 UTC
Is there any chance that there will be a security fix for log4j-v1.2.17?
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
Re: Is there any chance that there will be a security fix for
log4j-v1.2.17?
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Dec 15, 2019, at 3:06 PM, Andrew Marlow <ma...@gmail.com> wrote:
>
> On Sun, 15 Dec 2019 at 21:47, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> 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
Re: Is there any chance that there will be a security fix for log4j-v1.2.17?
Posted by Andrew Marlow <ma...@gmail.com>.
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 <ma...@gmail.com> wrote:
> On Sun, 15 Dec 2019 at 21:47, Gary Gregory <ga...@gmail.com> 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 <ra...@dslextreme.com>
>> 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 <ga...@gmail.com>
>> > 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 <
>> marlow.agents@gmail.com>
>> > > 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
Re: Is there any chance that there will be a security fix for log4j-v1.2.17?
Posted by Andrew Marlow <ma...@gmail.com>.
On Sun, 15 Dec 2019 at 21:47, Gary Gregory <ga...@gmail.com> 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 <ra...@dslextreme.com>
> 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 <ga...@gmail.com>
> > 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 <marlow.agents@gmail.com
> >
> > > 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
Re: Is there any chance that there will be a security fix for log4j-v1.2.17?
Posted by Gary Gregory <ga...@gmail.com>.
Thanks for bring up policy Ralph. For me, a new Log4j 1 release would have
to patch a pretty catastrophic security vulnerability.
As Ralph pointed out, the first thing I would do is migrate to Log4j 2 and
it's support for 1.x.
Gary
On Sun, Dec 15, 2019 at 4:13 PM Ralph Goers <ra...@dslextreme.com>
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 <ga...@gmail.com>
> 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 <ma...@gmail.com>
> > 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
> >>
>
>
Re: Is there any chance that there will be a security fix for log4j-v1.2.17?
Posted by Andrew Marlow <ma...@gmail.com>.
I have submitted a detailed report to the security mailing list and will
keep detail light here. Suffice it to say that I am proposing that the
log4j development team adopt a fix that has already been made and published
by Red Hat. The fix is to version 1.2.17 and I propose it is used to create
version 1.2.18. I give links to the Red Hat security report and the source
code for the fix.
On Sun, 15 Dec 2019 at 21:33, Kate Gray <ka...@aboveandbeyond.aero> wrote:
> Hello,
>
> I'm working on LOG4PHP, but I wanted to comment on the part about the
> ancient JDK. It's a situation I've had to deal with in the past (for
> things like Dell Remote Access).
>
> If there ultimately is a decision to patch the old software, there might
> be a logic in putting together a docker instance (or even a chroot
> package). I've found that it can be a lot easier than keeping a VM
> around. Oracle does have the old JDK 1.2 archive still up on their site,
> and there's a docker base image for Centos 4, which was released back in
> 2005. If the decision was made to release an update, I could likely put
> together an image for whoever wanted to release the update.
>
> Kate
>
> -----Original Message-----
> From: Ralph Goers <ra...@dslextreme.com>
> Sent: December 15, 2019 3:08 PM
> To: dev@logging.apache.org
> Cc: agents@andrewpetermarlow.co.uk
> Subject: Re: Is there any chance that there will be a security fix for
> log4j-v1.2.17?
>
> 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 <ga...@gmail.com>
> 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
> > <ma...@gmail.com>
> > 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
RE: Is there any chance that there will be a security fix for
log4j-v1.2.17?
Posted by Kate Gray <ka...@aboveandbeyond.aero>.
Hello,
I'm working on LOG4PHP, but I wanted to comment on the part about the ancient JDK. It's a situation I've had to deal with in the past (for things like Dell Remote Access).
If there ultimately is a decision to patch the old software, there might be a logic in putting together a docker instance (or even a chroot package). I've found that it can be a lot easier than keeping a VM around. Oracle does have the old JDK 1.2 archive still up on their site, and there's a docker base image for Centos 4, which was released back in 2005. If the decision was made to release an update, I could likely put together an image for whoever wanted to release the update.
Kate
-----Original Message-----
From: Ralph Goers <ra...@dslextreme.com>
Sent: December 15, 2019 3:08 PM
To: dev@logging.apache.org
Cc: agents@andrewpetermarlow.co.uk
Subject: Re: Is there any chance that there will be a security fix for log4j-v1.2.17?
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 <ga...@gmail.com> 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
> <ma...@gmail.com>
> 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
>>
Re: Is there any chance that there will be a security fix for
log4j-v1.2.17?
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ga...@gmail.com> 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 <ma...@gmail.com>
> 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
>>
Re: Is there any chance that there will be a security fix for log4j-v1.2.17?
Posted by Gary Gregory <ga...@gmail.com>.
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 <ma...@gmail.com>
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
>