You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Andy Seaborne <an...@apache.org> on 2021/12/13 17:30:11 UTC
[ANN] Apache Jena 4.3.1
The Apache Jena development community is pleased to
announce the release of Apache Jena 4.3.1.
This release updates the version of log4j2 used in Fuseki.
Fuseki users should upgrade as soon as possible.
Uses of Jena libraries should to check their application logging
dependences and update as necessary.
== Changes
JENA-2211: Upgrade to Log4j2 2.15.0
JENA-2209, JENA-2210: xloader improvements
JENA-2207: Fix for SERVICE
== Obtaining Apache Jena 4.3.1
* Via central.maven.org
The main jars and their dependencies can used with:
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>apache-jena-libs</artifactId>
<type>pom</type>
<version>4.3.1</version>
</dependency>
Full details of all maven artifacts are described at:
http://jena.apache.org/download/maven.html
* As binary downloads
Apache Jena libraries are available as a binary distribution of
libraries. For details of a global mirror copy of Jena binaries please see:
http://jena.apache.org/download/
* Source code for the release
The signed source code of this release is available at:
http://www.apache.org/dist/jena/source/
and the signed master source for all Apache Jena releases is available
at: http://archive.apache.org/dist/jena/
== Contributing
If you would like to help out, a good place to look is the list of
unresolved JIRA at:
http://s.apache.org/jena-jira-current
or review pull requests at
https://github.com/apache/jena/pulls
or drop into the dev@ list.
We use github pull requests and other ways for accepting code:
https://github.com/apache/jena/blob/master/CONTRIBUTING.md
Re: Release 4.3.2 -- was:[ANN] Apache Jena 4.3.1
Posted by Andy Seaborne <an...@apache.org>.
Part 3.
https://logging.apache.org/log4j/2.x/security.html
https://nvd.nist.gov/vuln/detail/CVE-2021-45105
Fuseki does not have a pattern with with a context Lookup (for example,
$${ctx:loginId}) or indeed any ${} lookup.
Fuseki:
[%d{yyyy-MM-dd HH:mm:ss}] %-10c{1} %-5p %m%n
Command line tools
%d{HH:mm:ss} %-5p %-15c{1} :: %m%n"
Andy
Don't be surprised if there are more.
When Jackson JSON data binding was found to have vulnerabilities a few
years ago, there were a number of CVEs as it got a lot of attention.
Also expect nearby projects to get attention. Logback has registered a
CVE (it's a remote code JNDI attack) but not from outside text. They
have removed the "we're not affected text" from the home page.
On 18/12/2021 00:04, Andy Seaborne wrote:
> Hi Andrew,
>
> Thank you for letting us know.
>
> Rob spotted that the log4j project security page has been updated:
>
> https://logging.apache.org/log4j/2.x/security.html
>
> revising it to critical 9/10
>
> We've already started a vote on Jena 4.3.2 with log4j 2.16.0.
>
> https://lists.apache.org/thread/tj0mo24g8jvfr02964nww96ckfvxnhjm
>
> (we are not bypassing the need to have the proper votes for a release)
>
> Very few changes in 4.3.2 but - bonus prize! - JENA-2215 (make sure
> logging is in the war file) is included.
>
> Andy
>
> On 17/12/2021 21:33, Andrii Berezovskyi wrote:
>> Hello Andy,
>>
>> I hate to be the bearer of bad news, but in a recent discussion on
>> Lobsters [1] it was brought to my attention that there apparently
>> exists a bypass [2] of the fix in 2.15.0 that brings back the RCE. To
>> be clear, the new exploit no longer requires fiddling with the Thread
>> Context Map settings. The CVE page [3] now says "This vulnerability
>> has been modified since it was last analyzed by the NVD. It is
>> awaiting reanalysis which may result in further changes to the
>> information provided.", which means that the original score 3.7/10 no
>> longer applies to the new CVE.
>>
>> Harri, the WAR file of the 4.3.1 was missing log4j JARs and I had
>> success simply placing 2.16.0 JARs myself. You should be able to use
>> that as a temporary mitigation until the new version comes out.
>>
>> /Andrew
>>
>> [1]:
>> https://lobste.rs/s/ccc9tu/patch_fixing_critical_log4j_0_day_has_its#c_c2syst
>>
>> [2]:
>> https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/#update-the-localhost-bypass-was-discovered
>>
>> [3]: https://nvd.nist.gov/vuln/detail/CVE-2021-45046
>
Release 4.3.2 -- was:[ANN] Apache Jena 4.3.1
Posted by Andy Seaborne <an...@apache.org>.
Hi Andrew,
Thank you for letting us know.
Rob spotted that the log4j project security page has been updated:
https://logging.apache.org/log4j/2.x/security.html
revising it to critical 9/10
We've already started a vote on Jena 4.3.2 with log4j 2.16.0.
https://lists.apache.org/thread/tj0mo24g8jvfr02964nww96ckfvxnhjm
(we are not bypassing the need to have the proper votes for a release)
Very few changes in 4.3.2 but - bonus prize! - JENA-2215 (make sure
logging is in the war file) is included.
Andy
On 17/12/2021 21:33, Andrii Berezovskyi wrote:
> Hello Andy,
>
> I hate to be the bearer of bad news, but in a recent discussion on Lobsters [1] it was brought to my attention that there apparently exists a bypass [2] of the fix in 2.15.0 that brings back the RCE. To be clear, the new exploit no longer requires fiddling with the Thread Context Map settings. The CVE page [3] now says "This vulnerability has been modified since it was last analyzed by the NVD. It is awaiting reanalysis which may result in further changes to the information provided.", which means that the original score 3.7/10 no longer applies to the new CVE.
>
> Harri, the WAR file of the 4.3.1 was missing log4j JARs and I had success simply placing 2.16.0 JARs myself. You should be able to use that as a temporary mitigation until the new version comes out.
>
> /Andrew
>
> [1]: https://lobste.rs/s/ccc9tu/patch_fixing_critical_log4j_0_day_has_its#c_c2syst
> [2]: https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/#update-the-localhost-bypass-was-discovered
> [3]: https://nvd.nist.gov/vuln/detail/CVE-2021-45046
Re: [ANN] Apache Jena 4.3.1
Posted by Andrii Berezovskyi <an...@kth.se>.
Hello Andy,
I hate to be the bearer of bad news, but in a recent discussion on Lobsters [1] it was brought to my attention that there apparently exists a bypass [2] of the fix in 2.15.0 that brings back the RCE. To be clear, the new exploit no longer requires fiddling with the Thread Context Map settings. The CVE page [3] now says "This vulnerability has been modified since it was last analyzed by the NVD. It is awaiting reanalysis which may result in further changes to the information provided.", which means that the original score 3.7/10 no longer applies to the new CVE.
Harri, the WAR file of the 4.3.1 was missing log4j JARs and I had success simply placing 2.16.0 JARs myself. You should be able to use that as a temporary mitigation until the new version comes out.
/Andrew
[1]: https://lobste.rs/s/ccc9tu/patch_fixing_critical_log4j_0_day_has_its#c_c2syst
[2]: https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/#update-the-localhost-bypass-was-discovered
[3]: https://nvd.nist.gov/vuln/detail/CVE-2021-45046
On 2021-12-15, 15:36, "Andy Seaborne" <an...@apache.org> wrote:
On 15/12/2021 13:44, Harri Kiiskinen wrote:
> Hi,
See
https://blogs.apache.org/security/
>
> it is possible that our university IT service may yet choose to be
> strict about this and require 2.16.0 from all services open to public,
The PMC are all volunteers.
This CVE hasn't been scored by NVD yet.
This CVE requires local access to enable features.
Many systems use log4j1 that has CVE-2019-17571 (in a component that
isn't necessarily used). Log4j 1.x is EOL since 2015.
When Jackson JSON has a serious flaws a few years ago, it was followed
by a number of CVEs as people looked hard at it.
> which would be bothersome four our projects in case Jena stays with
> 2.15.0. I guess similar situations might exist elsewhere; but perhaps
> this is not a question of days, as it was with the previous CVE, since
> this is not quite as severe.
Fuseki uses log4j in default configuration.
See the CVE details.
> My point: I may need to be able to show Jena is using 2.16.0 to be able
> to run our servers at some point.
JENA-2214 - already done.
The Apache Foundation produces source code.
Security is one of the reasons for this.
Binaries are a convenience.
Take the Jena source release, change the log4j version in the top POM.
Build.
Andy
>
> Best,
>
> Harri Kiiskinen
>
>
>
> On 15.12.2021 12.23, Andy Seaborne wrote:
>> On 14/12/2021 20:51, Brandon Sara wrote:
>>> Should we expect another release (like version 4.3.2) given Log4J
>>> updating to 2.16.0 in response to this other CVE:
>>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-45046?
>>
>> Going to the link to the log4j security page, the log4j team rates it
>> as "moderate" and says it's denial-of-service attack, not code
>> injection unlike 44228.
>>
>> Fuseki uses log4j in default configuration.
>> Fuseki uses logging via slf4j.
>> Fuseki does not use log4j ThreadContext.
>> Fuseki does not use %X, %mdc, or %MDC.
>>
>> The Fuseki logging built-in and default pattern uses plain %m in the
>> pattern:
>>
>> [%d{yyyy-MM-dd HH:mm:ss}] %-10c{1} %-5p %m%n
>>
>> although the user can change the log4j2 configuration to be a
>> non-default configurations and also set their own logging pattern
>> locally. that's outside the distributed Fuseki binaries.
>>
>> Personal opinion: I don't see a need for 4.3.2.
>>
>> Andy
>
>
docker-file for jena-fuseki 4.3.1
Posted by ja...@kolumbus.fi.
Hi,
found a docker-file for jena-fuseki 4.3.1 from
https://repo1.maven.org/maven2/org/apache/jena/jena-fuseki-docker/4.3.1/
It is without UI. Would there be coming a Dockerfile with UI, too ?
Br Jaana
Re: [ANN] Apache Jena 4.3.1
Posted by Andy Seaborne <an...@apache.org>.
On 15/12/2021 13:44, Harri Kiiskinen wrote:
> Hi,
See
https://blogs.apache.org/security/
>
> it is possible that our university IT service may yet choose to be
> strict about this and require 2.16.0 from all services open to public,
The PMC are all volunteers.
This CVE hasn't been scored by NVD yet.
This CVE requires local access to enable features.
Many systems use log4j1 that has CVE-2019-17571 (in a component that
isn't necessarily used). Log4j 1.x is EOL since 2015.
When Jackson JSON has a serious flaws a few years ago, it was followed
by a number of CVEs as people looked hard at it.
> which would be bothersome four our projects in case Jena stays with
> 2.15.0. I guess similar situations might exist elsewhere; but perhaps
> this is not a question of days, as it was with the previous CVE, since
> this is not quite as severe.
Fuseki uses log4j in default configuration.
See the CVE details.
> My point: I may need to be able to show Jena is using 2.16.0 to be able
> to run our servers at some point.
JENA-2214 - already done.
The Apache Foundation produces source code.
Security is one of the reasons for this.
Binaries are a convenience.
Take the Jena source release, change the log4j version in the top POM.
Build.
Andy
>
> Best,
>
> Harri Kiiskinen
>
>
>
> On 15.12.2021 12.23, Andy Seaborne wrote:
>> On 14/12/2021 20:51, Brandon Sara wrote:
>>> Should we expect another release (like version 4.3.2) given Log4J
>>> updating to 2.16.0 in response to this other CVE:
>>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-45046?
>>
>> Going to the link to the log4j security page, the log4j team rates it
>> as "moderate" and says it's denial-of-service attack, not code
>> injection unlike 44228.
>>
>> Fuseki uses log4j in default configuration.
>> Fuseki uses logging via slf4j.
>> Fuseki does not use log4j ThreadContext.
>> Fuseki does not use %X, %mdc, or %MDC.
>>
>> The Fuseki logging built-in and default pattern uses plain %m in the
>> pattern:
>>
>> [%d{yyyy-MM-dd HH:mm:ss}] %-10c{1} %-5p %m%n
>>
>> although the user can change the log4j2 configuration to be a
>> non-default configurations and also set their own logging pattern
>> locally. that's outside the distributed Fuseki binaries.
>>
>> Personal opinion: I don't see a need for 4.3.2.
>>
>> Andy
>
>
Re: [ANN] Apache Jena 4.3.1
Posted by Harri Kiiskinen <ha...@utu.fi>.
Hi,
it is possible that our university IT service may yet choose to be
strict about this and require 2.16.0 from all services open to public,
which would be bothersome four our projects in case Jena stays with
2.15.0. I guess similar situations might exist elsewhere; but perhaps
this is not a question of days, as it was with the previous CVE, since
this is not quite as severe.
My point: I may need to be able to show Jena is using 2.16.0 to be able
to run our servers at some point.
Best,
Harri Kiiskinen
On 15.12.2021 12.23, Andy Seaborne wrote:
> On 14/12/2021 20:51, Brandon Sara wrote:
>> Should we expect another release (like version 4.3.2) given Log4J
>> updating to 2.16.0 in response to this other CVE:
>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-45046?
>
> Going to the link to the log4j security page, the log4j team rates it as
> "moderate" and says it's denial-of-service attack, not code injection
> unlike 44228.
>
> Fuseki uses log4j in default configuration.
> Fuseki uses logging via slf4j.
> Fuseki does not use log4j ThreadContext.
> Fuseki does not use %X, %mdc, or %MDC.
>
> The Fuseki logging built-in and default pattern uses plain %m in the
> pattern:
>
> [%d{yyyy-MM-dd HH:mm:ss}] %-10c{1} %-5p %m%n
>
> although the user can change the log4j2 configuration to be a
> non-default configurations and also set their own logging pattern
> locally. that's outside the distributed Fuseki binaries.
>
> Personal opinion: I don't see a need for 4.3.2.
>
> Andy
--
Tutkijatohtori / post-doctoral researcher
Viral Culture in the Early Nineteenth-Century Europe (ViCE)
Movie Making Finland: Finnish fiction films as audiovisual big data,
1907–2017 (MoMaF)
Turun yliopisto / University of Turku
Re: [ANN] Apache Jena 4.3.1
Posted by Andy Seaborne <an...@apache.org>.
On 14/12/2021 20:51, Brandon Sara wrote:
> Should we expect another release (like version 4.3.2) given Log4J updating to 2.16.0 in response to this other CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-45046?
Going to the link to the log4j security page, the log4j team rates it as
"moderate" and says it's denial-of-service attack, not code injection
unlike 44228.
Fuseki uses log4j in default configuration.
Fuseki uses logging via slf4j.
Fuseki does not use log4j ThreadContext.
Fuseki does not use %X, %mdc, or %MDC.
The Fuseki logging built-in and default pattern uses plain %m in the
pattern:
[%d{yyyy-MM-dd HH:mm:ss}] %-10c{1} %-5p %m%n
although the user can change the log4j2 configuration to be a
non-default configurations and also set their own logging pattern
locally. that's outside the distributed Fuseki binaries.
Personal opinion: I don't see a need for 4.3.2.
Andy
Re: [ANN] Apache Jena 4.3.1
Posted by Brandon Sara <br...@collectivemedicaltech.com.INVALID>.
Should we expect another release (like version 4.3.2) given Log4J updating to 2.16.0 in response to this other CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-45046?
No PHI in Email: PointClickCare and Collective Medical, A PointClickCare Company, policies prohibit sending protected health information (PHI) by email, which may violate regulatory requirements. If sending PHI is necessary, please contact the sender for secure delivery instructions.
Confidentiality Notice: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.