Log4j XCode vulnerability - resolution eta?

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.

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.

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.

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)