Xcode 13.2 contains Log4j vulnerability | Hacker News Reader

Xcode 13.2 contains Log4j vulnerability

developer.apple.com

182 pointselpakal41 comments

Note that they are on JDK 14.0.2. An old, unsupported version of Java which doesn't get any security patches anymore. Being on a non-LTS version of Java forces them to upgrade to a new major version of Java every six months to get security patches, which they apparently don't do.

This is a bit of a tangent, but this is emblematic of the fact that, beyond Xcode Cloud, the Apple Developer Tools team seems more excited to work on toys like Swift Playgrounds than make the Apple platform development experience better and more sustainable for users beyond the one-man shop and toy applications.

It’s not surprising that more are preferring to use Electron, React Native, or Flutter to develop apps than to live with the bare metal Xcode toolchain and Apple APIs.

The Java / Kotlin + Gradle and JS development ecosystems are dramatically easier to live, despite the fact that Apple has the resources to do dramatically better.

> It’s not surprising that more are preferring to use Electron, React Native, or Flutter to develop apps than to live with the bare metal Xcode toolchain and Apple APIs.

Funny, because Electron, RN, and Flutter are the toys of mobile app development, serving mostly just one-man shops and toy applications--and even Android developers are going to agree.

And while I'm also of the opinion that Xcode has plenty of areas for improvement, you can't just extend the same commentary to Apple's APIs. Apple APIs are incredibly stable, well-architected, and so highly scalable that it's almost an embarrassment that Google gets all the rep for being an engineering powerhouse when the Android SDK has always been an incoherent hell of a mess since Android came out.

I'm so glad to read this comment. I think one way to learn great software design is read through the Apple APIs. Obviously not all of them are perfect, but even when that is the case it's always interesting to ask yourself why.

GP don't praise Android SDK.

> It’s not surprising that more are preferring to use Electron, React Native, or Flutter

Do you have any data to back that up. As an iOS developer, that is not my experience at all.

Offering these two data points for the Flutter side of things at least.

The first is Google trends results for Flutter vs Swift globally in the last year.

https://trends.google.com/trends/explore?q=%2Fm%2F010sd4y3,%...

Along with StackOverflow’s 2021 report that shows Dart is more popular than Swift.

https://insights.stackoverflow.com/survey/2021

> shows Dart is more popular than Swift.

that... seems obviously wrong.

These things are not comparable.

Flutter and Dart are used on a plethora of platforms, including Android which has a far larger market share than iOS alone, and Windows, which takes the cake on the desktop.

Swift is used only on Apple platforms, and mostly for iOS. The use of Swift on macOS, watchOS or server-side development is negligible.

Despite my dissatisfaction with Apple policies and way of doing things, they offer native, fast, smooth and not battery-draining experience for the users, because of no Java and Electron crap in most of the apps, unlike Android.

That was not the topic of discussion. If you think that outcome is better, why not advocate for less friction towards it?

>Kotlin + Gradle development ecosystems are dramatically easier to live,

I know Xcode is a piece of crap, but truly, nothing approaches the level of mindfuckery that is Gradle.

This is the App Store upload tool, derived from (and maybe the same as) the iTunes Store upload tool. It comes from Eddy Cue’s org that runs the store, not the Developer Tools team.

Honestly I would wager that the Developer Tools team has never been very happy about the size and quality (outdated JRE) of the upload tool

Yes. It is a Java application that originally was written to facilitate the upload of large intermediate video files from post houses to the iTunes Store ingest systems. I know because I was there.

"Xcode contains a copy of the log4j library that has the CVE-2021-44228 security vulnerability. Xcode automatically downloads an updated version of this library and installs it into ~/Library/Caches/com.apple.amp.itmstransporter. When submitting apps to the App Store, Xcode uses the updated version of the library. (86390060)"

https://developer.apple.com/documentation/xcode-release-note...

Is this the first time anyone other than eskimo1 has given an official reply on the Apple Dev Forums?

The end must be nigh if Apple breaks its sinister silence.

Yes, it is first time. This thing is serious !

Maybe this is only the past couple of years, but it's not uncommon for Apple engineers to answer under the name "[Team Name] Engineer", especially to questions tagged with an associated WWDC session video.

What’s the attack vector and required user action(s) here? Since Xcode projects allow arbitrary scripting I wouldn’t assume the presence of log4j makes anything _worse_.

It seems to be in an component used for submitting apps to the App Store, a very local process, so not likely to get any usage as a "remote" code execution vector

Can anyone explain how this would be exploited and its actual risk level?

I understand the log4j2 cve -- craft some input so that log4j does a lookup and insert your arbitrary code there.

