Upstream has issued an advisory today (December 10): https://www.openwall.com/lists/oss-security/2021/12/10/1 The issue is fixed upstream in 2.15.0. Mageia 8 is also affected.
Status comment: (none) => Fixed upstream in 2.15.0Whiteboard: (none) => MGA8TOO
fixed in mga8/9 src: - log4j-2.13.3-1.1.mga8 rpms: - log4j-jcl-2.13.3-1.1.mga8 - log4j-slf4j-2.13.3-1.1.mga8 - log4j-2.13.3-1.1.mga8 - log4j-javadoc-2.13.3-1.1.mga8
Assignee: java => qa-bugsStatus comment: Fixed upstream in 2.15.0 => (none)CC: (none) => mageia
Given https://developers.slashdot.org/story/21/12/10/2131259/new-zero-day-in-the-log4j-java-library-is-already-being-exploited?utm_source=rss1.0moreanon&utm_medium=feed validating based on clean install over the prior version using qarepo. installing log4j-2.13.3-1.1.mga8.noarch.rpm log4j-slf4j-2.13.3-1.1.mga8.noarch.rpm log4j-jcl-2.13.3-1.1.mga8.noarch.rpm log4j-javadoc-2.13.3-1.1.mga8.noarch.rpm from //root/qa-testing/i586 Preparing... ############################################################################################################################################################################################ 1/4: log4j ############################################################################################################################################################################################ 2/4: log4j-slf4j ############################################################################################################################################################################################ 3/4: log4j-jcl ############################################################################################################################################################################################ 4/4: log4j-javadoc ############################################################################################################################################################################################ 1/4: removing log4j-slf4j-2.13.3-1.mga8.noarch ############################################################################################################################################################################################ 2/4: removing log4j-jcl-2.13.3-1.mga8.noarch ############################################################################################################################################################################################ 3/4: removing log4j-2.13.3-1.mga8.noarch ############################################################################################################################################################################################ 4/4: removing log4j-javadoc-2.13.3-1.mga8.noarch ############################################################################################################################################################################################ writing /var/lib/rpm/installed-through-deps.list Advisory committed to svn.
Keywords: (none) => advisory, validated_updateWhiteboard: MGA8TOO => MGA8TOO MGA8-64-OKCC: (none) => davidwhodgins, sysadmin-bugs
Version: Cauldron => 8
Whiteboard: MGA8TOO MGA8-64-OK => MGA8-64-OK
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0556.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
How could this fixed ? All Files in log4j-core.jar from log4j-2.13.3-1.1.mga8 has a date from Jan 22 2020 Version 2.15.0 is from December 6th, 2021 Then at least a few files should have a newer date like 2020 And if you leave a detector like this https://github.com/mergebase/log4j-detector over it, it says it's vulnerable. Regards Dieter
Resolution: FIXED => (none)Ever confirmed: 1 => 0CC: (none) => dieterStatus: RESOLVED => UNCONFIRMED
I don't understand where you looked for the date of your files. [neoclust@localhost log4j]$ ls -l /usr/share/java/log4j/ total 2028 -rw-r--r-- 1 root root 199166 Dec 10 22:11 log4j-1.2-api.jar -rw-r--r-- 1 root root 289377 Dec 10 22:11 log4j-api.jar -rw-r--r-- 1 root root 9235 Dec 10 22:11 log4j-api-java9.zip -rw-r--r-- 1 root root 1500520 Dec 10 22:11 log4j-core.jar -rw-r--r-- 1 root root 2294 Dec 10 22:11 log4j-core-java9.zip -rw-r--r-- 1 root root 25782 Dec 10 22:11 log4j-docker.jar -rw-r--r-- 1 root root 18443 Dec 10 22:11 log4j-jpl.jar -rw-r--r-- 1 root root 12619 Dec 10 22:11 log4j-osgi.jar [neoclust@localhost log4j]$ rpm -q log4j log4j-2.13.3-1.1.mga8 [neoclust@localhost log4j]$
Please don't reopen fixed bugs.
Status: UNCONFIRMED => RESOLVEDResolution: (none) => FIXED
Your detector is buggy. We didn't update log4j, we patched it.
Because of the severity of this security issue, this question should be allowed. After unpacking the jar files of the log4j package and inspecting the change data of all files, no patch is recognizable. The only changed files (after 2020) are all MANIFEST.MD and /usr/share/java/log4j/log4j-api.jar/META-INF/versions/9/module-info.class As a bystander, the question arises whether this is the complete patch.
A patch was added to the package: http://svnweb.mageia.org/packages?view=revision&revision=1761382 %prep does have %autopatch -p1 so it is applied during the build. The class files are all generated at build time. Make sure you're looking at the correct version of the package. The patch added came from: https://issues.apache.org/jira/browse/LOG4J2-3198 I don't see anything from the other bug so I'm not sure if we're missing something: https://issues.apache.org/jira/browse/LOG4J2-3201
Upstream advisory: https://github.com/advisories/GHSA-jfh8-c2jp-5v3q Debian fixed it in stretch by removing a class: https://salsa.debian.org/java-team/apache-log4j2/-/commit/98347bcf2247025ccddadd888d45bcc64e84a544
(In reply to David Walser from comment #9) >The class > files are all generated at build time. Make sure you're looking at the > correct version of the package. > This is the reason why this question came up by Dieter and also from me after i looked into the installed files from log4j-2.13.3-1.1.mga8. I unpacked all the jar files from the installed package and filtered by change date. The only changed class file is /usr/share/java/log4j/log4j-api.jar/META-INF/versions/9/module-info.class. All other files are from january 2020. I don't want to question the work from Nicolas and im not so familiar with this topic. But it looks strange (given the troubles this security hole is creating at the moment...)
(In reply to David Walser from comment #10) > Upstream advisory: > https://github.com/advisories/GHSA-jfh8-c2jp-5v3q > > Debian fixed it in stretch by removing a class: > https://salsa.debian.org/java-team/apache-log4j2/-/commit/ > 98347bcf2247025ccddadd888d45bcc64e84a544 And exact these class stil exists with the date from January 2020 in log4j-core.jar from the updated package. unzip the log4j-core.jar from the updated package and look under org/apache/logging/log4j/core/lookup/ the JndiLookup.class still exists. I have no knowledge of Java, but this type of attack makes you feel uncomfortable. Sorry for that.
Our method (and upstream's) of fixing it was different than Debian's, but I believe we're fine. I'd just like clarification from Nicolas if we need the fix for LOG4J2-3201 as well.
For my understanding the MANIFEST.MF , what you have changed, tell what is to exported from the bundle if you handle these as a OSGI Bundle. But it is a jar file and you can use it as a normal java file with all it is in. I'm right or not i don't know
Apache issued a new version log4j 2.16.0 with additional mitigations: https://lists.apache.org/thread/d6v4r6nosxysyq9rvnr779336yf0woz4 Disable JNDI by default https://issues.apache.org/jira/browse/LOG4J2-3208 Remove support for Lookups in messages https://issues.apache.org/jira/browse/LOG4J2-3211
Nicolas said on the qa-discuss mailing list that he would look into doing another update to the latest version.
See Bug 29766 for the latest.
Ubuntu has issued an advisory for this today (December 14): https://ubuntu.com/security/notices/USN-5192-1 They updated to 2.15.0.
Fedora has issued an advisory for this on December 13: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/VU57UJDCFIASIO35GC55JMKSRXJMCDFM/
(In reply to David Walser from comment #18) > Ubuntu has issued an advisory for this today (December 14): > https://ubuntu.com/security/notices/USN-5192-1 > > They updated to 2.15.0. That's very nice but not enough. You need 2.16 https://nvd.nist.gov/vuln/detail/CVE-2021-45046
Nope, 2.15 is enough for this CVE. 2.16 fixes another one in Bug 29766.