Hacker News Reader

Comment by SheinhardtWigCo | Hacker News Reader

iOS is hundreds of millions of lines of C and C++, with immeasurable ways to feed in untrusted inputs. In that setting, it's guaranteed that there will be a constant supply of remotely exploitable memory corruption bugs.

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.

View on HN

Is the implication here that Apple doesn't value memory-safety? Why would you say that?

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.

I didn't say that. Their MacGyvered memory-safe iBoot implementation [1] shows that it's at least a consideration and that they're exploring ways to shore up vulnerable components.

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...

they damn well better have a long-term plan to replace their bug-ridden kernel and other important low-level systems

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++).

Is the implication here that Apple doesn't value memory-safety? Why would you say that?

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.

iOS was a stripped down MacOS. It has evolved since then, but that was the core and much of the user space code. All of that came from NextStep which was based on the Mach kernel and BSD from the late 80s. So, no Apple did not write a whole new operating system in this millenium.

Fair enough, it's true that they didn't start from scratch, but iOS today has evolved far beyond those original borrowed elements and is now much more than just a kernel and some early shared user space code. Even if that were not the case, it is still surprising that a company with Apple's resources would continue to favour writing new parts of iOS the same way 14 years after its first release.

What new operating system has Apple written recently?

iOS. I realise it feels like smartphones have been ubiquitous forever, but iOS is actually only 14 years old (and obviously most of the code in it is far younger).

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.

iOS reuses the XNU kernel from macOS, so most of its code is far older than that. And even in 2007, what good options were there for writing kernels? Most of the attempts in memory-safe languages were just toys.

Right, but it's not 2007 any more. Apple has more technical and financial resources available to it than many small countries. Memory-safe languages aren't toys now. Even if they still were, Apple could have built a better one from scratch.

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-...

Apparently the NEWP toy used by Unisys to write their high secure profile OS is an aging grandpa language from 1961.

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.

....

I believe (unsure about this) that it reused a reasonable amount of userspace macOS code as well, perhaps to do fonts and the like? i have to imagine most of e.g. webkit was also taken from macos.

If it wasn’t true when iOS was launched, it’s certainly true now.

Clearly they don't care enough to force their own employees to use it, which is how we got the absolute utter crap that is a proprietary 802.11 protocol implementation in the kernel and the endless streams of ObjectiveC userland exploits.

Agreed. What makes this worse is that apparently a single component is responsible for so many vulnerabilities over the past ten years. One would hope that over the years this component would’ve gotten thorough reviewing and have hardening added to make it less exploitable.

Looking at web browsers it doesn't matter how much reviewing and hardening you do, some of this just can't be 100% secured.

It's probably not realistic as long as you insist on writing such a complex and externally accessible application in a relatively low-level and error-prone programming language. Remove that constraint and the odds change considerably.

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.

>something that's vitally important

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.

Fair question, it's a shame you're being downvoted for it. I do agree that there is no apparent profit motive to do much more than lip service and short-term damage control, although Pegasus might start to change that, we'll see.

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.

I agree. That'd be fun! They could introduce a limit and if the product doesn't pass the limit, is outdated or anything, then it gets an ugly Unsafe sticker on the product box. Stickers could be mandated regarding the cloud usage of the device too: This one phones home to China, this one to Russia, this one to the USA. Let the people know.

The linux "kernel" is 30 millions lines of code, with the majority of the lines being used for a zillion different drivers.

So iOS is very unlikely to be "hundreds of millions of lines of C and C++".

You're comparing a kernel to a full graphical OS though with tons of included apps and frameworks.

iOS is the OS of the device, and while it does include frameworks, it does not include apps like Apple Maps or Safari.

That's not how things work. Apps aren't just the end app that you use, but the frameworks that create them that are part of the OS SDK.

Reply on news.ycombinator.com