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”

Building A Proof Of Concept Hardware Implant

You’ve no doubt heard about the “hardware implants” which were supposedly found on some server motherboards, which has led to all sorts of hand-wringing online. There’s no end of debate about the capabilities of such devices, how large they would need to be, and quite frankly, if they even exist to begin with. We’re through the looking-glass now, and there’s understandably a mad rush to learn as much as possible about the threat these types of devices represent.

EEPROM (left) can be edited to enable SMBus access on this card (header to the right)

[Nicolas Oberli] of Kudelski Security wanted to do more than idly speculate, so he decided to come up with a model of how an implanted hardware espionage device could interact with the host system. He was able to do this with off the shelf hardware, meaning anyone who’s so inclined can recreate this “Hardware Implant Playset” in their own home lab for experimentation. Obviously this is not meant to portray a practical attack in terms of the hardware itself, but gives some valuable insight into how such a device might function.

One of the most obvious attack vectors for hardware implants is what’s known as the Baseboard Management Controller (BMC). This is a chip used on modern motherboards to allow for remote control and monitoring of the system’s hardware, and promises to be a ripe target for attackers. There are a few sideband channels which can be used by the BMC chip to talk to other chips. To keep things simple [Nicolas] focused on the older I2C-derived SMBus (rather than the newer and more complex NC-SI), demonstrating what can be done once you have control of that bus.

Only problem was, he didn’t have a motherboard with a BMC to experiment with. After a little research, the answer came in the form of the Intel EXPI9301CTBLK network card, which features the 82574L SMBus chip. This allows for experimenting with a subset of SMBus functionality on any machine with a PCI-E slot. Even better, the card has an SMBus header on the top to plug into. [Nicolas] describes in detail how he enabled the SMBus interface by modifying the card’s EEPROM, which then allowed him to detect it with his HydraBus.

With the hardware setup, the rest of the write-up focuses on what you can do with direct control of SMBus on the network card. [Nicolas] demonstrates not only creating and sending Ethernet packets, but also intercepting an incoming packet. In both cases, a running instance of tcpdump on the host computer fails to see the packets even exist.

He goes on to explain that since SMBus is very similar to I2C and only requires four wires, the techniques shown could easily be moved from the Hydrabus dev board used in the demo, to a small microcontroller like the ATtiny85. But you would still need to find a way to add that microcontroller directly onto the network card without it being obvious to the casual observer.

Our previous coverage of suspected hardware implants sparked considerable discussion, and it looks like no matter what side of the fence you’re on, the debate isn’t going away anytime soon.

You’ll Flip For This 7404 IC Motherboard Fix

We often lament that the days of repairable electronics are long gone. It used to be you’d get schematics for a piece of gear, and you could just as easily crack it open and fix something as the local repairman — assuming you had the knowledge and tools. But today, everything is built to be thrown away when something goes wrong, and you might as well check at the end of a rainbow if you’re searching for a circuit diagram for a new piece of consumer electronics.

But [Robson] writes in with an interesting story that gives us hope that the “old ways” aren’t gone completely, though they’ve certainly changed for the 21st century. After blowing out his laptop’s USB ports when he connected a suspect circuit, he was desperate for a fix that would fit his student budget (in other words, nearly zero). Only problem was that he had no experience fixing computers. Oh, and it takes months for his online purchases to reach him in Brazil. Off to a rocky start.

His first bit of luck came with the discovery he could purchase schematics for his laptop online. Now, we can’t vouch for the site he used (it sure isn’t direct from Dell), but for under $5 USD [Robson] apparently got complete and accurate schematics that let him figure out what part was blown on the board without even having to open up the computer. All he had to do was order a replacement IC (SY6288DAAC), and solder it on. It took two months for the parts to arrive, and had to do it with an iron instead of a hot air station, but in the end, he got the part installed.

Continue reading “You’ll Flip For This 7404 IC Motherboard Fix”

Recovering Data From A Vintage MFM Drive

Even if you aren’t a vintage computer aficionado, you’re probably aware that older computer hard drives were massive and didn’t hold much data. Imagine a drive that weighs several pounds, and only holds 1/1000th of what today’s cheapest USB flash drives can. But what you might not realize is that if you go back long enough, the drives didn’t just have lower capacity, they utilized fundamentally different technology and relied on protocols which are today little more than historical footnotes.

A case in point is the circa 1984 Modified Frequency Modulation (MFM) drive which [Michał Słomkowski] was tasked with recovering some files from. You can’t just pop this beast into a USB enclosure; copying files from it required an interesting trip down computing’s memory lane, with a sprinkling of modern techniques that are sure to delight hackers who still like to dip their toes into the MS-DOS waters from time to time.

The drive, a MiniScribe 2012, has its own WD1002A-WX1 8-bit ISA controller card. [Michał] is the kind of guy who just so happens to have an ISA-compatible AT motherboard laying around, but he didn’t have the correct cooler for its Pentium processor. He stuck a random heatsink down onto it with a rubber band and set the clock speed as low as possible, which worked well enough to get him through the copying process.

Not wanting to fiddle with floppies, [Michał] then put together a setup which would let him PXE boot MS-DOS 6.22 under Arch Linux. He used PXELINUX, part of the syslinux package, and created an entry for DOS in the configuration file under the pxelinux.cfg directory. He then installed netboot which combines a DHCP and TFTP server into one simple package, and configured it for the MAC address of the AT machine’s 3com 3C905C-TXM network card.

With the hardware and operating system up and running, it was just a matter of getting the files off of the MFM drive and onto something a bit more contemporary. He tried to copy them to a secondary IDE drive, but it seemed there was some kind of conflict as both drives wouldn’t operate at the same time. So he pulled another solution from his bag of tricks: using a USB mass storage device on MS-DOS. By emulating a SCSI drive, he was able to get a standard flash drive plugged into a PCI USB card working, which ultimately dragged these ~35 year old files kicking and screaming into the 21st century.

We love keeping old hardware alive here at Hackaday, and documented methods to not only PXE boot DOS but use USB storage devices when you get it up and running will hopefully inspire some more hackers to blow the dust off that old 386 in the attic.

Retrotechtacular: Here’s How They Programmed The EDSAC Computer

When you write a program for your computer, whether it is a desktop machine, a microcontroller, or a supercomputer, the chances are that you use software tools to help you get the job done. High level languages, compilers, linkers, assemblers, debuggers, and code libraries have become so integrated that in many cases you will barely be aware of their existence. To all intents and purposes this huge toolchain will be the computer. But the first computer programmers had none of these luxuries. They had to hand assemble their own binaries, check them by hand, and debug them by guessing what had happened when they failed.

EDSAC I, 1948, W.Renwick with 5 hole tape reader and Creed teleprinter. Copyright Computer Laboratory, University of Cambridge. Reproduced by permission. [CC BY 2.0 UK]
EDSAC I, 1948, W.Renwick with 5 hole tape reader and Creed teleprinter. Copyright Computer Laboratory, University of Cambridge. Reproduced by permission. [CC BY 2.0 UK]
EDSAC (Electronic delay storage automatic calculator) was the first computer operated by the University of Cambridge in the UK and one of the first few computers in the entire world when it was built in the late 1940s. It is the subject of the 1951 film you’ll find embedded below. Originally produced for a conference, the video sports a 1976 introduction and narration from the machine’s creator Professor Maurice Wilkes. It doesn’t take us through the design of the machine itself, instead it concentrates on the workflow required to program it.

The Paper-Heavy Process of Programming EDSAC

To illustrate the programming process, a committee of people who would now call themselves computer scientists, but probably then called themselves mathematicians, breaking a formula into subroutines before the code is laboriously hand assembled. The linking process is performed manually too by the secretary who types the code into a teletype for transfer to a punched tape. When a library function is required she reaches into a filing cabinet for the roll of tape containing it before running it through a tape duplicator to add it to the program. Finally the completed tape is checked and added to a job queue that consists of a row of hooks on the wall. Never complain that your toolchain is unwieldy again!

The original EDSAC was decommissioned in the late 1950s after serving the university and spawning a commercial version, the LEO, which became the first ever computer manufactured for use in commerce. That was not the end of the EDSAC story though, because in this century a team at the National Museum of Computing at Bletchley Park set about recreating EDSAC as an exhibit. And as luck would have it a member of that team was at the recent Electromagnetic Field hacker camp to give a talk about their work which you will also find below.

Building a Faithful Reproduction of EDSAC

Tony Abbey gives us both a history of the machine and a description of its architecture, followed by a run through their efforts in rebuilding it. You may be surprised by some of the unexpected facts from the talk. For instance, while all the tubes used in the EDSAC are still available, their bases are not. Equivalents were sourced from China, but team members had to modify them with dental drills.

They also needed to manufact the 1940s-style tube chassis, and the solution to that problem happened to be just down the road. Bletchley is part of modern-day Milton Keynes, a post-war new town that is also home to another famous name: Marshall amplifiers. Tube amps are built in a surprisingly similar way, so they took on the manufactured challenge. Not all the parts of the new EDSAC are original though. The memory used mercury delay lines in 1949, but for 2018 recreation the computer has a delay line using nickel wire and modern components. Tony admits that even that has caused problems, and there is a simulator using a microcontroller.

You can see the restored EDSAC at the National Museum of Computing. We visited it in 2016, and you can read our review. Meanwhile if you are an FPGA wizard, you can even have a virtual EDSAC of your own.

Continue reading “Retrotechtacular: Here’s How They Programmed The EDSAC Computer”

That TRS Jack On Your Graphing Calculator Does More Than You Think

It’s not Apple IIs, and it’s not Raspberry Pis. The most important computing platform for teaching kids programming is the Texas Instruments graphing calculator. These things have been around in one form or another for almost three decades, and for a lot of budding hackers out there, this was the first computer they owned and had complete access to.

As hacking graphing calculators is a favorite for Maker Faires, we were pleased to see Cemetech make it out to this year’s World Maker Faire in New York last weekend. They’re the main driving force behind turning these pocket computers with truly terrible displays into usable computing platforms.

As you would expect from any booth, Cemetech brought out the goods demonstrating exactly what a graphing calculator can do. The most impressive, at least from a soldering standpoint, is their LED cube controlled by a graphing calculator. The electronics are simple, and just a few 595s and transistors, but this LED cube is taking serial data directly from the link cable on a graphing calculator. Of course, the PCB for the LED cube is designed as an Arduino shield for ease of prototyping, but make no mistake: this is an LED cube controlled by a calculator.

If you can send serial data to a shift register from a graphing calculator, that means you can send serial data to anything, bringing us to Cemetech’s next great build featured this year. It’s an N-gauge model train, with complete control over the locomotive.

There’s a lot more to controlling model trains these days than simply connecting a big ‘ol variac to the tracks. This setup uses Direct Cab Control (DCC), a system that modulates commands for locomotives while still providing 12-15V to the tracks. There’s a good Arduino library, and when you have that, you can easily port it to a graphing calculator.

Cemetech is one of the perennial favorites at Maker Faire, and over the years we’ve seen everything from the Ultimate TI-83+ sporting an RGB backlight and a PS/2 port to a game of graphing calculator Whac-A-Mole. It’s all a great example of what you can do with the programmable computer every 90s kid had, and an introduction to computer programming education, something Cemetech is really pushing out there with some hard work.

IBM 1403 printer working again

Fixing An IBM 1401 Computer To Get It Printing Again

The IBM 1401 is a classic computer which IBM marketed throughout the 1960s, late enough for it to have used transistors rather than vacuum tubes, which is probably a good thing for this story. For small businesses, it was often used as their main data processing machine along with the 1403 printer. For larger businesses with mainframes, the 1401 was used to handle the slower peripherals such as that 1403 printer as well as card readers.

Broken germanium transistor
Broken germanium transistor

The Computer History Museum in Mountain View, CA has two working 1401s as well as at least one 1403 printer, and recently whenever the printer printed out a line, the computer would report a “print check” error. [Ken Shirriff] was among those who found and fixed the problem and he wrote up a detailed blog entry which takes us from the first test done to narrow down the problem, through IBM’s original logic diagrams, until finally yanking out the suspect board and finding the culprit, a germanium transistor which likely failed due to corrosion and an emitter wire that doesn’t look solidly connected. How do they know that? In the typical [Ken]-and-company style which we love, they opened up the transistor and looked at it under a microscope. We get the feeling that if they could have dug even deeper then they would have.

If you’re unfamiliar with the work of this team who maintain the machines at the museum, you’ll want to read up on how they recently got a 1401 to run FORTRAN II code.