Live data from Hacker News

Kernel RCE in iOS/macOS with ICMP

lgtm.com

31–40 of 68 posts

Re: Kernel RCE in iOS/macOS with ICMP

#31
post #21

This looks like a mundane bug and there are countless other undiscovered bugs like this. It doesn’t deserve this huge essay IMHO.

Remotely exploitable buffer overflows in kernels are fairly rare. > there are countless other undiscovered bugs like this How do you know that they exist if they're undiscovered? At this point, there are probably very few in linux after the level of fuzzing its received.

> At this point, there are probably very few in linux after the level of fuzzing its received.

Linux is heavily developed, which means significant code churn. It's a victim of its own success.

And there's much less fuzzing happening than you think. It's an on-again, off-again activity; not something that any particular organization (AFAIK) is rigorously and repeatedly performing on Linux for any serious length of time (i.e. years). Fuzzing isn't an automatic thing; it requires human intervention to help craft the tests so they reach and tickle the right corner cases. And if the code is constantly changing, you need to constantly review your tests.

Also, syscall fuzzing must be done differently from network fuzzing, for example. And fuzzing kernels in general is more difficult than, e.g., a self-contained library.

If you look at the Linux kernel CVEs, they've been steadily increasing over time: https://www.cvedetails.com/product/47/ We can quibble over the causes and significance, but I don't think those data points support your argument.

Yes, remote exploits in Linux are rare, just as they're rare in most operating systems, including macOS and Windows. But not rare enough. And there's little indication that they're becoming more rare. Unfortunately, I'll bet that the shift to eBPF to implement basic filtering and routing will cause a spike over the next few years.

At this point the Linux kernel is a lost cause. Everybody serious about security understands that the future is moving your most sensitive assets to secure enclaves not running general purpose OSs like Linux. Unfortunately those enclaves are recapitulating the same mistakes--too many features, too flexible, too much emphasis on adding more complexity to try to fix things. But one thing is certain, Linux is definitely not getting any simpler, and people are moving assets to slower moving train wrecks.

Re: Kernel RCE in iOS/macOS with ICMP

#32

TL;DR: Heap buffer overflow in the network stack allowed for sending ICMP packets that would crash devices. Bug was marked as "RCE" because it's possible that it could be used for code execution, though the current PoC only causes a crash. Bug has been reported to Apple and fixed in iOS 12 and macOS Mojave 10.14. There's an excellent drawing by the author at the end of the author summarizing the exploit ;) As an asid…

and yet I always hear the argument, "but it's open source, just like Linux".

It is open source, but not like Linux. These are more of source dumps than an actual window into the development process.

Re: Kernel RCE in iOS/macOS with ICMP

#33

Earlier quoted context omitted.

> I find it to be an extremely sad state of affairs when it requires scouring the internet for a blog post from a Darwin engineer to build an outdated XNU :( Large projects at companies tend to be hard to build, simply because it takes a lot of effort to make the build system for something so complex easy. If community contributions aren't particularly valued (which they aren't for XNU), then it's hard to internally…

Really? I found Skia easier to compile than actually use.

I also found this to be true when I tried to use Skia.

Re: Kernel RCE in iOS/macOS with ICMP

#34
post #31
post #21

Earlier quoted context omitted.

Remotely exploitable buffer overflows in kernels are fairly rare. > there are countless other undiscovered bugs like this How do you know that they exist if they're undiscovered? At this point, there are probably very few in linux after the level of fuzzing its received.

> At this point, there are probably very few in linux after the level of fuzzing its received. Linux is heavily developed, which means significant code churn. It's a victim of its own success. And there's much less fuzzing happening than you think. It's an on-again, off-again activity; not something that any particular organization (AFAIK) is rigorously and repeatedly performing on Linux for any serious length of tim…

> If you look at the Linux kernel CVEs, they've been steadily increasing over time [...] I don't think those data points support your argument.

The number of CVEs don't support any argument really. More CVEs are assigned, yes. That doesn't mean more security issues. In the olden days of 8 years ago, a buffer overflow would be patched with no fanfare and no CVE assigned. Nowadays, often only theoretically exploitable issues will still be given a CVE.

Re: Kernel RCE in iOS/macOS with ICMP

#35

Earlier quoted context omitted.

