You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tika.apache.org by Tim Allison <ta...@apache.org> on 2021/12/16 17:15:43 UTC
Statement on CVE-2021-44228 and Apache Tika
The recently publicized CVE-2021-44228 in log4j2 allows for
unauthenticated remote code execution and has the highest severity
ranking possible. This is a very serious vulnerability. In the
following, we report on our findings and mitigations for the Apache
Tika project.
Apache Tika Version 2.x
Tika 2.x versions 2.0.0-BETA through and including 2.1.0 all use
vulnerable versions of log4j2[1]. We have not put the effort into a
proof of concept to prove that it is vulnerable, but we believe it
would be fairly trivial. On Monday, December 13 we upgraded to log4j
2.15.0 in our main branch and began the release process for Tika
2.2.0. We expect to release Tika 2.2.0 later today.
After we began the release process and after the reports of
CVE-2021-45046, Konstantin Gribov, a Tika PMC member, reviewed our
codebase and determined that risks within our codebase are
negligible[2]. Nevertheless, we plan to release an upgrade that
includes log4j2 2.16.0 in early January, 2022.
Apache Tika versions 1.x
All currently released versions of 1.x rely on the older log4j 1.x
versions which are not vulnerable to CVE-2021-44228. However, given
that log4j 1.x does have a lower severity CVE (CVE-2019-17571) against
it and given that it hit end of life in August 2015, we decided to
make some breaking changes in Tika's 1.x branch and upgrade to log4j2
2.16.0 in the next release (1.28). We have started the release process
for 1.28 today.
Please note:
1. This is a fast moving and dynamic set of vulnerabilities. We will
continue to review new findings and will make updates as appropriate.
2. As a PMC, we have set September 30, 2022 as the EOL for the Tika
1.x branch. We will continue to make security upgrades and releases
for the 1.x branch until then. We do not plan to backport new features
to the 1.x branch. We encourage 1.x users to migrate to 2.x as soon
as possible [3].
3. Parsing untrusted files with non-verified parsers is always
dangerous. This is a challenge not limited to Apache Tika and its
dependencies. We highly encourage as much containment as possible
around file parsing generally. See our wiki on the robustness of Tika
and what we're doing to improve its robustness [4].
Please let us know if you have any questions.
Sincerely,
Tim
16 December 2021, 1715 UTC
[1] In Tika 2.0.0-ALPHA we used the older log4j 1.x which is not
vulnerable to CVE-2021-44228.
[2] https://issues.apache.org/jira/browse/TIKA-3616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17460168#comment-17460168
[3] https://cwiki.apache.org/confluence/display/TIKA/Migrating+to+Tika+2.0.0
[4] https://cwiki.apache.org/confluence/display/TIKA/The+Robustness+of+Apache+Tika
Re: Statement on CVE-2021-44228 and Apache Tika
Posted by Tim Allison <ta...@apache.org>.
It isn't. We're starting the release cycle for 2.2.1 with Log4j 2.16.0
in a few hours. Thank you for update.
On Fri, Dec 17, 2021 at 11:17 AM Cristian Zamfir <cr...@cyberhaven.com> wrote:
>
> Hi, is the lower priority for CVE-2021-45046 still accurate in light of this? https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased
>
> On Thu, Dec 16, 2021 at 6:22 PM Tim Allison <ta...@apache.org> wrote:
>>
>> The recently publicized CVE-2021-44228 in log4j2 allows for
>> unauthenticated remote code execution and has the highest severity
>> ranking possible. This is a very serious vulnerability. In the
>> following, we report on our findings and mitigations for the Apache
>> Tika project.
>>
>> Apache Tika Version 2.x
>> Tika 2.x versions 2.0.0-BETA through and including 2.1.0 all use
>> vulnerable versions of log4j2[1]. We have not put the effort into a
>> proof of concept to prove that it is vulnerable, but we believe it
>> would be fairly trivial. On Monday, December 13 we upgraded to log4j
>> 2.15.0 in our main branch and began the release process for Tika
>> 2.2.0. We expect to release Tika 2.2.0 later today.
>>
>> After we began the release process and after the reports of
>> CVE-2021-45046, Konstantin Gribov, a Tika PMC member, reviewed our
>> codebase and determined that risks within our codebase are
>> negligible[2]. Nevertheless, we plan to release an upgrade that
>> includes log4j2 2.16.0 in early January, 2022.
>>
>> Apache Tika versions 1.x
>> All currently released versions of 1.x rely on the older log4j 1.x
>> versions which are not vulnerable to CVE-2021-44228. However, given
>> that log4j 1.x does have a lower severity CVE (CVE-2019-17571) against
>> it and given that it hit end of life in August 2015, we decided to
>> make some breaking changes in Tika's 1.x branch and upgrade to log4j2
>> 2.16.0 in the next release (1.28). We have started the release process
>> for 1.28 today.
>>
>> Please note:
>>
>> 1. This is a fast moving and dynamic set of vulnerabilities. We will
>> continue to review new findings and will make updates as appropriate.
>>
>> 2. As a PMC, we have set September 30, 2022 as the EOL for the Tika
>> 1.x branch. We will continue to make security upgrades and releases
>> for the 1.x branch until then. We do not plan to backport new features
>> to the 1.x branch. We encourage 1.x users to migrate to 2.x as soon
>> as possible [3].
>>
>> 3. Parsing untrusted files with non-verified parsers is always
>> dangerous. This is a challenge not limited to Apache Tika and its
>> dependencies. We highly encourage as much containment as possible
>> around file parsing generally. See our wiki on the robustness of Tika
>> and what we're doing to improve its robustness [4].
>>
>>
>> Please let us know if you have any questions.
>>
>> Sincerely,
>> Tim
>>
>>
>> 16 December 2021, 1715 UTC
>>
>> [1] In Tika 2.0.0-ALPHA we used the older log4j 1.x which is not
>> vulnerable to CVE-2021-44228.
>>
>> [2] https://issues.apache.org/jira/browse/TIKA-3616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17460168#comment-17460168
>>
>> [3] https://cwiki.apache.org/confluence/display/TIKA/Migrating+to+Tika+2.0.0
>>
>> [4] https://cwiki.apache.org/confluence/display/TIKA/The+Robustness+of+Apache+Tika
Re: Statement on CVE-2021-44228 and Apache Tika
Posted by Tim Allison <ta...@apache.org>.
It isn't. We're starting the release cycle for 2.2.1 with Log4j 2.16.0
in a few hours. Thank you for update.
On Fri, Dec 17, 2021 at 11:17 AM Cristian Zamfir <cr...@cyberhaven.com> wrote:
>
> Hi, is the lower priority for CVE-2021-45046 still accurate in light of this? https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased
>
> On Thu, Dec 16, 2021 at 6:22 PM Tim Allison <ta...@apache.org> wrote:
>>
>> The recently publicized CVE-2021-44228 in log4j2 allows for
>> unauthenticated remote code execution and has the highest severity
>> ranking possible. This is a very serious vulnerability. In the
>> following, we report on our findings and mitigations for the Apache
>> Tika project.
>>
>> Apache Tika Version 2.x
>> Tika 2.x versions 2.0.0-BETA through and including 2.1.0 all use
>> vulnerable versions of log4j2[1]. We have not put the effort into a
>> proof of concept to prove that it is vulnerable, but we believe it
>> would be fairly trivial. On Monday, December 13 we upgraded to log4j
>> 2.15.0 in our main branch and began the release process for Tika
>> 2.2.0. We expect to release Tika 2.2.0 later today.
>>
>> After we began the release process and after the reports of
>> CVE-2021-45046, Konstantin Gribov, a Tika PMC member, reviewed our
>> codebase and determined that risks within our codebase are
>> negligible[2]. Nevertheless, we plan to release an upgrade that
>> includes log4j2 2.16.0 in early January, 2022.
>>
>> Apache Tika versions 1.x
>> All currently released versions of 1.x rely on the older log4j 1.x
>> versions which are not vulnerable to CVE-2021-44228. However, given
>> that log4j 1.x does have a lower severity CVE (CVE-2019-17571) against
>> it and given that it hit end of life in August 2015, we decided to
>> make some breaking changes in Tika's 1.x branch and upgrade to log4j2
>> 2.16.0 in the next release (1.28). We have started the release process
>> for 1.28 today.
>>
>> Please note:
>>
>> 1. This is a fast moving and dynamic set of vulnerabilities. We will
>> continue to review new findings and will make updates as appropriate.
>>
>> 2. As a PMC, we have set September 30, 2022 as the EOL for the Tika
>> 1.x branch. We will continue to make security upgrades and releases
>> for the 1.x branch until then. We do not plan to backport new features
>> to the 1.x branch. We encourage 1.x users to migrate to 2.x as soon
>> as possible [3].
>>
>> 3. Parsing untrusted files with non-verified parsers is always
>> dangerous. This is a challenge not limited to Apache Tika and its
>> dependencies. We highly encourage as much containment as possible
>> around file parsing generally. See our wiki on the robustness of Tika
>> and what we're doing to improve its robustness [4].
>>
>>
>> Please let us know if you have any questions.
>>
>> Sincerely,
>> Tim
>>
>>
>> 16 December 2021, 1715 UTC
>>
>> [1] In Tika 2.0.0-ALPHA we used the older log4j 1.x which is not
>> vulnerable to CVE-2021-44228.
>>
>> [2] https://issues.apache.org/jira/browse/TIKA-3616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17460168#comment-17460168
>>
>> [3] https://cwiki.apache.org/confluence/display/TIKA/Migrating+to+Tika+2.0.0
>>
>> [4] https://cwiki.apache.org/confluence/display/TIKA/The+Robustness+of+Apache+Tika
Re: Statement on CVE-2021-44228 and Apache Tika
Posted by Cristian Zamfir <cr...@cyberhaven.com>.
Hi, is the lower priority for CVE-2021-45046 still accurate in light of
this?
https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased
On Thu, Dec 16, 2021 at 6:22 PM Tim Allison <ta...@apache.org> wrote:
> The recently publicized CVE-2021-44228 in log4j2 allows for
> unauthenticated remote code execution and has the highest severity
> ranking possible. This is a very serious vulnerability. In the
> following, we report on our findings and mitigations for the Apache
> Tika project.
>
> Apache Tika Version 2.x
> Tika 2.x versions 2.0.0-BETA through and including 2.1.0 all use
> vulnerable versions of log4j2[1]. We have not put the effort into a
> proof of concept to prove that it is vulnerable, but we believe it
> would be fairly trivial. On Monday, December 13 we upgraded to log4j
> 2.15.0 in our main branch and began the release process for Tika
> 2.2.0. We expect to release Tika 2.2.0 later today.
>
> After we began the release process and after the reports of
> CVE-2021-45046, Konstantin Gribov, a Tika PMC member, reviewed our
> codebase and determined that risks within our codebase are
> negligible[2]. Nevertheless, we plan to release an upgrade that
> includes log4j2 2.16.0 in early January, 2022.
>
> Apache Tika versions 1.x
> All currently released versions of 1.x rely on the older log4j 1.x
> versions which are not vulnerable to CVE-2021-44228. However, given
> that log4j 1.x does have a lower severity CVE (CVE-2019-17571) against
> it and given that it hit end of life in August 2015, we decided to
> make some breaking changes in Tika's 1.x branch and upgrade to log4j2
> 2.16.0 in the next release (1.28). We have started the release process
> for 1.28 today.
>
> Please note:
>
> 1. This is a fast moving and dynamic set of vulnerabilities. We will
> continue to review new findings and will make updates as appropriate.
>
> 2. As a PMC, we have set September 30, 2022 as the EOL for the Tika
> 1.x branch. We will continue to make security upgrades and releases
> for the 1.x branch until then. We do not plan to backport new features
> to the 1.x branch. We encourage 1.x users to migrate to 2.x as soon
> as possible [3].
>
> 3. Parsing untrusted files with non-verified parsers is always
> dangerous. This is a challenge not limited to Apache Tika and its
> dependencies. We highly encourage as much containment as possible
> around file parsing generally. See our wiki on the robustness of Tika
> and what we're doing to improve its robustness [4].
>
>
> Please let us know if you have any questions.
>
> Sincerely,
> Tim
>
>
> 16 December 2021, 1715 UTC
>
> [1] In Tika 2.0.0-ALPHA we used the older log4j 1.x which is not
> vulnerable to CVE-2021-44228.
>
> [2]
> https://issues.apache.org/jira/browse/TIKA-3616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17460168#comment-17460168
>
> [3]
> https://cwiki.apache.org/confluence/display/TIKA/Migrating+to+Tika+2.0.0
>
> [4]
> https://cwiki.apache.org/confluence/display/TIKA/The+Robustness+of+Apache+Tika
>
Re: Statement on CVE-2021-44228 and Apache Tika
Posted by Cristian Zamfir <cr...@cyberhaven.com>.
Hi, is the lower priority for CVE-2021-45046 still accurate in light of
this?
https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased
On Thu, Dec 16, 2021 at 6:22 PM Tim Allison <ta...@apache.org> wrote:
> The recently publicized CVE-2021-44228 in log4j2 allows for
> unauthenticated remote code execution and has the highest severity
> ranking possible. This is a very serious vulnerability. In the
> following, we report on our findings and mitigations for the Apache
> Tika project.
>
> Apache Tika Version 2.x
> Tika 2.x versions 2.0.0-BETA through and including 2.1.0 all use
> vulnerable versions of log4j2[1]. We have not put the effort into a
> proof of concept to prove that it is vulnerable, but we believe it
> would be fairly trivial. On Monday, December 13 we upgraded to log4j
> 2.15.0 in our main branch and began the release process for Tika
> 2.2.0. We expect to release Tika 2.2.0 later today.
>
> After we began the release process and after the reports of
> CVE-2021-45046, Konstantin Gribov, a Tika PMC member, reviewed our
> codebase and determined that risks within our codebase are
> negligible[2]. Nevertheless, we plan to release an upgrade that
> includes log4j2 2.16.0 in early January, 2022.
>
> Apache Tika versions 1.x
> All currently released versions of 1.x rely on the older log4j 1.x
> versions which are not vulnerable to CVE-2021-44228. However, given
> that log4j 1.x does have a lower severity CVE (CVE-2019-17571) against
> it and given that it hit end of life in August 2015, we decided to
> make some breaking changes in Tika's 1.x branch and upgrade to log4j2
> 2.16.0 in the next release (1.28). We have started the release process
> for 1.28 today.
>
> Please note:
>
> 1. This is a fast moving and dynamic set of vulnerabilities. We will
> continue to review new findings and will make updates as appropriate.
>
> 2. As a PMC, we have set September 30, 2022 as the EOL for the Tika
> 1.x branch. We will continue to make security upgrades and releases
> for the 1.x branch until then. We do not plan to backport new features
> to the 1.x branch. We encourage 1.x users to migrate to 2.x as soon
> as possible [3].
>
> 3. Parsing untrusted files with non-verified parsers is always
> dangerous. This is a challenge not limited to Apache Tika and its
> dependencies. We highly encourage as much containment as possible
> around file parsing generally. See our wiki on the robustness of Tika
> and what we're doing to improve its robustness [4].
>
>
> Please let us know if you have any questions.
>
> Sincerely,
> Tim
>
>
> 16 December 2021, 1715 UTC
>
> [1] In Tika 2.0.0-ALPHA we used the older log4j 1.x which is not
> vulnerable to CVE-2021-44228.
>
> [2]
> https://issues.apache.org/jira/browse/TIKA-3616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17460168#comment-17460168
>
> [3]
> https://cwiki.apache.org/confluence/display/TIKA/Migrating+to+Tika+2.0.0
>
> [4]
> https://cwiki.apache.org/confluence/display/TIKA/The+Robustness+of+Apache+Tika
>