But how does this being in XCode present a risk and what level of risk?

Is someone running XCode in a production server somewhere? The most likely case I could think of would be in a CI type server, and this would only be vulnerable when a build is getting is in progress?

It's not on the level of "my app runs on tomcat" type of bad, I wouldn't think.

All a guess, but I think this impacts CI providers more than anything because they are running Xcode for arbitrary projects. If I were a CI provider I’d probably be nervous.

And also once Xcode is patched, all of our teams are going to have to update immediately and that wipes out a whole day of work.

But again, just guessing here.

If the CI runs the build of arbitrary projects, it already has a huge vector surface for attacks: xcode projects can contain shell scripts, ... So xcode's App Store submission components having log4j won't likely allow for more exploits of CIs or local devices

I assume you would need to load and run untrusted projects on your machine for an exploit to work, right?

(Not that it's not bad)

The newer WebSocket based Log4j attack vector [0] is pretty scary. Maybe not relevant to you/here, but definitely opens up a much bigger attack Surface.

[0]https://m.slashdot.org/story/394029

I think it's only a problem if there's a device accepting websocket connections running on your network. I can't think of anything you would run inside the confines of a presumed safe network that would also accept websockets from arbitrary origins.

Attackers would need to brute force or guess the right IP and port combination to do anything with this attack, so I don't think it will be a huge problem in practice. Just something to be aware of.

Java is only used in the App Store upload tool, I suppose you’d need to build an untrusted project and then upload it to the store? Not very likely.

There might be a vulnerability there if you use one of those SaaS tools that turn websites into apps for you. Some (early?) versions gave you the binaries that you'd just need to sign and upload yourself. In those circumstances, the insecure and outdated code can trigger and take over your machine. I don't think it's a big problem in practice, really.

The Java version listed is already several outdated so I don't think log4j is the only security problem the uploading system introduces. I'm not sure why Apple isn't shipping a supported, patched JRE instead of their own bespoke implementation, but they seem to be behind on patches as a result.

I think the outrageous thing here is that Xcode contains Java runtime.

Really? Xcode is an IDE. Java is a language supported by Xcode, even if it’s (probably) not supported well. (And for a brief time, Java was even a language advocated for app development by Apple.)

Are you arguing that any IDE must contain JRE?

What an odd question. No. I was merely expressing surprise that someone would consider a copy of JRE in a big IDE like Xcode to be outrageous. I don't think it's outrageous. Saying that something isn't outrageous isn't synonymous with saying that it's a "must".

I agree, I should have worded that differently. My point is an IDE isn't entitled to have yet another runtime which is not used for core functionality just because it is an IDE.

I call it outrageous because the task itself (uploading to App Store Connect) don't require a separate runtime. It's likely an artefact from the past or convenience vehicle for whoever wrote it; another example of developer's convenience trumping user experience.

Personally I think it's outrageous that Apple doesn't maintain and distribute OpenJDK as part of macOS. Wouldn't even require much internal effort—they could just throw a bit of money at Adopt (or similar) to maintain it.

It would also be a download-on-first-use thing, much like Rosetta 2 or Xcode command line tools. Latest version only, updated regularly, updates delivered similarly to Safari Technology Preview. If you need a specific version, download it yourself.

Apple for a long time had WebObjects, a server-side Web Framework in ObjC, later Java, inherited from Next. Judging by URL structure a lot of Apple infrastructure likes the stores and iTunes Connect were build on Webobjects and possible still are.

It's indeed quite ridiculous that a very tiny part of xcode requires Java, it's fun how Apple can keep such inconsistencies: why would a part of the development team of xcode use such a different tech compared to the rest of the software

It's part of the App Store upload process, and a legacy/holdover from using WebObjects 5 as part of the back-end for the original iTunes Music Store. WO5 was a full Java rewrite of WebObjects (which was originall Objective-C back when it was started at NeXT), because in around 2000 that seemed like a sensible choice given where the mindshare was in their target market (pretty enterprise - it was like $50k for a full deployment license at the time).

Several days after RCE disclosure and the best they can do is forum reply "yes we know, no ETA for a fix"? No security advisory, no immediate workaround suggested?

I am not sure what kind of security advisory would be helpful here? It's software you run locally, not something on a public server. How would anyone exploit this unless you are in a habit of running untrusted software on your local machine? And in the latter case, this vulnerability is probably the last of your worries.

Depends on what they log, could be controllable by the code you open in xcode. For example if you clone and open (not necessarily even run) a malicious github repo. VS code asks you if you trust the code you are opening for example and if not it turns into dumb editor mode for this sort of reason.

Reply on news.ycombinator.com