Log4j XCode vulnerability - resolution eta?

  • How? Java isn't installed on macOS.

  • Xcode does include a Java runtime environment - the App Store upload has always used Java tooling in its delivery mechanism and ships a Java Runtime Environment: % /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/bin/java -version openjdk version "14.0.2" 2020-07-14 OpenJDK Runtime Environment 14.0.2-5906ce1373 (build 14.0.2+12-iTunesOpenJDK-8) OpenJDK 64-Bit Server VM 14.0.2-5906ce1373 (build 14.0.2+12-iTunesOpenJDK-8, mixed mode

  • Does anyone know if Xcode 13.1 is affected?

Add a Comment

Apple Recommended Answer

  • Thanks for citing this, I didn't notice this in the 13.2.1 release notes!

  • Does it the same in the iTunes Producer app as it contains the same issue as the transporter app. mentioned above. /Applications/iTunes Producer.app/Contents/itms/share/OSGi-Bundles/org.apache.logging.log4j.core-2.11.2.jar contains Log4J-2.x >= 2.10.0 VULNERABLE :-(

    thanks for replies.

Add a Comment

Answers

Hi, the Xcode team is aware of this issue. We don’t usually give ETAs for when a bug will be fixed, but the team is aware that this is a security concern.

  • Hi, any tips for those who are using Xcode 13.2 in production?

  • @niclego, better update to Xcode 13.2.1.

  • Updated to Xcode 13.2.1 still I could see two Log4J vulnerabilities:

    VULNERABLE: /System/Volumes/Data/Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/share/OSGi-Bundles/org.apache.logging.log4j.core-2.11.2.jar -> org/apache/logging/log4j/core/net/JndiManager.class [04fdd701809d17465c17c7e603b1b202: log4j 2.9.0 - 2.11.2]

    VULNERABLE: /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/share/OSGi-Bundles/org.apache.logging.log4j.core-2.11.2.jar -> org/apache/logging/log4j/core/net/JndiManager.class [04fdd701809d17465c17c7e603b1b202: log4j 2.9.0 - 2.11.2]

Add a Comment

Transporter (docs here) invoked via xcrun iTMSTransporter, has a built-in auto-update mechanism. It will check for and cache new java libraries on first launch and once per day following, and always does this prior to actually invoking functionality.

You can verify this yourself by just running xcrun iTMSTransporter and watching the log output, where you'll see the new library downloaded, i.e.:

[2021-12-18 10:27:17 EST] <ForkJoinPool.commonPool-worker-23>  INFO: downloading resource: org.apache.logging.log4j.api/2.16.0

It will not replace the library in-place within the .app bundle, instead it will cache them to ~/Library/Caches/com.apple.amp.itmstransporter and then only load the libs from that location. (You can also delete that cache directory to force it to re-run this process)

Given all of the above, it seems like there will be no cases of someone inadvertently using the vulnerable library, even though it would remain on disk in the Xcode app bundle, for as long as Apple continues shipping it (13.2.1 still includes it).

Since other platform companies and vendors have been able to quickly issue public statements on the subject of log4j2, I think the right thing for Apple's security or WWDR team to do would be to have a public KB article to just simply explain the above. Xcode is widely known and installed, log4j2 is now widely known, but these specific details are not. FB9811066 is my feedback/rdar asking for such a public KB/article on the subject.

  • Thanks for citing this, I didn't notice this in the 13.2.1 release notes!

  • Does it the same in the iTunes Producer app as it contains the same issue as the transporter app. mentioned above. /Applications/iTunes Producer.app/Contents/itms/share/OSGi-Bundles/org.apache.logging.log4j.core-2.11.2.jar contains Log4J-2.x >= 2.10.0 VULNERABLE :-(

    thanks for replies.

Add a Comment

Can someone explain this in layman's terms? Are macs affected by the Log4j virus or not, if so please explain. Thanks everyone any clear cut answer is very appreciated.

@Whitakerj If Apple took the pain to update the library on upload, it is because they analysed that there was a risk. And the new library (hopefully) protects from it.

So AFAIK, answer is YES.

It would be nice (read: my employer will be less concerned) if Apple could update Xcode so it doesn't include <2.17.

Krampus gave us another log4j remote code execution vulnerability (CVE-2021-44832), with the patch coming about 10 days after XCode 13.2.1 was released.

XCode might be vulnerable; it's 13.2.1 release notes don't mention patching this newer vulnerability.

I'm with donmontalvo and wish XCode would excludes all log4j versions less than 2.17.1. When I scan my system with CloudStrike's CAST tool, XCode pops in a big way. If XCode could upgrade /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/share/OSGi-Bundles/org.apache.logging.log4j.core-2.11.2.jar to a secure version, my company would be much less worried.

Please consider that as long as the vulnerable jar exists on the local filesystem, it should be considered vulnerable. Preventing the App Store from becoming a distribution mechanism is good, but not good enough.

Post not yet marked as solved Up vote reply of sot3 Down vote reply of sot3

Anyone have a update in regards to this issue? I tried calling apple support and they gave me a run around for now.

Thanks!

The updated info is located in the release notes for Xcode 13.3:

Mitigated several Log4J 2 vulnerabilities by updating Log4J 2 jar files to version 2.17.1. See https://logging.apache.org/log4j/2.x/security.html. (86489820)