Hacker News new | past | comments | ask | show | jobs | submit login
Apple patches CVE-2020-9859 (unc0ver) (support.apple.com)
190 points by rowawey 7 months ago | hide | past | favorite | 74 comments



I think this might be the fastest patch of a security issue affecting Apple's operating systems, ever. Aside from *.0.1 releases that fixed critical bugs with core features in new OSes, has anything been patched this fast?

(I'm also obligated to post that the bug that this fixes is not new; it was discovered back in iOS 11, fixed, and Apple reopened it in an iOS 13 update: https://www.synacktiv.com/posts/exploit/return-of-the-ios-sa...)


I have a pretty clear memory of the JailbreakMe 2/3 bugs (which, for anyone else reading, were bugs that could be used from the web browser, and so were of the form "you click a link or have some evil iframe and are pwned") being fixed in six days (which I mentally cataloged as the minimum turnaround time Apple could muster).


That's a bit before I was using iOS, so I'll take your word on that one ;) AFAIK some system call filtering went into WebKit at some point to make this specific exploit unreachable from the web process, so I guess you could call it "less severe" than JailbreakMe was. That being said, I guess "zero day affecting all current devices" is probably good enough to get priority. (FWIW, heavily publicized non-security bugs often get quicker updates, sometimes within one or two days, which I assume pushes close to how quickly they can get a fix merged and through B&I.)


That syscall filtering still exists and broke a build for three or four days recently.


Is this something that made it into the public WebKit sources? Would be curious to see the commit for that :)


If that doesn't illustrate their true priorities re: user security/ privacy, then I'm not sure what could.


https://twitter.com/s1guza/status/1266433756270866433

This may also illustrate their priority to reintroduce the same bug and re-fix it at faster speeds to wow their fanbase. Or you know the priority may also be keeping the walled garden - walled? Also it might just be security response 101 - like every other major OS vendor out there depending on the bug. But yeah privacy and security for users that's a much nicer marketing pitch.


> Or you know the priority may also be keeping the walled garden - walled?

That's actually what I interpreted prvc's comment to be saying. But I guess I might have misinterpreted it.


Jailbreaking is not a threat to the walled garden. The majority of users want the walls there to protect them from malware and crappy software breaking their device. The obvious market preference for managed devices that "just work" is lost on the HN crowd because most of us belong to a different market with different preferences.

My reading is that this bug could potentially allow apps to install rootkits. The speed of the fix tells me maybe it's being exploited that way right now in the wild.

BTW MacOS got the fix in record time too in spite of it being far less strictly walled than iOS. That supports my suspicion that this bug is being used in nasty ways.


The more interesting part is that unc0ver exploits a bug that was reintroduced by Apple: https://twitter.com/s1guza/status/1266433756270866433 ..



From the equivalent macOS patch: https://support.apple.com/en-us/HT211215

> Available for: macOS High Sierra 10.13.6, macOS Catalina 10.15.5

That's interesting—did the bug exist on both 10.13 and 10.15, but not 10.14?


If it is true the bug was present in iOS 11 and fixed in iOS 12 before being reintroduced in iOS 13, that might align with macOS 10.14 (≈ iOS 12) being unaffected.


So much for regression tests.


Yes: it was fixed for that period and then rebroken for Catalina.


Oh dear. My laptop is saying 10.15.4 is the latest. Huh.


try `softwareupdate -l`


press ctrl-r


⌘ + R


So, it is a bug in macOS or iOS? Both?


Fixes were pushed out for all four major platforms today, presumably as the affected system call is available on all of them.


Be nice if they could patch a kernel bug in macOS with less than a 1.5GB download.


It might seem strange, but they are using a change/build/deploy mechanism designed to deliver updates to any and all parts of an OS across a range of hardware devices.

I'm pretty sure the mechanism, from end-to-end, is complex, and providing an optimized path for small changes would require resources, introduce more risk, and come at the expense of something else.

Sucks, though, for everyone who doesn't have a reasonably fast or reliable internet connection.


