Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kernel RCE in iOS/macOS with ICMP

lgtm.com

Post reply on HN
Print view View original

11–20 of 68 posts

Re: Kernel RCE in iOS/macOS with ICMP

#11

Post by TheDong »

derefr wrote: post #10
saagarjha wrote: post #3

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…

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

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.

Re: Kernel RCE in iOS/macOS with ICMP

#12

Post by derefr »

TheDong wrote: post #11
derefr wrote: post #10

Earlier quoted context omitted.

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

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.

Re: Kernel RCE in iOS/macOS with ICMP

#16

Post by throwabayhay »

derefr wrote: post #10
saagarjha wrote: post #3

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…

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

Nah. What you say is partly true, but I and others build xnu locally and incrementally all the time. Fast enough.

Re: Kernel RCE in iOS/macOS with ICMP

#17

Post by pcwalton »

saagarjha wrote: post #3

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…

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

Re: Kernel RCE in iOS/macOS with ICMP

#18

Post by throwabayhay »

throwabayhay wrote: post #16
derefr wrote: post #10

Earlier quoted context omitted.

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

Nah. What you say is partly true, but I and others build xnu locally and incrementally all the time. Fast enough.

If you want more details: Lots of parts are obviously pure C, but in my experience the C++ stuff is usually quite incremental as well. Changing a header included in lots of places is the obvious multiplier to build time.

Linking does take some time, but it’s only really noticeable if you do very incremental changes (e.g. change a single value, build, boot, repeat).

Overall, building a whole kernel from scratch even for multiple configurations is not unbearable during normal development.

Re: Kernel RCE in iOS/macOS with ICMP

#19

Post by TheDong »

derefr wrote: post #12
TheDong wrote: 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.

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

Post reply on HN