About the security content of iOS 10.3(support.apple.com)
support.apple.com
About the security content of iOS 10.3
https://support.apple.com/en-us/HT207617
45 comments
And it is not an unknown thing, for decades!
"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."
-- C. A. R. Hoare, Turing award lecture in 1981, http://cacm.acm.org/magazines/1981/2/10949-the-emperors-old-...
> I do wonder if Apple is considering re-writing any of these core services in a safer language.
Apple already uses C++ for device drivers, which allows for more safety oriented programming as straight C.
In any case, even if it isn't fully ready today, they view Swift as a C and Objective-C replacement in the long term.
"Fast. Swift is intended as a replacement for C-based languages (C, C++, and Objective-C). " -- https://swift.org/about/
"Swift is a successor to both the C and Objective-C languages." -- https://developer.apple.com/swift/
The dock and launchd in Sierra were rewritten in Swift.
"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."
-- C. A. R. Hoare, Turing award lecture in 1981, http://cacm.acm.org/magazines/1981/2/10949-the-emperors-old-...
> I do wonder if Apple is considering re-writing any of these core services in a safer language.
Apple already uses C++ for device drivers, which allows for more safety oriented programming as straight C.
In any case, even if it isn't fully ready today, they view Swift as a C and Objective-C replacement in the long term.
"Fast. Swift is intended as a replacement for C-based languages (C, C++, and Objective-C). " -- https://swift.org/about/
"Swift is a successor to both the C and Objective-C languages." -- https://developer.apple.com/swift/
The dock and launchd in Sierra were rewritten in Swift.
> Apple already uses C++ for device drivers, which allows for more safety oriented programming as straight C
Just to qualify that a bit, IOKit uses a restricted form of C++ based on Embedded C++
https://en.wikipedia.org/wiki/Embedded_C%2B%2B
https://developer.apple.com/library/content/documentation/De...
Just to qualify that a bit, IOKit uses a restricted form of C++ based on Embedded C++
https://en.wikipedia.org/wiki/Embedded_C%2B%2B
https://developer.apple.com/library/content/documentation/De...
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).
How did they do ?
How did they do ?
They are referring to nghttp2's version .
The takeaway here is that if you have a device that's so old it's not supported for iOS 10 updates, it's a doorstop.
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.
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.
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.
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.
Isn't the more relevant date when they ceased sale of the iPhone 4S, which was September 2014 (2½ years ago)?
No, because if you bought a 4S at that point you knew you were buying a 3 year old device.
I expect support periods for my device to start when I bought it from the manufacturer, not when it happened to first go into production.
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!)
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!)
Posting this from an otherwise finen, iOS 9 only, iPad 3.
> Unnecessary but great
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.
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.
4.5 years out of an iPad though, is completely doable. I've given up on my iPad 2 because it's too slow now, but other than that it's absolutely fine.
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."
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?
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?
Perhaps a scanner could be run on an iPhone backup directory (on disk on your Mac/PC).
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?
Or should we assume that competent attackers are hoarding sandbox escapes and thus most app vulnerabilities can be escalated to device compromise?
"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.
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.
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.
This is the opposite of terrifying for me.
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.
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.
[deleted]
[deleted]
Sometimes Safari on iOS will freeze and I wonder what's happening.
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.
I wasn't aware that Carbon was there in iOS.
I imagine none of the GUI stuff, but drivers and other C stuff
I imagine none of the GUI stuff, but drivers and other C stuff
Well looking at the bug it seems like it at least is used to support loading old TrueType fonts...
It's extremely impressive how many of these bugs were found by Google's Project Zero team.
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.