[HN Gopher] Apple patches CVE-2020-9859 (unc0ver)
___________________________________________________________________
Apple patches CVE-2020-9859 (unc0ver)
Author : rowawey
Score : 120 points
Date : 2020-06-01 18:06 UTC (4 hours ago)
(HTM) web link (support.apple.com)
(TXT) w3m dump (support.apple.com)
| KenanSulayman wrote:
| The more interesting part is that unc0ver exploits a bug that was
| reintroduced by Apple:
| https://twitter.com/s1guza/status/1266433756270866433 ..
| Flockster wrote:
| See also from 8 days ago:
| https://news.ycombinator.com/item?id=23287364
| baggy_trough wrote:
| Be nice if they could patch a kernel bug in macOS with less than
| a 1.5GB download.
| xerces8 wrote:
| at least the iOS patch is "only" 44 MB
| andarleen wrote:
| Forces users to buy larger storage. Clever marketing.
| lallysingh wrote:
| Which two Mac drive options are only 1.5GB apart?
| rowawey wrote:
| 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.
| lallysingh wrote:
| 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.
| rowawey wrote:
| 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.
| snazz wrote:
| You can delete a downloaded (but not installed) update on
| iOS.
| rowawey wrote:
| That's not my point. It's not a user-accessible file, but
| still steals space from the user.
| rowawey wrote:
| 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.
| saagarjha wrote:
| Update sizes has little to do with needing larger storage,
| especially on Macs.
| andarleen wrote:
| Did your boss ask you to police hn against negative apple
| feedback?
| saagarjha wrote:
| 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".
| andarleen wrote:
| 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.
| rowawey wrote:
| 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?
| saagarjha wrote:
| 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...
| aspenmayer wrote:
| 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.
| saagarjha wrote:
| Thanks for the kind words, but you'll find that I'm not
| always right ;)
| jmull wrote:
| 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.
| joshocar wrote:
| 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.
| LeoPanthera wrote:
| 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.
| Wowfunhappy wrote:
| ^ This is why you should always be able to turn off
| automatic downloading of updates.
| jagged-chisel wrote:
| And you can. Doesn't mean all your users' personal
| devices comply with the request to do so.
| Wowfunhappy wrote:
| 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.
| snazz wrote:
| 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.
| Wowfunhappy wrote:
| 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?
| hu3 wrote:
| 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.
| cozzyd wrote:
| Sure but Fedora and RHEL (for example) manage to do this for
| all updates on a small fraction of the budget.
| ComputerGuru wrote:
| 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.
| machello13 wrote:
| 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.
| igreulich wrote:
| I would venture to guess that often it is because the
| answer is 'business reasons', which is often not
| reasonable.
| clairity wrote:
| 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.
| minedwiz wrote:
| I just wish it didn't take 30 minutes to install, even on
| modern Macs with PCIe drives.
| saagarjha wrote:
| 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...)
| saurik wrote:
| 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).
| saagarjha wrote:
| 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.)
| why_only_15 wrote:
| That syscall filtering still exists and broke a build for
| three or four days recently.
| saagarjha wrote:
| Is this something that made it into the public WebKit
| sources? Would be curious to see the commit for that :)
| prvc wrote:
| If that doesn't illustrate their true priorities re: user
| security/ privacy, then I'm not sure what could.
| Wowfunhappy wrote:
| 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?
| xerces8 wrote:
| So, it is a bug in macOS or iOS? Both?
| saagarjha wrote:
| Fixes were pushed out for all four major platforms today,
| presumably as the affected system call is available on all of
| them.
| saagarjha wrote:
| Yes: it was fixed for that period and then rebroken for
| Catalina.
| 0x0 wrote:
| 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.
| drewg123 wrote:
| So much for regression tests.
| vmchale wrote:
| Oh dear. My laptop is saying 10.15.4 is the latest. Huh.
| randyrand wrote:
| press ctrl-r
| dewey wrote:
| [?] + R
| based2 wrote:
| https://www.macrumors.com/2020/06/01/apple-releases-ios-13-5...
|
| and for macOs https://support.apple.com/en-us/HT211215
| [deleted]
___________________________________________________________________
(page generated 2020-06-01 23:00 UTC)