[HN Gopher] Apple has just released the first Rapid Security Res...
___________________________________________________________________
Apple has just released the first Rapid Security Response for
Ventura
Author : Amorymeltzer
Score : 134 points
Date : 2023-05-01 18:06 UTC (4 hours ago)
(HTM) web link (eclecticlight.co)
(TXT) w3m dump (eclecticlight.co)
| chuckreynolds wrote:
| I was great to see until the update didn't work lol. works now
| but... confusing for the first use.
| 0000011111 wrote:
| "Unable to check for updates Could't communicate with a helper
| application." That is the error I am getting when trying to
| update from on macOS 13.3.1 on a M1 2020 MacBook Air.
| niij wrote:
| Warning: if you install this it doesn't give you the option to
| delay a reboot to apply the update. I got a notification my
| computer would be restarting in 60 seconds as soon as the install
| completed.
| jerrysievert wrote:
| you can delay it by simply closing the "restarting in ..."
| dialog.
|
| you can resume in software update by clicking "Restart Now".
| reaperducer wrote:
| _I got a notification my computer would be restarting in 60
| seconds as soon as the install completed._
|
| This is not new. I got the same notice earlier today updating a
| MacBook running Big Sur, which is two versions before Ventura.
| judge2020 wrote:
| This notification is different. The ONLY option I see in the
| notification is to restart. And it's counting down to 0
| menacingly.
| clint wrote:
| Not new
| reaperducer wrote:
| Again, same notification I got with Big Sur. Complete with
| "menacing" countdown.
| capableweb wrote:
| Ah, the good'ol Windows method of forcing updates. Rely on
| users saying no within X seconds, otherwise go for it
| regardless if they want to or not. Awesome when you didn't
| notice that an update happened because you were grabbing a
| coffee, or that the computer want to check a 2TB disk for
| errors upon reboot. Usually happens when you have much more
| important things to do at the moment.
| alpaca128 wrote:
| Forced reboot after an update is not the same as forced
| updates. It's not like Windows can update without reboot
| either.
|
| So far I haven't seen Mac OS force any update on me, not only
| that but when I accidentally activated automatic updates it
| showed a notification that stays on screen until you
| confirm/cancel the setting change.
| Dalewyn wrote:
| >It's not like Windows can update without reboot either.
|
| And neither can Linux, contrary to popular belief. Anything
| that involves system services or god forbid the kernel
| requires a reboot.
|
| Yes, if the kernel wasn't updated you could meticulously
| reboot each individual system service that was updated
| instead, but why bother when you can just reboot and be
| done with it?
| commoner wrote:
| > And neither can Linux, contrary to popular belief.
| Anything that involves system services or god forbid the
| kernel requires a reboot.
|
| That is not true at all, and anyone can confirm this by
| upgrading the kernel and system services (e.g. desktop
| environment, display manager, systemd) on Arch Linux and
| verifying that just about everything continues to work
| normally. In my experience, the only things that require
| a reboot are a few particular kernel modules (such as the
| VirtualBox host modules) and only if you are going to use
| those modules. Even in that case, it is still your choice
| whether you want to reboot.
| formerly_proven wrote:
| Gnome, KDE and also Firefox and Chrome don't seem to be
| particularly fond of updates being applied under their
| ass, probably because they are heavy on dynamic code
| loading and spawning workers with unstable APIs,
| respectively. Firefox even added some code to detect this
| and show a blank page with "You gotta restart Firefox
| before you can open new tabs" instead of crashing.
|
| Edit: Another classic is upgrading the kernel on Arch,
| not rebooting, then trying to use a thumb drive for the
| first time since the last boot. Since Arch uses one
| package for all kernel versions, only one set of loadable
| modules is installed per kernel package - so upgrading
| the package removes the loadable modules of the currently
| running kernel.
| commoner wrote:
| I do restart browsers after upgrading them, but that's
| different from restarting Linux. For desktop
| environments, I usually don't bother rebooting Linux for
| anything other than major releases (like GNOME 43/44 and
| Plasma 5.26/5.27) since most of the minor releases don't
| make enough of a difference in day to day use to
| interrupt what I'm doing.
| zamalek wrote:
| > Anything that involves system services
|
| This is not true. NixOS, as one example, is able to
| figure out which services (including system) need to be
| restarted.
|
| > god forbid the kernel
|
| This is not true either. Live kernel updates are possible
| (but are usually a paid addition, e.g.
| https://ubuntu.com/security/livepatch).
| lockhouse wrote:
| In the case of an update involving a shared library you
| would still have to close and restart every single
| program that links against it though, right? Which if
| we're talking about something like glibc you might as
| well just reboot.
| commoner wrote:
| I've never had to reboot Linux after a glibc update if I
| didn't care whether the new version was being used. In
| general, glibc updates are not important enough to
| interrupt what I'm doing to reboot my device and I'll
| just shut down or reboot my device the next time I
| normally do.
| zamalek wrote:
| If you wanted the change to take effect then, yes, you
| would need to restart those apps. Because of the way that
| NixOS deals with dependencies, the old versions would
| still be around for running apps to use and carry on.
|
| It might actually be a useful tool for NixOS: finding out
| which processes have a specific version of a module
| loaded, so that the user can be warned to restart those
| processes.
|
| If the user wants to restart processes they can, if they
| want to just reboot they can also. Simply because it's
| "simpler" to do one, doesn't mean it's the correct
| universal choice in all circumstances. My wife, for
| example, leaves way to much crap open and leaves her
| laptop suspended - a restart is a serious issue for her.
| doublepg23 wrote:
| I'm seeing a lot of "Unable to Verify" based on the r/Apple
| Reddit thread.
|
| EDIT: Seems to be working as of 15min ago.
|
| https://reddit.com/r/apple/comments/134u12e/apple_releases_r...
| [deleted]
| sashk wrote:
| that's for iOS/iPadOS. Installed macOS update without issues.
| [deleted]
| ls612 wrote:
| Updates are also available for iOS it seems.
| tuxone wrote:
| Doesn't seem to be installable for me on Xr.
| itake wrote:
| My iPhone can't verify the update.
| livinglist wrote:
| Happened to me quite few times, try rebooting
| Scoundreller wrote:
| Same. Says it can't because I'm no longer connected to the
| internet, but I'm here!
| bink wrote:
| The dangers of over-simplifying your error messages to
| cater to the average user.
| willis936 wrote:
| I think the real hazard is insufficient testing of
| infrequently used features.
| nehal3m wrote:
| Same. iPhone 8, EU West.
|
| edit: MacOS reports iPhone being up to date.
|
| edit 2: Selecting 'use mobile data' when downloading and
| installing does work. Go to Settings > General > iPhone
| Storage and delete the update package. Restart the download
| & install process and let it use mobile data this time.
|
| I get the feeling checking the hash does work over LTE as
| opposed to Wi-Fi, based on absolutely wild speculation.
| Scoundreller wrote:
| > let it use mobile data this time.
|
| This is the most Canadian-hostile update in the history
| of computing!
| yumraj wrote:
| Ditto. Keeps complaining that my phone does not have Internet
| access.
| AdamJacobMuller wrote:
| Please click _here_ to go to our website and troubleshoot
| why you don't have internet access.
| fweimer wrote:
| For those not familiar with the Apple platforms:
|
| > By default, your device allows Rapid Security Responses to be
| applied automatically and, if necessary, will prompt you to
| restart your device.
|
| https://support.apple.com/en-us/HT201224
|
| Unfortunately, the article does not say whether the update is
| applied automatically even if the device is locked.
| acdha wrote:
| The thing I don't understand is why they blocked RSR behind a
| password prompt. You can't even use Face ID / Touch ID and in my
| experience that plus a reboot means a lot of people will put it
| off as long as they can.
|
| iOS also really needs to trigger the automatic Photos + Apps
| storage reclamation process since statistically everyone I know
| who delays updates does it because their phone is full of
| pictures & videos. The iCloud offload works beautifully so I
| don't know why they haven't added a trigger multiple years into
| that feature existing.
| jeffbee wrote:
| Good: much less disruptive than a regular macos update.
|
| Bad: still requires a reboot, and is still irrelevant noise for
| non-users of safari.
| objclxt wrote:
| > is still irrelevant noise for non-users of safari
|
| Safari vends an in-app view controller used by lots of third
| party apps to display web content.
| Dylan16807 wrote:
| Not many of those show arbitrary web pages.
|
| I guess it depends on what the bug is.
| olliej wrote:
| > Not many of those show arbitrary web pages.
|
| Plenty do display arbitrary _content_ thought. Mail
| clients, RSS readers, various messaging (twitter, mastodon,
| ...) clients, etc use it. Obviously these days many apps
| instead just ship a 400mb out of date copy of chrome
| instead of using the builtin frameworks, so it's less of an
| addressable problem, but so it goes.
| Dylan16807 wrote:
| A mail client is partway there, but is probably
| significantly filtering the html it allows.
|
| An RSS reader would be one of those few apps that might
| have the full risk.
|
| Messaging platforms have to worry about unicode bugs and
| image bugs, but almost all html or javascript exploits
| don't matter to them. If there is a safari-specific
| problem, it's very likely they don't care about it.
| olliej wrote:
| Mail clients do not filter html, that's a losing
| strategy, they use APIs on the rendering engine they use
| to prevent the engine from doing anything "bad" e.g. you
| don't try and filter JS, you tell the engine to not
| enable JS, you don't try to filter urls or resources by
| regex on the source, you use the engine APIs to manage
| resource loading yourself. Then it doesn't matter what
| absurd syntax or encoding is being used, if the engine
| thinks it should do a load, or run some scripts, it asks
| the host app.
|
| But it doesn't matter what proportion of the app
| ecosystem is or is not using the system webkit framework,
| we both know that if Apple does update only Safari say,
| and then people are compromised through their RSS reader,
| the HN comments will be asking why Apple didn't update
| the system framework.
|
| Don't get me wrong - I do get annoyed at having to
| reboot, but I'm not sure what the better solution is
| given the constraints of macOS and iOS (at least iOS apps
| are better designed in terms of saving and restoring
| state).
| Dylan16807 wrote:
| > Mail clients do not filter html, that's a losing
| strategy
|
| I mean that whitelist-style, which isn't a losing
| strategy.
|
| But that's a side issue. I'm trying to argue that the
| vast majority of programs that use webkit aren't affected
| by the vast majority of webkit-specific bugs.
|
| > But it doesn't matter what proportion of the app
| ecosystem is or is not using the system webkit framework,
| we both know that if Apple does update only Safari say,
| and then people are compromised through their RSS reader,
| the HN comments will be asking why Apple didn't update
| the system framework.
|
| I'm not suggesting not to update. But yes it does matter
| how many programs are vulnerable.
| smoldesu wrote:
| > Not many of those show arbitrary web pages.
|
| If I'm not mistaken, it is the renderer for many arbitrary
| pages like PDFs and Preview documents. Could be wrong
| though.
| pritambaral wrote:
| That still only requires a logout and login, not a full
| restart. In fact, it doesn't even require a logout, only
| restarting affected processes.
|
| I guess the software updater wasn't built to make those steps
| easy, so an OS reboot might've been the easiest way to ship
| this.
| xrisk wrote:
| IIUC, safari and other essential OS components are mounted
| on a read-only volume. The installer has to perform special
| shenanigans to update it.
| flangola7 wrote:
| > IIUC, safari and other essential OS components are
| mounted on a read-only volume
|
| I... what?
| [deleted]
| pcl wrote:
| If I Understand Correctly
| zamnos wrote:
| That's right. Safari is an application and so lives under
| /Applications, which is one a few special directories
| where the user can make changes, which actually live
| under /System/Volumes/Data in a scheme similar to unionfs
| under Linux.
|
| Which is to say, _/_ under Catalina and above (so, since
| 2019), the root partition is really the mount of an APFS
| snapshot. There 's security as a reason, but also from a
| system perspective, it makes it more robust to
| upgrade/downgrade OS versions under such a scheme because
| you always have a known-good system image to revert back
| to.
|
| Safari though is a special case, and so
| /Applications/Safari.app is a symlink to
| ../System/Cryptexes/App/System/Applications/Safari.app
|
| https://superuser.com/questions/1495124/read-only-file-
| syste...
| olliej wrote:
| As a basic security measure the macOS system partition is
| readonly and cryptographically signed.
|
| https://support.apple.com/guide/security/signed-system-
| volum...
| Operyl wrote:
| Yup, see page 51:
| https://help.apple.com/pdf/security/en_US/apple-platform-
| sec...
| r00fus wrote:
| Good defense in depth. Frustrating this requires an OS
| update & reboot, but I prefer that to weakening the
| defense model.
| MBCook wrote:
| > Bad: still requires a reboot
|
| This one does, but I don't think they all will. The language
| around it seems clear that's a possibility.
| gnicholas wrote:
| > _is still irrelevant noise for non-users of safari._
|
| Can you explain this more? Despite being a longtime Apple user,
| I've never heard of RSR before. If it's just an update for
| Safari, why does it require the computer to be rebooted? Does
| it not affect me if I use other browsers for 99% of my web
| usage?
| pjot wrote:
| RSR is a new feature.
| https://support.apple.com/guide/deployment/manage-rapid-
| secu...
| Amorymeltzer wrote:
| Indeed, here's the crucial quote:
|
| >Rapid Security Responses that involve the operating system
| require the device to restart. On macOS, the updated
| operating system content may be made available to Safari
| and its associated processes with just a relaunch of those
| processes, though a restart is required to make this
| content broadly available to the rest of the operating
| system.
| Malwheer wrote:
| Kernel patch requires a reboot. This will include important
| kernel fixes
| Amorymeltzer wrote:
| From the info page on apple (linked elsewhere here but
| https://support.apple.com/en-us/HT201224 and (no discussion:
| https://news.ycombinator.com/item?id=35776738))
|
| >They deliver important security improvements between
| software updates -- for example, improvements to the Safari
| web browser, the WebKit framework stack, or other critical
| system libraries. They may also be used to mitigate some
| security issues more quickly, such as issues that might have
| been exploited or reported to exist "in the wild."
|
| I believe they are vague on purpose (and because they're
| Apple) but it does not strike me as something strictly
| limited to affecting just Safari, especially given the
| libraries may be used elsewhere.
|
| ETA: To further quote from
| https://support.apple.com/guide/deployment/manage-rapid-
| secu...:
|
| >Rapid Security Responses that involve the operating system
| require the device to restart. On macOS, the updated
| operating system content may be made available to Safari and
| its associated processes with just a relaunch of those
| processes, though a restart is required to make this content
| broadly available to the rest of the operating system.
| Malwheer wrote:
| It almost certainly includes some kernel modification that
| was required. or it could be that the WebKit component that
| Safari and other applications use as an API layer needed to
| be patched and a reboot ensures all components running get
| the patch. There is also some sandboxing technology that is
| used for other things besides Safari and that is implemented
| in the Kernel.
| olliej wrote:
| If the bug is used in WebKit, then that's a system framework
| used by many apps on the system (and has been for well over a
| decade), not just Safari.
|
| However updating the system requires updating the system
| partition, which is readonly, so requires rebooting.
| bink wrote:
| The Safari libraries are used by tons of apps running on OSX.
| It's probably just easier to reboot than to ensure that all
| affected apps are reloaded.
| capableweb wrote:
| Are there apps using the Safari libraries running in the
| background? Sounds like something only user-facing
| applications would be using.
|
| Also, isn't one of the arguments for Apple's stronghold on
| all the software running on their machines that they know
| 100% what everything is doing? Should be trivial to look up
| which processes are using specific parts and restart those.
| olliej wrote:
| > Also, isn't one of the arguments for Apple's stronghold
| on all the software running on their machines that they
| know 100% what everything is doing?
|
| What stronghold? You can run whatever apps you want on a
| Mac.
|
| As for identifying libraries in use. you can do that on
| any platform: Pause all processes, scan the address space
| of all processes to find anything the looks like a
| pointer to an impacted library, then hope/assume that
| there's no pointer tagging or munging going on, and voila
| that's your list. Hopefully you didn't miss anything.
|
| The problem is that that's just a heuristic and you'd
| want to be _really_ sure you were right, or weird crashes
| will happen.
|
| On macOS specifically there are other hurdles, the
| biggest being that the system partition is readonly, and
| so system libraries can't be replaced outside of early on
| in the boot process.
| bink wrote:
| > The problem is that that's just a heuristic and you'd
| want to be _really_ sure you were right, or weird crashes
| will happen.
|
| Or worse, you leave running applications vulnerable to a
| critical security vulnerability while telling the user
| that they've applied all security patches.
| ikekkdcjkfke wrote:
| I feel like Android is much more modular in that regard,
| even the apps for the playstore is an app that can be
| killed/wiped essily from an all apps menu
| glhaynes wrote:
| How is it less disruptive than a regular macOS update?
| ddoolin wrote:
| Regular updates render the computer unusable while they are
| installing, I guess.
| jeffbee wrote:
| Yeah macos full updates spend 20 minutes doing ???? between
| reboots, no matter how fast your mac is.
| nmjohn wrote:
| This macOS update took < 30 seconds - opposed to most regular
| macOS updates which at the fastest are still 5+ minute
| operations
| egksgjegk wrote:
| [flagged]
| diebeforei485 wrote:
| Hopefully the learnings from this rollout will make future
| updates smoother.
| mrtksn wrote:
| Interesting, apparently this can be removed post install:
| https://i.imgur.com/gvbbU8F.jpg
|
| why would that be?
| LeoPanthera wrote:
| Maybe rapid security updates don't get much testing, so they
| allow you to remove it in case it causes problems? Just a
| guess.
| judge2020 wrote:
| To allow people to jailbreak? /s
|
| Probably to ensure someone can go back if this fix breaks
| functionality (which it shouldn't do).
| win32k wrote:
| If anyone thinks any non-Apple platform is more secure than
| modern iPhone/Macbooks running iOS/macOS, you are dead wrong.
| Apple's security is far ahead of other platforms.
| colechristensen wrote:
| OpenBSD is pretty damn secure.
|
| I think I've even seen an insane person with a marginally
| operational openbsd phone.
| astrange wrote:
| Their phone probably had at least 3 other RTOSes on it.
| Hardware security is more important than the main processor's
| OS when you have that many radios.
| smabie wrote:
| How would anyone even know? OpenBSD pretty obscure and
| unused. Payoff of attacking OpenBSD much lower.
| colechristensen wrote:
| OpenBSD _is_ used, but often in less visible ways, as are
| many of it 's subprojects.
|
| OpenSSH, for example, is an OpenBSD project and damn near
| everybody uses it.
| win32k wrote:
| Security is a lot more than just the OS. Modern iPhones have
| security chips that ensure the integrity of the main OS
| during boot and while running. A large part of Apple's
| security excellence comes from their hardware security
| integrated with their software/firmware.
| bink wrote:
| And they make the entire mobile industry more secure by
| showing what can be done, allowing others to follow suit.
| hospitalJail wrote:
| What makes you think there is excellence in security?
| Nearly every case involving Pegasus was on the iPhone.
|
| I believe this affected ~1000 VIPs and caused the death of
| at least 1 person.
|
| Either 0 VIPs use Android, or it is much harder to break
| into. (From my research, there wasnt any 0 click exploits,
| you always had to manually download something and approve
| it outside the play store)
| artificial wrote:
| 4 0days were just patched recently on Samsungs which
| targeted the baseband modem among a batch of 22.
| https://nakedsecurity.sophos.com/2023/03/17/dangerous-
| androi...
| themagician wrote:
| I sort of agree with the sentiment behind what OP is
| saying here, but perhaps not the way he is saying it. I'm
| not sure if I'd call it "security" as much as "system
| integrity." The model that Apple has moved to with the
| signed and sealed system volume is pretty interesting. I
| didn't even realize how much had changed with macOS until
| I was hunting around to change the startup wallpaper on
| Monterey and realized that macOS today is totally
| different from the macOS I remembered administering many
| years ago.
|
| UAC on a Mac has always been good, but now there is this
| new layer that even protects the system from the admin. I
| think the real risk with Apple's model is that there are
| these choke points now that, if compromised, can cause
| truly catastrophic failure--especially because of the
| false sense of security that's out there. If an Apple
| update server or signing certificate were compromised it
| would be a potential company ending event. Other
| ecosystems are much more fragmented, and there is some
| resilience baked into that. I remember a few years back
| when an OCSP server went down and internet connected Macs
| around the world ground to a halt. You couldn't open any
| application because it took 10 minutes for the server
| that verifies its certificate to time out.
| jupp0r wrote:
| Every single case involving Pegasus was a targeted attack
| by a state actor. This is a very different scenario to
| defend against than what corporations or private persons
| normally worry about.
| willcipriano wrote:
| Thank you Steve.
| voytec wrote:
| NSO would lose customers if iOS and Android were secure.
| Scoundreller wrote:
| NSO would lose customers if iOS and android were insecure
| because there would be a million competitors capable of doing
| the same job.
|
| NSO prefers devices to be 99% secure.
| win32k wrote:
| Yes. The whole existence of NSO shows that the iPhone is
| preeminent in platform security. No one pays hundreds of
| thousands of dollars to access an easily exploitable
| system.
| smoldesu wrote:
| FWIW, Zerodium still values Android zero-days higher[0]
| than iOS ones. Suffice to say that both parties pay
| hundreds of thousands to access their respective systems,
| to the point that companies like Greyshift sell standard-
| issue exploit hardware[1] for these devices now. Hacking
| your phone is a commercial field in the year of 202X.
|
| Both platforms are extremely vulnerable and actively
| exploited. Make of that what you will.
|
| [0] https://zerodium.com/program.html
|
| [1] https://www.grayshift.com/graykey/
| Scoundreller wrote:
| > Zerodium still values Android zero-days higher[0] than
| iOS ones.
|
| Partly due to more android devices out there than iPhones
| ex-US
| slillibri wrote:
| Like many others, I am unable to verify this right now.
| jasoneckert wrote:
| Security is a complex topic. While I don't disagree with your
| statement, I also don't agree with it. It's more realistic to
| say that "in recent years, Apple has clearly invested more in
| macOS security compared to the late 2010s."
| kweingar wrote:
| I'm biased because I work on ChromeOS, but Chromebooks seem
| extremely secure.
| NoZebra120vClip wrote:
| One of the cool advantages I was pondering is its greatly
| reduced attack surface. Linux and Android apps can still come
| in, but they're always really sandboxed and insulated from
| the main OS, which is little more than browser+UI. So as
| secure as you can make the browser, that's your OS security.
| The most a user can do is install PWAs on it; they're not
| going to have a bunch of userspace native apps causing
| trouble.
| fsflover wrote:
| I'm pretty sure that Qubes OS [0] is far more secure than any
| other desktop operating system: its security relies on hardware
| virtualization, which was broken last time in 2006 by the Qubes
| founder [1].
|
| [0] https://qubes-os.org
|
| [1] https://en.wikipedia.org/wiki/Blue_Pill_(software)
___________________________________________________________________
(page generated 2023-05-01 23:02 UTC)