top | item 30091980

About the security content of macOS Monterey 12.2

200 points| ingve | 4 years ago |support.apple.com

107 comments

order
[+] perardi|4 years ago|reply
Some sympathy for the devil: operating systems are just so…big.

Like, there’s an arbitrary code execution issue fixed here in ColorSync. ColorSync! Who thinks to attack the color management system, and then how do you set up your org structure to protect from attacks on that? Because…assuming they have much of a team on it at all, as it’s probably a bit of a solved problem…your core team is probably going to be focused on color, and not buffer overflows.

macOS has a lot of old components now, and just getting a grasp of where you could possibly have security issues must be nigh impossible.

[+] jrockway|4 years ago|reply
I think you prevent these "corrupt file corrupts important memory" bugs in two ways: 1) use a memory safe language 2) write fuzz tests just like you'd write unit tests.

1 is becoming extremely viable, infrastructure for 2 is starting to be included with modern programming languages and so will soon become the norm.

[+] brundolf|4 years ago|reply
Which is exactly why we need to use safe languages. People can't even prevent vulnerabilities in the code they are scrutinizing, much less the other 90% they aren't.

(Beating a dead horse, I know, and not blaming the devs because this utility has been around forever, but regardless)

[+] SulphurCrested|4 years ago|reply
Since you pick on that example, yes I am unsurprised about an exploit in ColorSync. The bugs in ColorSync in combination with Photoshop are legend: for example, there was a "black crush" bug doing the rounds of photo blogs and forums which persisted for months. More recently, it was not possible to disable ColorSync when printing, which made it impossible to calibrate printers (that is, measure the printed result with a spectrophotometer in order to derive new ColorSync tables). And furthermore, I don't think it is actually the first colour profile exploit I've heard of, although I forget whether it was Apple's or someone else's.

However much of a team they have on ColorSync, it needs to be bigger. If they don't have code fixes to make, there's plenty of other things for them to get on with. I didn't think much of the API documentation, and multiple people who seemed credible to me claimed there wasn't enough detail for the kind of implementation Adobe and others need, as several calls have been deprecated. And, since Apple no longer offer their own competing product it would make sense to assist Adobe in getting it reliably right.

More than that, the calibration software for monitors is third party and, at least for the photo monitor I have... could be better. These monitors use onboard hardware LUTs instead of doing it in the GPU, so the software is hardware-specific. Fortunately, there are only a couple of brands who offer these high-end monitors, maybe 3 if you count LG, so there isn't all that much hardware to support. It's another case where the overall experience could be improved for a segment of Apple's customers if they put the effort in. There may even be money to be made.

ColorSync shouldn't have been an "old" component, if Apple had kept their eyes on what their users needed. Instead they went and changed Music again, which has apparently not pleased its users. It's a company whose management seems obsessed with a fairly narrow range of applications like home automation and instant messaging, the kinds of things shown in 1970s TV programs about the "future". If they widened their horizons more they would end up cycling through more of the many components of macOS more often, so things got timely refreshes.

[+] the-golden-one|4 years ago|reply
Would it not be possible to detect these kind of errors using machine learning now? To go through the code base and find unsafe operations?

There must be enough security bug fixes out there on GitHub that certain classes of security error become easily detectable.

[+] varenc|4 years ago|reply
There's also security updates for the two older versions of macOS

- Big Sur: https://support.apple.com/en-us/HT213055

- Catalina: https://support.apple.com/en-us/HT213056

Though the Monterey update fixes 13 CVEs and the Big Sur and Catalina updates only address 7 and 5 CVEs respectively.

It seems unlikely that Big Sur just isn't vulnerable to so many of the Monterey CVEs and instead this is just Apple prioritizing fixes for the latest macOS version. Officially Apple of course only provides security updates for the latest version.

Edit: Here's a list of the security issues fixed in the Monterey update that aren't mentioned in the Big Sur update: https://gist.github.com/varenc/7722a0fe198d85a7e49544bcf4066...

[+] gregoriol|4 years ago|reply
Big Sur is the latest supported version on some Retina MacBook Pros, so it's not such a bad idea for Apple to still provide updates for critical issues
[+] yborg|4 years ago|reply
>can root the box with a CrashReporter exploit

It's like poetry.

[+] bigbizisverywyz|4 years ago|reply
Exploited even whilst attempting to report an exploit.

