6 ms·

Xcode 13.2 contains Log4j vulnerability

182 points by elpakal 5y ago

folli 5y ago
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)
- yodon 5y ago
  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 https://m.slashdot.org/story/394029
  - jeroenhd 5y ago
    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.
- mrpippy 5y ago
  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.
  - jeroenhd 5y ago
    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.
morpheuskafka 5y ago
Is this the first time anyone other than eskimo1 has given an official reply on the Apple Dev Forums?
- classified 5y ago
  The end must be nigh if Apple breaks its sinister silence.
- marvel_boy 5y ago
  Yes, it is first time. This thing is serious !
- Austin_Conlon 5y ago
  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.
needusername 5y ago
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.
- akkawwakka 5y ago
  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.
  - rTX5CMRXIfFG 5y ago
    > 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.
    - deleted 5y ago
      [deleted]
    - asimpletune 5y ago
      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.
thombles 5y ago
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_.
- deleted 5y ago
  [deleted]
- gregoriol 5y ago
  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
progbits 5y ago
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?
- ribit 5y ago
  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.
  - progbits 5y ago
    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.
Kina 5y ago
"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-notes/xcode-13_2_1-release-notes https://developer.apple.com/documentation/xcode-release-note...
viktorcode 5y ago
I think the outrageous thing here is that Xcode contains Java runtime.
- simondotau 5y ago
  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.)
  - viktorcode 5y ago
    Are you arguing that any IDE must contain JRE?
    - simondotau 5y ago
      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".
      - viktorcode 5y ago
        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.
        simondotau 5y ago
        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.
bfung 5y ago
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.
- elpakal 5y ago
  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.
  - gregoriol 5y ago
    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

182 points by elpakal 5y ago

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)

yodon 5y ago
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 https://m.slashdot.org/story/394029
- jeroenhd 5y ago
  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.
mrpippy 5y ago
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.
- jeroenhd 5y ago
  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.

morpheuskafka 5y ago

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

classified 5y ago
The end must be nigh if Apple breaks its sinister silence.
marvel_boy 5y ago
Yes, it is first time. This thing is serious !
Austin_Conlon 5y ago
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.

needusername 5y ago

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.

akkawwakka 5y ago
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.
- rTX5CMRXIfFG 5y ago
  > 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.
  - deleted 5y ago
    [deleted]
  - asimpletune 5y ago
    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.

thombles 5y ago

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_.

deleted 5y ago
[deleted]
gregoriol 5y ago
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

progbits 5y ago

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?

ribit 5y ago
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.
- progbits 5y ago
  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.

Kina 5y ago

"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-notes/xcode-13_2_1-release-notes https://developer.apple.com/documentation/xcode-release-note...

viktorcode 5y ago

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

simondotau 5y ago
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.)
- viktorcode 5y ago
  Are you arguing that any IDE must contain JRE?
  - simondotau 5y ago
    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".
    - viktorcode 5y ago
      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.
      - simondotau 5y ago
        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.

bfung 5y ago

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.

elpakal 5y ago
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.
- gregoriol 5y ago
  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