That’s not an axiomatic truth. Binary diff algorithms exist (ask me, I’ve written several) that can identify and isolate changes across versions even when content is changed at non-block boundaries, non-contiguously, etc and while they are computationally expensive patches to create, they are trivial to unpack/apply.

But generally the software industry has moved to a model where diffs are shunned and “recreate from scratch” is embraced for reasons that range from reproducibility to speed of development to architectural purity and everything in between.


That's not universally true. Android makes significant use of binary diffs for patching to reduce OTA upgrade sizes, for example. However they're not appropriate for all situations, and there's a bunch of legitimate reasons Apple may have chosen not to pursue this for kernel updates.


Chrome does too, I hear.


https://blog.chromium.org/2009/07/smaller-is-faster-and-safe...

Yes, and smaller updates is arguable better security for users because they'll actually update. A 3gig download and a 15 to 45 minute down time is a huge incentive to NOT update.


I work on a ship part of the year. Satellite internet shared between 50 people. These Apple updates would saturate the network and grind it to a halt before we started blocking them on the firewall. iMessage got caught in the crossfire and now sometimes works and sometimes doesn't.


If you have at least one Mac, you can use Content Caching:

https://support.apple.com/guide/mac-help/what-is-content-cac...

It works for iCloud content, too.


I tried to make that work, but it didn't seem to do anything. Repeat downloads took just as long as before.


you can verify if Content Cache is working in a couple ways... first, while installing the update, you should see a CPU usage spike in Activity Monitor for the process "AssetCache".

secondly, you can run this command on the machine you want to upgrade, to verify that it can see your Content Caching Server (it should report the local IP address of the machine you set up Content Caching on) "AssetCacheLocatorUtil"


great info, thanks.

Looks like if the machine is asleep it won't use it for a content cache, even if "wake for network access" is turned on. So a pretty useless feature if you have a machine that's allowed to sleep.


If you've just turned on Content Caching, or the machine running it has rebooted, client devices will not discover the server immediately. You need to wait a while, or reboot the client devices, which will force them to discover it.


^ This is why you should always be able to turn off automatic downloading of updates.


And you can. Doesn't mean all your users' personal devices comply with the request to do so.


On iOS? iPhones don't update automatically (if you tell them not to), but I'm not aware of a way to stop them from downloading updates, other than weird workarounds like installing a tvOS beta profile.


I forget that perhaps Apple's intent is to do what people complain about: download the update anyway, regardless of the setting. My anecdotal experience (I have yet to have an iOS device actually download the update when I have automatic updates turned off) allows me to forget.


How about silent updates, like the one Apple pushed to remove Zoom's ghost server last year?


Those are non-executable rulesets that are part of XProtect, the system-level antivirus. It’s not an OS update.


Actually, my iphone won't update unless it's being connected via WLAN rather than WWLAN. Makes me kindof of a persona non grata at friends where I have a WLAN password, and the first thing happening if I'm on a visit is that my iphone updates itself. Though it's not as bad as people with Windows notebooks exhausting my mobile plan when they're at my place.


If you're all on the same LAN, then you can configure one device to download it from Apple and share it with the rest.


Sure but Fedora and RHEL (for example) manage to do this for all updates on a small fraction of the budget.


It's funny how rarely you see a reasonable response to a question about "why doesn't my software do X" on a site full of software developers.


I would venture to guess that often it is because the answer is 'business reasons', which is often not reasonable.


that's a flippant guess. the underlying reasons or the reasoning for others' decisions may not be apparent to you (i.e., under-explained).

beyond that, if decisions others make often seem not reasonable, it's probable that you disagree with the values on which those decisions are based, rather than those business decisions being without reason. you may be entirely justified in your disagreement, but that's a different animal from unreasonableness.

also, most business decisions are made under uncertainty and with imperfect information (under-informed), and many can seem less reasonable in hindsight as a result.

in any case, it's really unlikely that decision makers are chaos monkeys even if it seems that way from your vantage point.


I apologize if this is a stupid question, but, is there a reason they can't do a diff patch on the binary? Would it end up not introducing savings?


Incompetence.

A private company can deliver two human beings alive to a point in space with millimeter precision. Meanwhile another can't deliver Operating Systems without gross bugs or smaller updates with binary diff patching.