Poetry indeed.

[+] jacobkg|4 years ago|reply
I finally upgraded to Monterey from Mojave this past weekend. I somehow didn’t get the memo that it was no longer getting security updates until my head security engineer said it last week
[+] bluedemon|4 years ago|reply
I noticed it last week. I finally have the time today to upgrade my macbook pro 2015 to Monterey. Hoping things go smooth.
[+] tempodox|4 years ago|reply
Does everything still work that used to work on Mojave? Any changes in bugginess?
[+] drewg123|4 years ago|reply
What is AMD kernel? The AMD graphics driver? Or is there a new x86_64 port to AMD CPUs? :)
[+] chipotle_coyote|4 years ago|reply
I'm 99% sure it's the AMD graphics driver, yes. I did see someone link the "amd-osx.com" website, but it seems unlikely that Apple would be issuing security fixes for that.
[+] clord|4 years ago|reply
Some shops call x86-64 “amd64” because AMD originated it. Not sure if Apple is one.
[+] olliej|4 years ago|reply
Oh nice, they include an explicit acknowledgement section (in addition to the more obscure acknowledgements in the bug descriptions)
[+] vineyardmike|4 years ago|reply
This was long requested from the security community, so hopefully they keep it up going forward! This would probably go a long way in terms of rebuilding their developer trust.
[+] saagarjha|4 years ago|reply
Is this new? I feel like I’ve been seeing these for a while.
[+] akersten|4 years ago|reply
> Impact: An application may be able to access a user's files

What does this mean? Back in my day that's just what a regular computer program did.

[+] mattl|4 years ago|reply
Applications have to ask permissions for Desktop, Documents, Downloads, etc.
[+] nyc640|4 years ago|reply
Thank you for posting this! Definitely had some concern about the IndexedDB leak, so good to know the new release is out (and has a fix for the issue) so I can update ASAP.
[+] aetherspawn|4 years ago|reply
It's easy to stress over the number of things here, but remember: every org probably has a huge list of these, known-and-sitting on the backlog, so if there's this many in the changelog it means that someone actually cares enough to bring them forward vs. yet another UX refresh or something like that.
[+] jonas21|4 years ago|reply

[deleted]

[+] teewuane|4 years ago|reply
I'm surprised they still ship with python2.
[+] CSSer|4 years ago|reply
You're given this warning when you fire up the interpreter (at least in Monterey):

> WARNING: Python 2.7 is not recommended. This version is included in macOS for compatibility with legacy software. Future versions of macOS will not include Python 2.7. Instead, it is recommended that you transition to using 'python3' from within Terminal.

[+] blitzar|4 years ago|reply
I'm impressed they ship with python.
[+] tempodox|4 years ago|reply
I don't know, I already find Catalina way too buggy for my taste. I expect this to only get worse with later OSs, as it happened time and again in the past several years. I'll hold off on upgrading until it's absolutely unavoidable.
[+] smarx007|4 years ago|reply
Does anyone know if this fixes a 100% CPU use by bluetoothd on 2015ish macbook pros? The release notes are scant on non-security fixes.
[+] gnatman|4 years ago|reply
2020 M1 air here and airpods pro are waking my machine as soon as it goes to sleep. Some general bluetooth bugginess around I think.
[+] landonxjames|4 years ago|reply
This issue was killing my battery, but I don't use bluetooth on this laptop at all, so going to Settings > Bluetooth and turning it off completely fixed the issue for me. Haven't seen a bluetoothd process in ~2 weeks now.
[+] crumbits|4 years ago|reply
I don’t think they will fix it, isn’t it searching for and proxy ink for AirTags?
[+] cudder|4 years ago|reply
Is this as bad as it looks?
[+] kosolam|4 years ago|reply
How many of these automatically would have been prevented by Rust compiler with production compilation settings?
[+] Canada|4 years ago|reply
I wonder which older versions are vulnerable to CVE-2022-22586 and which ones will be patched.
[+] zozbot234|4 years ago|reply
Man, these advertisements for Rust are really getting out of control.
[+] jtsiskin|4 years ago|reply
Seriously… half of these are memory management bugs
[+] hit8run|4 years ago|reply
CVE-2022-22590 Sounds scary
[+] crumbits|4 years ago|reply
Damn. I switched to OpenBSD a while back, glad I did.