You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2021/12/14 09:51:56 UTC
[SECURITY] Apache Tomcat and CVE-2021-44228 (Log4j vulnerability)
The following represents the current understanding of the Apache Tomcat
security team at the time this announcement was issued. There is a lot
of security research being focussed on log4j2 at the moment and it is
probable that additional information will emerge.
Currently supported Tomcat versions (8.5.x, 9.0.x, 10.0.x and 10.1.x)
have no dependency on any version of log4j.
Web applications deployed on Tomcat may have a dependency on log4j. You
should seek support from your application vendors on how best to address
this vulnerability.
Tomcat 8.0.x and earlier as well as the first few releases of 8.5.x
(8.5.3 and earlier) provided optional support for switching Tomcat's
internal logging to log4j 1.x. Anyone one using these very old (5+
years), unsupported versions of Tomcat that switched to using log4j 1.x
may need to address this vulnerability as log4j 1.x may be affected in
some (probably rarely used) configurations. Regardless, they'll need to
address the Tomcat vulnerabilities that have been made public in those
5+ years.
It is possible to configure Tomcat to use log4j 2.x for Tomcat's
internal logging. This requires explicit configuration and the addition
of the log4j 2.x library. Anyone who has switched Tomcat's internal
logging to log4j 2.x is likely to need to address this vulnerability.
In most cases, disabling the problematic feature will be the simplest
solution. Exactly how to do that depends on the exact version of log4j2
being used. Details are provided on the log4j2 security page [1].
If not already subscribed, you may wish to follow the ASF announcements
mailing list [2] where any significant updates from the logging project
will be posted.
If you have any questions regarding this issue or how to mitigate it,
please direct them to the Apache Tomcat Users mailing list [3].
The Apache Tomcat Security Team
[1] https://logging.apache.org/log4j/2.x/security.html
[2] https://www.apache.org/foundation/mailinglists.html#foundation-announce
[3] https://tomcat.apache.org/lists.html#tomcat-users
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] Apache Tomcat and CVE-2021-44228 (Log4j vulnerability) (also CVE-2021-45046 and CVE-2021-4104)
Posted by Rainer Jung <ra...@kippdata.de>.
LGTM!
Am 17.12.2021 um 11:43 schrieb Mark Thomas:
> Unless there are objections, I'm planning on sending a follow-up to the
> original email to state (in summary)
> - more CVEs have been identified
> - given the amount of attention focussed on this there may be further CVEs
> - previous advice regarding the impact for Tomcat is essentially unchanged
> - follow the log4j advice on mitigation which is changing over time -
> mitigation via configuration is unlikely to be sufficient
> - monitor log4j for further updates
>
> Mark
>
> 16 Dec 2021 22:49:59 Rainer Jung <ra...@kippdata.de>:
>
>> I guess people here are aware of it, but for the sake of even mire
>> completeness: the official security document for log4j2 has been amended:
>>
>> - currently only version 2.16.0 and, if one absolutely needs to run on
>> Java 7, version 2.12.2 really fix the problems. The originally
>> suggested version 2.15.0 does not suffice. To reduce confusion:
>> although the version number 2.12.2 is much smaller than 2.16.0, it is
>> a new backport of the fix to the latest version, that was compatible
>> with Java 7.
>>
>> - the system property / environment variable workaround to suppress
>> message lookups is no longer recommended, because it is incomplete
>>
>> - if one absolutely can not update or not fast enough, removing the
>> Log4j JndiLookup class from the log4j core jar file and all other
>> places where it might have beend deployed in an application is still
>> assumed to be a good workaround. Plus restart of course.
>>
>> Best regards,
>>
>> Rainer
>>
>> Am 16.12.2021 um 17:03 schrieb Christopher Schultz:
>>> Mark,
>>> Adding that the below message also applies for both CVE-2021-45046
>>> and CVE-2021-4104 as well as the originally-mentioned 2021-44228, for
>>> completeness.
>>> -chris
>>> On 12/14/21 04:51, Mark Thomas wrote:
>>>> The following represents the current understanding of the Apache
>>>> Tomcat security team at the time this announcement was issued. There
>>>> is a lot of security research being focussed on log4j2 at the moment
>>>> and it is probable that additional information will emerge.
>>>>
>>>> Currently supported Tomcat versions (8.5.x, 9.0.x, 10.0.x and
>>>> 10.1.x) have no dependency on any version of log4j.
>>>>
>>>> Web applications deployed on Tomcat may have a dependency on log4j.
>>>> You should seek support from your application vendors on how best to
>>>> address this vulnerability.
>>>>
>>>> Tomcat 8.0.x and earlier as well as the first few releases of 8.5.x
>>>> (8.5.3 and earlier) provided optional support for switching Tomcat's
>>>> internal logging to log4j 1.x. Anyone one using these very old (5+
>>>> years), unsupported versions of Tomcat that switched to using log4j
>>>> 1.x may need to address this vulnerability as log4j 1.x may be
>>>> affected in some (probably rarely used) configurations. Regardless,
>>>> they'll need to address the Tomcat vulnerabilities that have been
>>>> made public in those 5+ years.
>>>>
>>>> It is possible to configure Tomcat to use log4j 2.x for Tomcat's
>>>> internal logging. This requires explicit configuration and the
>>>> addition of the log4j 2.x library. Anyone who has switched Tomcat's
>>>> internal logging to log4j 2.x is likely to need to address this
>>>> vulnerability.
>>>>
>>>> In most cases, disabling the problematic feature will be the
>>>> simplest solution. Exactly how to do that depends on the exact
>>>> version of log4j2 being used. Details are provided on the log4j2
>>>> security page [1].
>>>>
>>>> If not already subscribed, you may wish to follow the ASF
>>>> announcements mailing list [2] where any significant updates from
>>>> the logging project will be posted.
>>>>
>>>> If you have any questions regarding this issue or how to mitigate
>>>> it, please direct them to the Apache Tomcat Users mailing list [3].
>>>>
>>>> The Apache Tomcat Security Team
>>>>
>>>>
>>>> [1] https://logging.apache.org/log4j/2.x/security.html
>>>>
>>>> [2]
>>>> https://www.apache.org/foundation/mailinglists.html#foundation-announce
>>>>
>>>> [3] https://tomcat.apache.org/lists.html#tomcat-users
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [SECURITY] Apache Tomcat and CVE-2021-44228 (Log4j vulnerability) (also CVE-2021-45046 and CVE-2021-4104)
Posted by Mark Thomas <ma...@apache.org>.
Unless there are objections, I'm planning on sending a follow-up to the
original email to state (in summary)
- more CVEs have been identified
- given the amount of attention focussed on this there may be further
CVEs
- previous advice regarding the impact for Tomcat is essentially
unchanged
- follow the log4j advice on mitigation which is changing over time -
mitigation via configuration is unlikely to be sufficient
- monitor log4j for further updates
Mark
16 Dec 2021 22:49:59 Rainer Jung <ra...@kippdata.de>:
> I guess people here are aware of it, but for the sake of even mire
> completeness: the official security document for log4j2 has been
> amended:
>
> - currently only version 2.16.0 and, if one absolutely needs to run on
> Java 7, version 2.12.2 really fix the problems. The originally
> suggested version 2.15.0 does not suffice. To reduce confusion:
> although the version number 2.12.2 is much smaller than 2.16.0, it is a
> new backport of the fix to the latest version, that was compatible with
> Java 7.
>
> - the system property / environment variable workaround to suppress
> message lookups is no longer recommended, because it is incomplete
>
> - if one absolutely can not update or not fast enough, removing the
> Log4j JndiLookup class from the log4j core jar file and all other
> places where it might have beend deployed in an application is still
> assumed to be a good workaround. Plus restart of course.
>
> Best regards,
>
> Rainer
>
> Am 16.12.2021 um 17:03 schrieb Christopher Schultz:
>> Mark,
>> Adding that the below message also applies for both CVE-2021-45046 and
>> CVE-2021-4104 as well as the originally-mentioned 2021-44228, for
>> completeness.
>> -chris
>> On 12/14/21 04:51, Mark Thomas wrote:
>>> The following represents the current understanding of the Apache
>>> Tomcat security team at the time this announcement was issued. There
>>> is a lot of security research being focussed on log4j2 at the moment
>>> and it is probable that additional information will emerge.
>>>
>>> Currently supported Tomcat versions (8.5.x, 9.0.x, 10.0.x and 10.1.x)
>>> have no dependency on any version of log4j.
>>>
>>> Web applications deployed on Tomcat may have a dependency on log4j.
>>> You should seek support from your application vendors on how best to
>>> address this vulnerability.
>>>
>>> Tomcat 8.0.x and earlier as well as the first few releases of 8.5.x
>>> (8.5.3 and earlier) provided optional support for switching Tomcat's
>>> internal logging to log4j 1.x. Anyone one using these very old (5+
>>> years), unsupported versions of Tomcat that switched to using log4j
>>> 1.x may need to address this vulnerability as log4j 1.x may be
>>> affected in some (probably rarely used) configurations. Regardless,
>>> they'll need to address the Tomcat vulnerabilities that have been
>>> made public in those 5+ years.
>>>
>>> It is possible to configure Tomcat to use log4j 2.x for Tomcat's
>>> internal logging. This requires explicit configuration and the
>>> addition of the log4j 2.x library. Anyone who has switched Tomcat's
>>> internal logging to log4j 2.x is likely to need to address this
>>> vulnerability.
>>>
>>> In most cases, disabling the problematic feature will be the simplest
>>> solution. Exactly how to do that depends on the exact version of
>>> log4j2 being used. Details are provided on the log4j2 security page
>>> [1].
>>>
>>> If not already subscribed, you may wish to follow the ASF
>>> announcements mailing list [2] where any significant updates from the
>>> logging project will be posted.
>>>
>>> If you have any questions regarding this issue or how to mitigate it,
>>> please direct them to the Apache Tomcat Users mailing list [3].
>>>
>>> The Apache Tomcat Security Team
>>>
>>>
>>> [1] https://logging.apache.org/log4j/2.x/security.html
>>>
>>> [2]
>>> https://www.apache.org/foundation/mailinglists.html#foundation-announce
>>>
>>> [3] https://tomcat.apache.org/lists.html#tomcat-users
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [SECURITY] Apache Tomcat and CVE-2021-44228 (Log4j vulnerability) (also CVE-2021-45046 and CVE-2021-4104)
Posted by Rainer Jung <ra...@kippdata.de>.
I guess people here are aware of it, but for the sake of even mire
completeness: the official security document for log4j2 has been amended:
- currently only version 2.16.0 and, if one absolutely needs to run on
Java 7, version 2.12.2 really fix the problems. The originally suggested
version 2.15.0 does not suffice. To reduce confusion: although the
version number 2.12.2 is much smaller than 2.16.0, it is a new backport
of the fix to the latest version, that was compatible with Java 7.
- the system property / environment variable workaround to suppress
message lookups is no longer recommended, because it is incomplete
- if one absolutely can not update or not fast enough, removing the
Log4j JndiLookup class from the log4j core jar file and all other places
where it might have beend deployed in an application is still assumed to
be a good workaround. Plus restart of course.
Best regards,
Rainer
Am 16.12.2021 um 17:03 schrieb Christopher Schultz:
> Mark,
>
> Adding that the below message also applies for both CVE-2021-45046 and
> CVE-2021-4104 as well as the originally-mentioned 2021-44228, for
> completeness.
>
> -chris
>
> On 12/14/21 04:51, Mark Thomas wrote:
>> The following represents the current understanding of the Apache
>> Tomcat security team at the time this announcement was issued. There
>> is a lot of security research being focussed on log4j2 at the moment
>> and it is probable that additional information will emerge.
>>
>> Currently supported Tomcat versions (8.5.x, 9.0.x, 10.0.x and 10.1.x)
>> have no dependency on any version of log4j.
>>
>> Web applications deployed on Tomcat may have a dependency on log4j.
>> You should seek support from your application vendors on how best to
>> address this vulnerability.
>>
>> Tomcat 8.0.x and earlier as well as the first few releases of 8.5.x
>> (8.5.3 and earlier) provided optional support for switching Tomcat's
>> internal logging to log4j 1.x. Anyone one using these very old (5+
>> years), unsupported versions of Tomcat that switched to using log4j
>> 1.x may need to address this vulnerability as log4j 1.x may be
>> affected in some (probably rarely used) configurations. Regardless,
>> they'll need to address the Tomcat vulnerabilities that have been made
>> public in those 5+ years.
>>
>> It is possible to configure Tomcat to use log4j 2.x for Tomcat's
>> internal logging. This requires explicit configuration and the
>> addition of the log4j 2.x library. Anyone who has switched Tomcat's
>> internal logging to log4j 2.x is likely to need to address this
>> vulnerability.
>>
>> In most cases, disabling the problematic feature will be the simplest
>> solution. Exactly how to do that depends on the exact version of
>> log4j2 being used. Details are provided on the log4j2 security page [1].
>>
>> If not already subscribed, you may wish to follow the ASF
>> announcements mailing list [2] where any significant updates from the
>> logging project will be posted.
>>
>> If you have any questions regarding this issue or how to mitigate it,
>> please direct them to the Apache Tomcat Users mailing list [3].
>>
>> The Apache Tomcat Security Team
>>
>>
>> [1] https://logging.apache.org/log4j/2.x/security.html
>>
>> [2]
>> https://www.apache.org/foundation/mailinglists.html#foundation-announce
>>
>> [3] https://tomcat.apache.org/lists.html#tomcat-users
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [SECURITY] Apache Tomcat and CVE-2021-44228 (Log4j vulnerability) (also CVE-2021-45046 and CVE-2021-4104)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
Adding that the below message also applies for both CVE-2021-45046 and
CVE-2021-4104 as well as the originally-mentioned 2021-44228, for
completeness.
-chris
On 12/14/21 04:51, Mark Thomas wrote:
> The following represents the current understanding of the Apache Tomcat
> security team at the time this announcement was issued. There is a lot
> of security research being focussed on log4j2 at the moment and it is
> probable that additional information will emerge.
>
> Currently supported Tomcat versions (8.5.x, 9.0.x, 10.0.x and 10.1.x)
> have no dependency on any version of log4j.
>
> Web applications deployed on Tomcat may have a dependency on log4j. You
> should seek support from your application vendors on how best to address
> this vulnerability.
>
> Tomcat 8.0.x and earlier as well as the first few releases of 8.5.x
> (8.5.3 and earlier) provided optional support for switching Tomcat's
> internal logging to log4j 1.x. Anyone one using these very old (5+
> years), unsupported versions of Tomcat that switched to using log4j 1.x
> may need to address this vulnerability as log4j 1.x may be affected in
> some (probably rarely used) configurations. Regardless, they'll need to
> address the Tomcat vulnerabilities that have been made public in those
> 5+ years.
>
> It is possible to configure Tomcat to use log4j 2.x for Tomcat's
> internal logging. This requires explicit configuration and the addition
> of the log4j 2.x library. Anyone who has switched Tomcat's internal
> logging to log4j 2.x is likely to need to address this vulnerability.
>
> In most cases, disabling the problematic feature will be the simplest
> solution. Exactly how to do that depends on the exact version of log4j2
> being used. Details are provided on the log4j2 security page [1].
>
> If not already subscribed, you may wish to follow the ASF announcements
> mailing list [2] where any significant updates from the logging project
> will be posted.
>
> If you have any questions regarding this issue or how to mitigate it,
> please direct them to the Apache Tomcat Users mailing list [3].
>
> The Apache Tomcat Security Team
>
>
> [1] https://logging.apache.org/log4j/2.x/security.html
>
> [2] https://www.apache.org/foundation/mailinglists.html#foundation-announce
>
> [3] https://tomcat.apache.org/lists.html#tomcat-users
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org