https://nvd.nist.gov/vuln/detail/CVE-2011-0227
https://nvd.nist.gov/vuln/detail/CVE-2015-1097
https://nvd.nist.gov/vuln/detail/CVE-2015-5843
https://nvd.nist.gov/vuln/detail/CVE-2016-4654
The 0-days will continue to drop on a regular basis until OS vendors embrace widespread memory safety as something that's vitally important to more than just a handful of dissidents and journalists.
edit: parent comment previously said "Makes me wonder how secure iOS really is", which is what I was responding to.
Apple have created and embraced an entire language (Swift) around the idea that things like memory safety are important, but you cannot just rewrite an entire operating system overnight into a new language.
Swift is not (currently) a viable replacement for C.
I'm not saying they should rewrite the entire OS immediately, but: given the pace at which they're able to pump out new marketable features; the massive deployed base of iOS devices; and the sensitivity of the data that is kept on those devices, I would argue that they damn well better have a long-term plan to replace their bug-ridden kernel and other important low-level systems, with code that isn't vulnerable to classes of bugs that have been solved for decades and are frequently exploited in the wild. And I'm not just talking about Apple here.
[1] https://support.apple.com/guide/security/memory-safe-iboot-i...
I think they are slowly going in that direction, e.g. by moving drivers to user space with DriverKit (which AFAIK unfortunately, still uses C++).
Presumably because they also said
> iOS is hundreds of millions of lines of C and C++
and Apple did write a whole new operating system that way not so long ago despite the well-known safety issues of doing so. If any company in the world has the resources to incrementally rewrite an entire operating system with huge numbers of active users today so that the attack surface becomes progressively smaller, it's Apple.
It's not as if no-one knew about the dangers of writing security-sensitive systems in C or C++ in 2007 or as if the Internet was some new idea where no-one understood that bad people would try to remotely compromise your system using it. Apple might not yet have realised how important the iPhone was going to become back then but they were doing very well by a decade ago and they were huge by five years ago.
Maybe in 2007 it made sense to build iOS on an existing platform and use the normal systems programming languages. Why couldn't more recent development of potentially vulnerable components have been done using safer technologies though?
Take a look at the long list of security issues fixed by last week's iOS 14.7 update[1] and tell me how many of the vulnerable systems could have been written or rewritten to use more secure technologies. Look for terms like "use-after-free", "buffer overflow" and "out-of-bounds read".
Then there is the iOS 14.7.1 update we're discussing today. Yet again this seems to be about fixing a memory corruption issue in a kernel extension written in an unsafe language that has a track record of exposing vulnerabilities. When do we start learning from those mistakes?
[1] https://www.cybernewsgroup.co.uk/apple-issues-urgent-iphone-...
Multics had a DoD validated security profile higher than any UNIX, it was written in Acme Corporation PL/I.
The original Mac OS and Lisa were written in Fluffy Object Pascal.
Apparently many airplanes get to fly in a toy language created around 1983.
....
Now notice the companies behind all the major browsers and the companies behind most of the popular recent programming languages are basically the same set, and join the rest of us in wondering how this is still happening.
Why would that be vitally important? They are a business selling lifestyle and technology. For them vitally important is staying in a profitable business. I think we can agree that we're past the point where we can believe that these vulnerabilities threaten that. These vulns mean to them, I think, only risk. Mitigation will come in a form of some patches, and some PR. And the world will go on, continuing to circulate these phones.
It's important in the same way that phasing out ICE cars is important -- important for society, but unlikely to happen in a timely manner without regulation.
Here's a fun strawman: the EU or California could announce limits on the sale of products relative to the number of lines of memory-unsafe code used to build them, starting in a few years.
So iOS is very unlikely to be "hundreds of millions of lines of C and C++".
And frankly I think they’re being generous to you; writing a frame buffer is even more complicated than their estimation.
The complexity is not the same. My grandfather is not questionning my ability to fix his computer that “breaks” once in a while just because I already fixed it the last time.
I don't care how complex the vulnerability is. The consequences I do.
Pretty much every operating system has some fun places near its core that are a steady stream of problems.
Also the software in question is a complicated subsystem to write on a platform that’s guaranteed to get many eyeballs on. So the fact that those CVEs span roughly once per year might also be a demonstration that there are relatively few bugs (if we knew the number of people and time spent researching vs CVEs published then maybe we’d have a more meaningful statistic).
CVEs do also demonstrate that active research is happening. There are plenty of common libraries out there that never get audited. Does fewer CVEs mean they’re more secure? Or does it just mean that nobody has checked?
Thus on its own, that data is pretty meaningless in terms of deriving a trend.
The reason the LoC comparison was made is because measuring lines of code doesn’t tell you how long a developer has spent debugging, reading documentation, or doing other research required. It doesn’t tell you how secure, performant, or even buggy the code is. All it tells you is the number of lines written and literally nothing more can be derived from that figure. Likewise with CVEs submitted.
However I have written a more in-depth reply about why counting CVEs is meaningless here:
Display controllers are complicated (and Apple ones are especially so, with all their fancy features).