> I find it to be an extremely sad state of affairs when it requires scouring the internet for a blog post from a Darwin engineer to build an outdated XNU :( Large projects at companies tend to be hard to build, simply because it takes a lot of effort to make the build system for something so complex easy. If community contributions aren't particularly valued (which they aren't for XNU), then it's hard to internally…

Really? I found Skia easier to compile than actually use.

It's probably gotten better lately. A few years ago it took me several days to get it built.

Re: Kernel RCE in iOS/macOS with ICMP

#36
post #4

Can someone explain to me, did I miss the description of the actual bug here? I get there’s a copy, but why is there an under-allocation to start with? Or is that alloc somehow attacker-controlled? Was part of the copy func args controllable? Or was this just an ad?

Pretty sure it was introduced here: https://github.com/apple/darwin-xnu/commit/c10988c130af09087...

In this commit a bunch of code was copy-pasted from BSD into ip_icmp.c in icmp_error() to quote IP packet data in icmp error responses. Unfortunately they forgot to copy a line from the BSD source which would prevent the overflow:

  icmplen = min(icmplen, M_TRAILINGSPACE(m) - sizeof(struct ip) - ICMP_MINLEN);
m is allocated with a fixed-length buffer (mbuf), which means without that line above we can overrun it:

  m = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR);
Copy-paste programming in core networking code...

Re: Kernel RCE in iOS/macOS with ICMP

#37

Earlier quoted context omitted.

> I find it to be an extremely sad state of affairs when it requires scouring the internet for a blog post from a Darwin engineer to build an outdated XNU :( Large projects at companies tend to be hard to build, simply because it takes a lot of effort to make the build system for something so complex easy. If community contributions aren't particularly valued (which they aren't for XNU), then it's hard to internally…

I don’t see why compiling XNU needs to be more complicated than 1. install the compiler (easy to do just by typing ‘cc’ on a pristine Mac) 2. Type ‘make’

That’s not how software teams work unfortunately.

There’s probably three build systems and none of them work on certain days of the week and the guy who wrote it all left six months ago.

Re: Kernel RCE in iOS/macOS with ICMP

#38
post #37

Earlier quoted context omitted.

I don’t see why compiling XNU needs to be more complicated than 1. install the compiler (easy to do just by typing ‘cc’ on a pristine Mac) 2. Type ‘make’

That’s not how software teams work unfortunately. There’s probably three build systems and none of them work on certain days of the week and the guy who wrote it all left six months ago.

For XNU? Doubt it. It's probably all on XBS and has multiple people maintaining the build system.

Re: Kernel RCE in iOS/macOS with ICMP

#39
post #12
post #11

Earlier quoted context omitted.

Developers of course never wish to compile a 5 line patch locally and launch a kernel in a VM to test it. That's something practically every linux kernel dev does, but surely every time a XNU dev wants to add a single debug print statement, they'll go through the whole CI system before being able to run it.

If XNU can't be built incrementally (and, not having built it myself, I'm unsure whether it can, since it contains a large amount of C++), then it's going to take just as long, if not longer, to build it on your workstation, compared to going through the CI pipeline (with the beefy build-boxes.) So there's no disadvantage in a CI-only workflow in such a case. IIRC Chrome has this workflow for this reason.

I promise you incremental builds are extremely important. A completely clean build of iOS/OSX years ago would take multiple days & I'm sure it's only gotten worse. The entire internal CI system relies on incremental builds working properly so that they can generate an internal iOS build every day for testing. It's possible it's disabled for certain projects but I doubt it. C++ in no ways alters the incremental build mechanism; all the problems of incremental builds it inherited from C's preprocessor. Speaking of, that's what C++ modules fixes (clang has support for C & C++ there although when I left only C projects had it on).

Re: Kernel RCE in iOS/macOS with ICMP

#40

How long until somebody builds a device that is basically a pwnplug, which joins wifi networks at major tech conferences, does an nmap for live IPs, and sends this to every device?

As an aside, well ran conference WiFi (and public WiFi in general) won't allow attendees to contact each other over the WiFi network - they will only allow traffic from end user devices towards the gateway, and won't allow hairpin routing on that gateway.

I wish more public WiFi was well ran, as many of these same network attacks wouldn't have an opportunity to work in the first place.

Post reply on HN