I want to point out that software and space are quite different problems. Much of the engineering for space appears to be mathematically differentiable and continuous -- a small change in inputs usually results in a predictable change in outputs. It's hard work, but relatively intuitive.

Software is more chaotic though. A small change in inputs can change behavior drastically, like stepping a tiny bit to the right on a branch of the Mandelbrot set. It's sometimes easier work, but often relatively counterintuitive.


There's no amount of handwaving that will excuse Apple for messing up their signin authentication, mobile throttling, faulty keyboards being delivered for years despite customer outcry or allowing anyone to login as root with blank password on macos. Those things should get caught in basic QA. It's not rocket science.

I repeat: it's incompetence.


I rather would point out management. This is what changed in this timeframe.


I just wish it didn't take 30 minutes to install, even on modern Macs with PCIe drives.


It’s indeed infuriating than any small-ish kernel patch takes so long to install. I wonder what the update system is doing.


On my iPhone SE 2020 the update size is 3,31 GB (from 13.5 to 13.5.1)


at least the iOS patch is "only" 44 MB


[flagged]


Update sizes has little to do with needing larger storage, especially on Macs.


[flagged]


I currently don't have one, so…no? I do usually try to keep Hacker News clean of low-quality comments, though, which is fairly distinct from "negative apple feedback".


I'm confused by the GP's us-vs-them animosity. There was an interesting issue that got buried in a polarizing "fan" vs "hater" dynamic. :'( Sigh

Like, shouldn't most high-end consumer devices include a dedicated update storage partition or flash area so that user storage is never impacted?


And it's a much more interesting topic than trying to figure out if I'm an Apple astroturfer, which in itself is strange because the top comment in this very thread is me pointing out that Apple unpatched this bug in iOS 13…plus it's against the site guidelines, which is why I assume that the comments have been flagged.

But back on topic: there are some devices that do include a specific partition for updates, but I don't think it's usually for user storage, but for "seamless updates": you install the OS to the other partition, reboot, and the partitions swap and you have a new OS up and running immediately. I actually doubt that any manufacturer would forgo not counting that as part of their user storage, unfortunately…


As someone who has been corrected by you when quoting from inaccurate sources on iOS and jailbreak related info, thanks for what you do and how you go about it. You're curt and courteous, which can come off as being short, but you're always accurate in my experience. I don't think you should worry too much about people thinking you're an astroturfer, because those who know the technical side know that you know your stuff.


Thanks for the kind words, but you'll find that I'm not always right ;)


How did you know I read your blog? :P


Yeah people like you did a lot of work to hide apple’s planned obsolence in the past, wouldnt be entirely shocked if this was the case. Now you can apply for a job at apple showing what a good sheeple you are.


We've banned this account for repeatedly breaking HN's guidelines and using multiple accounts to abuse the site. If you'd please stop doing that, we'd appreciate it.

https://news.ycombinator.com/newsguidelines.html


Except storage is soldered on. Storage juggling should be automated with an additional volume IMHO, because installing a new OS or point release shouldn't be a massive, manual hassle. On iOS, a USB2Go device should be usable... but ideally, it would have enough reserved space for all possible updates.


Which two Mac drive options are only 1.5GB apart?


Strawman. An almost full 256 GB SSD MBP would obviously need the next one up, but it's moot if it's soldered on unless you're a Louis Rossmann fan with the microsoldering and microscope play-at-home pack.


No my point is 1.5 GB is too small a transient (you delete the download when done) requirement to make someone have to bump up disk sizes.


You didn't communicate that. There is no "download" to delete on iOS (and derivatives) and it's managed by the system on macOS. It's not a small delta when it should be tiny (100 MiB), that eats up data plan and storage.


You can delete a downloaded (but not installed) update on iOS.


That's not my point. It's not a user-accessible file, but still steals space from the user.


I jailbroke for the first time in nearly a decade when unc0ver came out. It's actually pretty useful. I really love having the ability to use Flex on any app on my device.


Phew. Just updated to 13.5. Good to know I'm good on the jailbreak front.



hm




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: