Apple Kernel Code Vulnerability Affected All Devices

Another day, another vulnerability. Discovered by [Kevin Backhouse], CVE-2018-4407 is a particularly serious problem because it is present all throughout Apple’s product line, from the Macbook to the Apple Watch. The flaw is in the XNU kernel shared by all of these products.

This is a buffer overflow issue in the error handling for network packets. The kernel is expecting a fixed length of those packets but doesn’t check to prevent writing past the end of the buffer. The fact Apple’s XNU kernel powers all their products is remarkable, but issues like this are a reminder of the potential downside to that approach. Thanks to responsible disclosure, a patch was pushed out in September.

Anatomy of a Buffer Overflow

Buffer overflows aren’t new, but a reminder on what exactly is going on might be in order. In low level languages like C, the software designer is responsible for managing computer memory manually. They allocate memory, tagging a certain number of bytes for a given use. A buffer overflow is when the program writes more bytes into the memory location than are allocated, writing past the intended limit into parts of memory that are likely being used for a different purpose. In short, this overflow is written into memory that can contain other data or even executable code.

With a buffer overflow vulnerability, an attacker can write whatever code they wish to that out-of-bounds memory space, then manipulate the program to jump into that newly written code. This is referred to as arbitrary code execution. [Computerphile] has a great walk-through on buffer overflows and how they lead to code execution.

This Overflow Vulnerabilty Strikes Apple’s XNU Kernel

[Kevin] took the time to explain the issue he found in further depth. The vulnerability stems from the kernel code making an assumption about incoming packets. ICMP error messages are sent automatically in response to various network events. We’re probably most familiar with the “connection refused’ message, indicating a port closed by the firewall. These ICMP packets include the IP header of the packet that triggered the error. The XNU implementation of this process makes the assumption that the incoming packet will always have a header of the correct length, and copies that header into a buffer without first checking the length. A specially crafted packet can have a longer header, and this is the data that overflows the buffer.

Because of the role ICMP plays in communicating network status, a closed firewall isn’t enough to mitigate the attack. Even when sent to a closed port, the vulnerability can still trigger. Aside from updating to a patched OS release, the only mitigation is to run the macOS firewall in what it calls “stealth mode”. This mode doesn’t respond to pings, and more importantly, silently drops packets rather than sending ICMP error responses. This mitigation isn’t possible for watchOS and iOS devices.

The good news about the vulnerability is that a packet, malformed in this way, has little chance of being passed through a router at all. An attacker must be on the same physical network in order to send the malicious packet. The most likely attack vector, then, is the public WiFi at the local coffee shop.

Come back after the break for a demonstration of this attack in action.

Continue reading “Apple Kernel Code Vulnerability Affected All Devices”

Linux, Without The Git Factor

Linux started as a student project in the 1990s, the creation of Linus Torvalds. He has attained celebrity status while steering his creation through the decades, but along the way he has also attracted a different reputation within the Linux and software community. He is famous for his outbursts and rants, some of which become rather personal, and it is not difficult at all to find kernel developers or would-be kernel developers who have turned their backs on the project as a result.

It’s very refreshing indeed then to read an update from [Linus] as part of his regular communications, in which he admits that he has an issue, and says that he is taking the time to seek help for it. There is an accompanying update to the kernel maintenance code of conduct, which suggests that this is likely to mark a sea-change in that environment, as well as we hope salvage that aspect of [Linus]’ reputation.

“My flippant attacks in emails have been both unprofessional and uncalled for. Especially at times when I made it personal. In my quest for a better patch, this made sense to me. I know now this was not OK and I am truly sorry.”

The Hackaday community has a much greater than average proportion of Linux users among its readership. Even those readers who use a desktop OS with BSD, Windows, or other kernels will almost certainly have a Linux kernel somewhere, whether it’s in their phone, their set-top-box, their children’s toys, or even their domestic appliances. And of course a large swath of the Internet runs on Linux. It is in the best interest of us all that we continually attract and retain brilliant people to contribute to the effort put into developing and maintaining the Linux kernel.

Without wishing to lionise [Linus] above the many others whose work has also contributed to Linux and its success, his contribution to our community has been beyond measure and it has been uncomfortable to see his other side. It’s a step in the right direction to apologize for personal attacks and behavior that drives a wedge into the kernel developer community, and seek to change that behavior. We’d urge others to follow his example, we’re sure every grouping has at times had its personality problems, and it’s never too late to enact some repairs.

While Linus steps away to work on his self improvement, veteran kernel developer Greg Kroah-Hartman will take the reigns among the kernel maintainers.

The rust language logo being branded onto a microcontroller housing

Pun Intended: Bare Metal Attracts Rust

Programming languages tend to polarize, and Rust is by far no exception. Whether it will stick around and grow as an alternative for the lower levels or not — time will tell. In the meantime, if you’re curious about the language and its low-level abilities yourself, [phil-opp] has written a series of blog posts on building your own little bare metal kernel in Rust.

Starting from the basics, [phil-opp] describes in detail the set-up and build process to create a standalone executable that won’t be linked against the Rust standard library. From here he proceeds to build a simple operating system kernel that prints a good old Hello World via VGA output — QEMU emulation included. And of course, there is a GitHub repository with all of the source code.

[phil-opp] has been working on this for a while already, and he is currently writing the second edition of the series. Some content is therefore still missing, but you may find more of it in his first edition. And in case you know absolutely nothing about Rust in the first place, let’s just take a step back and start with the basics. After all, we might see more of it in the future.

Under The (Linux) Hood

We’ve often heard that you don’t need to know how an engine works to drive a car, but you can bet that professional race car drivers know. By analogy, you can build lots of systems with off-the-shelf boards like Raspberry Pis and program that using Python or some other high-level abstraction. The most competent hackers, though, know what’s going on inside that Pi and what Python is doing under the hood down to some low level.

If you’ve been using Linux “under the hood” often means understanding what happens inside the kernel–the heart of the Linux OS that manages and controls everything. It can be a bit daunting; the kernel is simple in concept, but has grown over the years and is now a big chunk of software to approach.

Your first embedded system project probably shouldn’t be a real time 3D gamma ray scanner. A blinking LED is a better start. If you are approaching the kernel, you need a similar entry level project. [Stephen Brennan] has just the project for you: add your own system call to a custom Linux kernel.

Continue reading “Under The (Linux) Hood”

VGA Output On A Freescale

Even though VGA is an outdated and becoming somewhat deprecated, getting this video output running on non-standard hardware is a rite of passage for some hackers. [Andrew] is the latest to take up the challenge. He got VGA output on a Freescale i.MX233 and also got some experience diving into the Linux kernel while he was at it.

The Freescale i.MX233 is a single-board computer that is well-documented and easy to wire up to other things without specialized hardware. It has video output in the form of PAL/NTSC but this wasn’t quite enough for [Andrew]. After obtaining the kernel sources, all that’s needed is to patch the kernel, build the kernel, and build a custom DAC to interface the GPIO pins to the VGA connector.

The first thing that [Andrew] did was load up the Hackaday home page, which he notes took quite a while since the i.MX233 only runs at 454 MHz with just 64 MB of RAM. While our retro page may have loaded a little faster, this is still an impressive build and a great first step to exploring more of the Linux kernel. The Freescale i.MX233 is a popular chip for diving into Linux on single-board computers, and there’s a lot going on in that community. There are some extreme VGA hacks out there as well if that’s more your style.

What Is This Thing Called Linux?

It should come as no surprise that we at Hackaday love Linux above all others (that should start a nice little flamewar on the internal email list). If you still haven’t given it a whirl yet, don’t fear. Everyone starts from scratch at some point. With each passing year it becomes more and more likely that knowing something about Linux will eventually benefit every hardware hacker. Take part of your time off in the coming weeks to give it a whirl. First thing’s first, check out this quick guide on what Linux actually is.

Adafruit’s offering is pretty low level, so if you’re the kind that likes to argue “kernel” versus “OS” please keep it to yourself. For us the important distinction pointed out here is microcontroller (Arduino) versus Raspberry Pi. The Pi generally runs one flavor or another of Linux for good reasons, while microcontroller-driven systems tend to run use-specific code (with the exception of projects that leverage Real Time Operating Systems). Of course it extends past pre-fab options, Linux is a popular choice on bare-bones roll-your-own machines.

This is the year of Linux! Ha, we’ve heard that one every year for at least a decade. To us it makes no difference, you should know a bit about each OS out there. What are you waiting for? Read the guide then download (for free!) a CD image of our current favorite Linux flavor.

Dumping A C64 Kernel

[Blark] picked up a couple of Commodore 64 machines on Craig’s List so that he could play around with the SID chips inside. But there’s some other fun stuff in there and his attention was drawn to the PROM which stores the kernel. He thought it would be a fun adventure to build a ROM dumper capable of storing binary images.

In the video after the break you can see that when powered up the dumper immediately starts streaming hex values to the terminal. The system is set up to feed a Python script which packs the data stream into an image file. The reading is done by a PIC 18F4520, streaming the data in at 9600 baud with a generous delay between each address read to get the cleanest read possible. He had a bit of help from the AVR Freaks to get to this point.

We’d guess he’s going to pull the image off the chip several times and compare results to filter out any possible data corruption. From there we’re not sure what he’ll do with the files but there’s always the possibility of making is own emulator using this kernel image.

Continue reading “Dumping A C64 Kernel”