To me this is quite depressing. The sure amount of bounds errors and whatnot in things like font handling, audio, images, etc mean that evil websites/email/etc have a strong chance of owning your device for years to come.
Highlights the value of languages like Swift or Rust that build in bounds checking into the language itself, preventing such attacks (as long as you don't call any explicitly unsafe bits). I do wonder if Apple is considering re-writing any of these core services in a safer language.
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
It still is C++ and way safer than plain C, assuming devs care to use RAII, reference parameters, string and array wrappers with bounds checking, enums.
And it all happens silently (in the background). You could very well have long random passwords with 2FA, but a device that's been pwned would render all that useless. Considering how much crucial data exists on my mobile, it's very depressing to see a long list of things that can compromise security.
It's written that they updated LibreSSL to version 1.17.0 (in the part HTTPProtocol) but the first version of LibreSSL is 2.0 and the last is 2.5.2 (https://www.libressl.org/releases.html).
iOS 10 supports the iPhone 5 which was released September 21, 2012 or about 4 1/2 years ago. If you're getting 4.5 years out of your iPhone, that's great. Unnecessary but great.
Importantly, the phone was sold until September 10, 2013. So someone buying on September 9, 2013 had about 3.5 years of support, which is still great, but notably shorter.
The iPhone 4S was an extreme case of this, where it was introduced in 2011, but was sold in India until 2016. Meaning it has some of the shortest or longest iOS support depending on when and where you bought it (0-5 years!)
My iPad Mini came out at the same time, but iOS 10 doesn't support it. I don't expect infinite support, but that felt like a pretty small window to me. I've gifted it and another to my younger relatives who are happy to play games on iOS 9.
5-10 years personally is what I think the minimum should be for security-related bugs.
Fact is, I'm probably never going to hold off on a phone for more than a year (I still have a 6S+), but I always hand-down my old phones. I can't use a 5-year old phone, but, others can and should still be able to do so safely.
What would make you think that 4.5 years of service of an electronic device is unnecessary? I have multiple devices that old or older and I hope very much that they will last way longer.
No, they are not updated by their manufactures. I wouldn't want that either. I'm receiving daily updates for my system, though, from the sources I choose.
I plan to never switch away from my iPhone 5S unless it breaks for some reason. It's a phone, why would I need anything new on my phone? I consider it pretty much perfect and it only gets better because now the value is so little, I dont have to be so scared anymore that it will be stolen.
Jesus, this reeks of a big company throwing programmers at a problem until it goes away. Myriad memory corruption issues all solved with input validation. Surely there has to be some kind of process improvements they could implement, at the very least fuzzing and valgrind (or similar). How do you not read this and want to rethink your strategy.
This is pretty terrifying. So many "arbitrary code execution with root privileges" exploits! They may be fixed, but how many more are still only known to malicious third parties?
And without even needing to install anything! "Processing maliciously crafted web content may lead to arbitrary code execution."
I can't recall so many (80?) security fixes in a recent iOS update. A malicious font, audio file, image file or website can cause arbitrary execution?! When a file parser or Safari is vulnerable, why doesn't the iOS sandbox block device/root modifications?
What happens if your device is already infected? Does the update process replace all OS files or could an infected device still contain malware after upgrade to 10.3?
Are there tools or apps that can report system level logs, e.g. could iOS 10.3 detect and report if known-malicious files are present on a device?
"may lead to arbitrary code execution" often means they didn't take the time to detect whether it does.
Reason is that it isn't worthwhile to spend time on that. Firstly, it is typically impossible to prove that a vulnerability cannot lead to arbitrary code execution (to do so, you would likely have to know _all_ vulnerabilities in your code), and secondly, defense in depth still requires plugging all holes, even if you can _now_ prove they just lead to an impregnable barrier.
And already infected devices very, very likely are safe after a reboot (the OS will only run signed code, and the malware isn't signed, or even considered code), but still may carry files that could infect systems running older iOS versions.
The sandbox does block such modification, but a useful exploit would combine the arbitrary code execution vulnerability with a sandbox escape, using e.g. some arbitrary read/write vulnerability in the kernel or similar.
In that case, would the list of iOS 10.3 security fixes mention at least one sandbox escape or kernel vulnerability? Since it does not, can we assume that most (all?) of the listed "arbitrary code executions" would be isolated by the iOS application sandbox?
Or should we assume that competent attackers are hoarding sandbox escapes and thus most app vulnerabilities can be escalated to device compromise?
No, you can't make any such assumptions from the text of the update. But you can probably assume there's localhost sandbox escape (or kernel RCE) available to serious attackers.
You're following security updates for flaws in an entire operating system and an entire browser. This is pretty much par for the course. Chromium has one of the best security teams and one of the best SDLC processes in the whole industry, and you'll see similar update stats for them if you watch closely.
My presumption with any technology is that there are security risks and issues. What is more concerning to me is the absence of information about these risks and issues.
Apple had a nice time for years while Microsoft acted as a honeypot for crackers. The absence of published problems for Apple products was merely an indication that crackers and researchers were not attempting to poke holes into the Apple ecosystem.
This is pretty silly. If your Linux machine gets owned up through an RCE flaw, you aren't going to be able to rely on the "transparency" of Linux to detect the attacker. Just like with Linux, iOS KRCE is game-over for casual detection.
Highlights the value of languages like Swift or Rust that build in bounds checking into the language itself, preventing such attacks (as long as you don't call any explicitly unsafe bits). I do wonder if Apple is considering re-writing any of these core services in a safer language.