Apple pushes first-ever 'rapid' patch – and rapidly screws up Apple on Monday pushed to some iPhones and Macs its first-ever rapid security fix. This type of patch is supposed to be downloaded and applied automatically and seamlessly by the operating system to immediately protect devices from exploitation, thus avoiding the usual system update cycle that users may put off or miss and …
... marred by confusing versioning. It's supposed to be an imitation of Android security patch levels, but the Android versioning by date is much more obvious than three point numbers and a letter.
If only the Android security patch system worked though. The outdated Android version problem that it set out to solve never got solved.
Why do you believe "it is supposed to be an imitation of Android security patch levels"?
The version number is just like any other iOS patch, except for the 'a' at the end. I assume that's to denote that it isn't a "full" 16.4.1 but just the targeted fixes. Not sure if that means that if they had another one next week it would be 16.4.1 (b) or 16.4.2 (a) or if there might be a "full sized" 16.4.2 (if not now, someday later following one of these rapid patches)
Anything that gets patches on my phone more quickly for something that's been observed in the wild is a good thing as far as I'm concerned. Sure, these attacks are probably targeted at the type of people who might be targeted by actors deploying NSO software or similar so the chance it will matter to me is almost zero, but better safe than sorry.
Because the concept underlying the two is identical: rapid deployment of fixes for vulnerabilities being exploited in the wild, independent of OS versions.
The versioning confusion between full and partial iOS versions is exactly why this versioning scheme is a bad idea :P
The versioning confusion between full and partial iOS versions is exactly why this versioning scheme is a bad idea
What confusion? You can't claim there is confusion when we don't know how the numbering will work. If they only use a given release number then there's no confusion. If they do something dumb like release a 16.4.1 after a 16.4.1 (a) then yes you can claim there is confusion. But now there is none, you can just ignore the "a" and just look at the number as always. The only difference being that a patch with "a" will download/install faster (and is presumably more important that you install it ASAP)
In Oz my iMac had a message on the screen this morning suggesting that I restart it now (or later). Seems OK. Then did 2 iPad Pro's and 2 iPhones. All went well, except Mrs Tim99's iPhone which had a flat battery - Recharged to ~5%, then had to manually request patch, but needed an additional restart to avoid "Update Later" as the only choice, now OK...
It applied, blew the wireless NIC into noop zone.
Downloaded the drivers and sneakernetted the damned things over via USB drive, which I first had to build, as my last one had failed hard, got the NIC working. Annoyingly, the laptop didn't have a wired NIC, so everything was wireless.
For the next patch to do the same damned thing.
Got it fixed that time, well, until the next patch munges their own drivers again and the chipset manufacturer's drivers...
But now, I've working USB flash drives to spare again. And an extra fine fireaxe.
Automatic updates - while good in theory - are rarely as good in application. While this screw-up only resulted in a few stray internet availability error messages, there is a long history of bricked devices (personal assistants, etc..) that have resulted from this "good in theory" idea. I've always found it far better to not let anything touch my devices until I review what will take place and give it the nod.
So long as you are reasonably diligent on updates, the risk of you being exploited between the time some company issues a fix-all "automatic update" and when you normally look for updates is quite low. On the iPhone, how hard is it? There is a big red-dot that appears over the settings apps when updates need attention.
But that means the gap is there.
Often I find the update only by seeking, Apple’s idea of automatic must mean slowly staged as I’m often seeking. It doesn’t change that the patch is out for a couple of days or more before I see it.
Have three iThings, my phone is the seeker.
The proponents of auto-updating seem to think that software is flawless.
So it is a balance between being exposed to malware or whatever for a time til I choose to review and update, and being exposed to someone buggering up the update process. Waiting helps me reduce the problems of the latter, or at least do it at a time convenient to me, notably after making a backup.
I've deliberately ditched software that auto updates... Brave, Zoom, and Microsoft Office (which you can turn off auto updates, but that doesn't stop the auto-update application itself auto updating itself... sigh) amongst others.
But is it?
A bad update leaves you without the device at all, so you don't want to be among the first few thousand.
An exploitable hole is only an issue if it is exploited. Once a patch is released, exploits will likely become available after a few days to weeks.
So logically, you always want to wait a few days before updating.
The proponents of auto-updating seem to think that software is flawless. ... just as cloud-computing-for-everything* and web-forms-for-everything** advocates seem to think Internet connectivity is flawless. How can so many otherwise-smart people be so stupid? (Or arrogant, or whatever the heck their problem is.)
*Cloud computing is excellent for a very limited set of applications.
**I hate web-forms. If you can't understand why, try filling out a long, web-based employment or insurance form almost to the end when the cat leaps and knocks over your cablemodem which then parts ways with its power connector. And there are many ghost-cats haunting comms closets and switching centers, just aching to sink their needle-teeth into some juicy, mouse-flavored CAT-6, or waiting to pounce claws-out onto some techie's neck and make them fat-finger something critical. (FWIW that's my theory.)
"Automatic updates - while good in theory - are rarely as good in application."
As someone who did a lot of software system testing and a lot of development, let me say that testing is by far the more difficult of the two worlds. It's no surprise to me that updates often don't work right. Lots of reasons, but one big one is that it is often quite impractical to test patches against all the possible user configurations. So yeah, sometimes "they" didn't really test against your use case. The other big one is that developers and testers often don't actually know what users are using their software to do or exactly how it is being used. In my experience users are astonishingly good at finding ways to use software that may be quite different than the developers have in mind. When that happens it's really easy to break the user's workflow. Users generally don't like that.
Two opposing world views: "What could possibly go wrong (WCPGW) with this simple fix?" on one hand. "Whatever can go wrong will" (WCGWW) on the other.
WCPGW folks tend to feel that updates are out there for a reason and that failing to install them promptly is incredibly risky. WCGWW folk on the other hand feel that blindly installing updates is asking for trouble. Not a lot of middle ground there.
I tend toward WCGWW myself.
Some sorts of errors (buffer overflow, array-bounds overrun) can be fixed indpendently of the user interface. Some sorts of errors can be quickly-Bondoed*-over, but not truly fixed without investigation into the root cause of the problem, or problem-group, and thinking about it.
If you have the symptom that "holding down Windows+Alt+Umlaut on German keyboards bypasses MSGINA and auto-logs the user into the Windows box as local admin", you can Bondo it over by writing code which modifies MSGINA to filter any key-combo containing an Umlaut. Unless you have a warehouse-sized testing facility with every possible keyboard, "testing" is not likely to catch the fact that it isn't just Umlauts, but also Cedillias on French, Catalan and Portuguese keyboards, and Myakizhnak on Russian, Ukranian, and Bulgarian keyboards, and (etc. ...). Only thinking will bring the realization that the problem is a problem-group, and the root cause was that whomever originally wrote MSGINA presumed its input would be only 7-bit ASCII**, and the proper fix is to revise MSGINA to deal with all key-code combos, if it practically can be, or re-writing it if not.
Testing is not enough. Thinking and code review is required to boost code quality.
*"Bondo" is an automobile dent-repair paste which is used to fill in small dents, and then painted-over.
**This is a made-up problem with a made-up root cause.
Back in the day Windoze would apply updates at the end of the day. Seems like a good idea.
Except it would only tell me that it was going to do that when I shut down, at which point it would take 10 or 30 or 60 minutes installing updates with a big message 'do not unplug computer while updates are being applied' while I was wanting to leave the office with my laptop in my bag. And you couldn't tell it 'not right now, just shut down please'.
Pulling the battery out solved the problem nicely.
Applying this patch was a heart-stopping experience - not only did it complain about being offline so that it couldn’t proceed with the verification (it was online until it decided to verify), once the process got underway it restarted and demanded my password…. but without the screen keyboard! The keyboard only retuned after several minutes. Whoever made this sure got a laugh out of this user!
I'm guessing that is for these reasons:
1. limiting to latest version means there's only 1 element in the update
2. ... therefore much quicker to develop and test; download and install
3. ... which is what you want with a live exploit and a "hard push"
I really, really don't like the way this is going.
My device is my device. That means I get to decide what happens to it. And yes, if I fail to apply an update and it gets exploited, I end up in trouble; but I want to make the decision to solve it or not.
Any device that allows another entity to make critical system-level changes without consulting with you, isn't your device.
Then turn it off. If automatic updates are off, then you won't install it unless you push the button. The "rapid" part of the name is just because it no longer needs to send a full OS image, so it's quicker to develop, test, and download. It doesn't make it mandatory if you have disabled that switch.
I have automatic updates turned off, because Apple has burned me too many times before. And not only was this particular patch not installed without my knowledge, Nanny Mac isn't even nagging me about it. There's no accusatory red dot, no pearl clutching pop ups. I will (manually, thank you) apply it in a few days once it is a little more stable. Which is not to deny that Apple is indeed run by a bunch of control freaks and you are right to be concerned and vigilant.
I discovered this morning that my MacBook Pro rebooted overnight. I assume this means I Got The Patch. At first, Mac would not accept my password. Several tries later, I restarted the machine and that convinced it to accept my password. Then I discovered that an external, thunderbolt-connected disk drive would not mount - it has a fatal error.
"Problem -69842 occurred while restoring the original mount state."
I ran a Disk Uitility check on it, several times, and no joy.
I unplugged the disk, and no joy.
I am to the point that I must reformat the drive and recover from Time Machine.
This feels exactly the way that Windows used to feel. Congrats, Apple!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
