8 ms·
Kernel RCE in iOS/macOS with ICMP
- microcolonel 8y agoWhy do I need JavaScript localStorage to look at a blog post? Edit: An indirect archive, because apparently archive.is does not allow localStorage access either. http://archive.is/yuIV5 http://archive.is/yuIV5
- saagarjha 8y agoTL;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 aside: > Even on a Mac, XNU is highly non-trivial to build. 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 :(
- 0x0 8y agoApparently it was actually already fixed in ios 12.0 and macOS 10.14.0 but retroactively added to the security notes for those releases only just now.
- saagarjha 8y agoThanks, updated.
- nixpulvis 8y agoand yet I always hear the argument, "but it's open source, just like Linux".
- deleted 8y ago[deleted]
- saagarjha 8y agoIt is open source, but not like Linux. These are more of source dumps than an actual window into the development process.
- derefr 8y agoPresumably, internally to Apple, XNU is built mostly on build-servers. Maybe even the branches having CI build-on-push, and test machines able to PXE-boot directly to a given branch's tip build. In such a case, you'd never need XCode to successfully build a standalone XNU at all.
- TheDong 8y agoDevelopers 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.
- derefr 8y agoIf 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.
- TheDong 8y agoChromium absolutely does not only build that way. I occasionally build chromium on my machine, and sure it takes two hours the first time, but incremental builds after that are only on the order of minutes. C++ code can be incrementally compiled... Sure, it's not as good as in many other languages due to headers being so heavy, but it's still a massive reduction in total build time.
- vlovich123 8y agoI 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).
- pcwalton 8y ago> 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 justify spending the effort. Linux hackers are spoiled… XNU isn't even one of the worst offenders. Try compiling Google's Skia, for example…
- lunixbochs 8y agoReally? I found Skia easier to compile than actually use.
- slimsag 8y agoI also found this to be true when I tried to use Skia.
- pcwalton 8y agoIt's probably gotten better lately. A few years ago it took me several days to get it built.
- pjmlp 8y agoSo it is not only me. On my case I ended up giving up and went back to Qt.
- pjmlp 8y agoOne needs to duplicate Google's build infrastructure, which is quite a pain versus other open source projects that rely on more mainstream tooling.
- hoaw 8y agoWhich would be fine if they provided some straight forward way to replicate that (like a container). It really seems like open source doesn't have that high of a standing at Google (anymore?). I guess limiting hardware manufacturers use of open source, not spending time making sure other people can build open source code, is what gives you the promotion these days
- xnyhps 8y ago> Heap buffer overflow in the network stack allowed for sending ICMP packets that would crash devices. It's not receiving an ICMP packet that causes the crash, it's when sending an ICMP error response packet. ICMP error packets can be generated in response to any type of IP packet, for example "host unreachable" when using UDP. These packets copy the original header of the packet which generated the error, which is where the out-of-bounds copy is. I understand why the author doesn't want to give full details, but in this case it leads to a lot of misunderstandings on how it works.
- AndyMcConachie 8y agoI understand it to be a classic buffer overflow using a memory copy. Bounds checking fails and a buffer is overflowed with bits from the attacker. The author was able to cause a kernel panic. This does not mean another attacker could not execute arbitrary code using this exploit. I expect to see a PoC soon with arbitrary code execution in kernel space on all unpatched MacOS/iOS devices soon. Which would be bad...
- wepple 8y agoCan 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?
- geogriffin 8y agoPretty sure it was introduced here: https://github.com/apple/darwin-xnu/commit/c10988c130af090877998fa56ed842575b841ff8#diff-9e767463d3d961f80f454adb3cdd9da3R279 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...
- sigjuice 8y ago> Copy-paste programming in core networking code... There is nothing special about core networking code.
- pjmlp 8y agoOther than being highly security sensitive, written in a language without any regard for security.
- geogriffin 8y agoMy thought specifically was that "core networking code" is code that handles untrusted, unsolicited data potentially from the entire world, written in C, with special performance requirements that gives programmers a license to eliminate redundant bounds checks wherever possible..
- jerf 8y agoThe Ping of Death rides again! Ok, yeah, not exactly the same, but humor me. It's a Halloween undead miracle!
- sigjuice 8y agoThis looks like a mundane bug and there are countless other undiscovered bugs like this. It doesn’t deserve this huge essay IMHO.
- tptacek 8y agoWell, you may not deserve the huge essay, sure.
- sigjuice 8y ago?? Not sure what you are trying to say.
- TheDong 8y agoRemotely 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.
- sigjuice 8y agoBecause these types of bugs are easy to make and miss?
- wahern 8y ago> 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/ 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.
- swang 8y agoDoes this affect all version of iOS before 12? Seems like some old iphones may fall out of use then if they're vulnerable.
- Klover 8y agoCorrect. iOS 11 devices can update to iOS 12, older devices are vulnerable.
- walrus01 8y agoHow 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?
- toast0 8y agoProbably a long time, Apple devices update frequently and in a generally timely fashion -- in a few months there won't be many vulnerable devices left (except for the ones apple won't release updates for)
- loeg 8y agoSo like, 30 seconds ago? :)
- kiallmacinnes 8y agoAs 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.
- pjmlp 8y agoMany public WiFis are managed by people buying some routers at the local store and plugging them in.
- weinzierl 8y agoAt the Chaos Communication Congress in 2010 (27C3) someone repeatedly crashed all Apple OSX Devices via WiFi. These things happen.
- PeterLGummybear 8y agoThe XNU networking stack is complete garbage in general. Have you ever seen all the crazy hard-coded stuff they have for different types of network mediums -- wifi vs cellular vs etc -- and in the kernel? It's bonkers. Plus a weird evolution of firewalls and ugh.
- deleted 8y ago[deleted]
- petre 8y agoIs there a fix for older OSX or should I just install Linux on my 2011 iMac? Yosemite is already quite slow. OpenSuSE 13.2 was really fast on a same generation Mac Mini.
- etatoby 8y agoGo ahead. After trying many options I settled on XUbuntu. But any of them will do. To bad, I liked the older OS Xes.
- galad87 8y agoIf you are behind a NAT, you won't receive ping from the Internet, so you are safe. And you can enable the firewall and "stealth mode" to make it ignore local pings. Your 2011 iMac can be update to 10.13, so I would update, a iMac 2011 with enough ram and a ssd works very well even on 10.13.
- jsjohnst 8y agoExcept it’s not a received ICMP packet that triggers the issue, it’s a TCP packet with large IP and TCP options. The crash occurs because the XNU kernel is sending an ICMP error in response to that received TCP packet.
- pjmlp 8y agoAnother day, another buffer overflow caused by C's memory model. At least ARM is getting pointer tagging.
- int0x80 8y agoCaused by Apple copy pasting networking BSD code, missing a crucial bounds check in the process (as noted by another reply ITT). Here: https://news.ycombinator.com/item?id=18351533 https://news.ycombinator.com/item?id=18351533
- pjmlp 8y agoWhich in a language with bounds checking would usually mean a panic instead of a memory corruption leading to possible exploit. Unless the same mistake would have been done inside an unsafe code block/module. If anything, C's history of memory corruption errors and how they come to be, proves that even the best aren't able to follow best practices that apparently all good C coders do. Linux kernel is full of such CVEs in spite of the approval processes in place to accept new code into the kernel, and I assume Apple does have similar practices in place.
- int0x80 8y agoYeah. C gives you little safety nets. But the problem here is a missing check. Do the same (logic mistakes) in Rust, Java, C#, JavaScript etc and you will, sooner or later, give access to your admin account, to your DB, to a command shell or to memory, writting not permitted values by omiting a validation check etc. I see your point, and I agree partly, some languages can avoid the particular secuence of events in this bug or make it more difficult. In this case, imagine: - Sloppiness getting code into the icmp module (this is speculation, to be fair). - Buffer overrun leading to RCE. - Solution: 1 You rewrite in rust because you think the root cause is that C is unsafe. 2 You don't write sloppy code, higher your standars, more audit/testing/verification. To me, if you don't fix #2, you are going to have big problems anyway even if you have safer tools.
- 8y ago
- cesarb 8y agoThe worst part, is that you just known some sysadmins are going to use this as an excuse to block all ICMP, worsening the PMTU blackhole problem; and the "these ICMP bugs were all from the 90s" argument won't work anymore.
- jsjohnst 8y agoExcept this isn’t triggered with an ICMP packet. All it takes to trigger the crash is a specially formatted TCP packet.
- unixpickle 8y agoReproduced the bug in Golang. Pretty simple stuff. https://github.com/unixpickle/cve-2018-4407 https://github.com/unixpickle/cve-2018-4407