Original URL: https://www.theregister.com/2007/06/13/null_exploit_interview/

Embedded problems: exploiting NULL pointer dereferences

Your device could be at risk

By Federico Biancuzzi

Posted in Security, 13th June 2007 10:31 GMT

Interview Barnaby Jack developed a method for exploiting certain NULL pointer dereferences on the ARM and XScale architectures (and likely PowerPC). This method affects a lot of devices since most mobile phones and PDA are ARM based, and high-end routers often use the XScale architecture.

Could you introduce yourself?

Barnaby Jack: I'm a staff security researcher at Juniper Networks. I've been involved in computer security for a number of years, mostly dealing with operating system internals, reverse engineering, and anything low-level. I've recently started to focus some of my research efforts into embedded systems - I'm having fun with it. I'm a kiwi born and bred, but these days I'm living way across the pond up in the bay area.

Could you describe the vector rewrite attack you have developed?

Barnaby Jack: The Vector Rewrite Attack is a method for exploiting certain NULL pointer dereferences on the ARM and XScale architectures. In general, NULL pointer dereference flaws are considered non-exploitable. On the XScale and ARM architectures the memory address 0 is mapped, and also holds the exception vector table. The exception vector table is a set of branch instructions that correspond to different exceptions, such as software and hardware interrupts. When a case arises that writes to the 0 address with user-defined source data, it is possible to gain execution control by rewriting the exception table.

On many embedded devices, execution is running in Supervisor (SVC) mode so memory access is unrestricted. The PowerPC architecture also stores the vector table at a low address, and is likely vulnerable to this same attack. Research into the PPC architecture is ongoing.

A short paper describing the attack is available here (pdf).

There were some comments around the net about your attack and its link with the JTAG interface. Could you please explain us how you used JTAG and the link with your attack?

Barnaby Jack: The JTAG interface is a hardware interface that when used in conjunction with a hardware debugging probe, allows live debugging of the embedded processor. JTAG is simply used as a debugging mechanism. JTAG is in no way required for an attack, and is used for exploit development in the same way a debugger such as ollydbg would be used on a PC. Most modern cores have JTAG support built into the processor design.

Which architectures are affected?

Barnaby Jack: ARM and XScale architectures, and likely the PowerPC architecture. The MIPS processor maps the vectors to a high address, and is not susceptible to this exploitation method. Any architecture that stores the vector table at 0x0 would be vulnerable to this attack.

Can we consider this a hardware design problem?

Barnaby Jack: This could be considered more of a problem in the architecture design. The MIPS architecture for example bases the exception vectors at a high address, at 0x8000xxxx. Thankfully, with ARM, XScale, and PowerPC - there is an option to map the vectors to a high address.

On ARM9 and newer cores, the exception table can be relocated high by driving the HIVECS processor pin high. On the XScale core, the vectors can be relocated high by setting the Exception Vector Relocation Bit of the ARM control register to 1. The vectors will be mapped to address 0xFFFF0000.

Manufacturers of networked devices could issue a firmware update to remap the vectors to high memory.

I saw a thread on the dailydave mailing list, where Brad Spengler posted: "I submit for your record-keeping what I believe to be the first public exploit for a null ptr dereference bug in the Linux kernel." It seems they are talking about x86 too?

Barnaby Jack: There have been examples of NULL pointer exploitation on a variety of architectures and platforms, including a locally exploitable vulnerability in pt_chmod from 1994 found by 8lgm. More recently, skape wrote a paper on exploiting NULL pointers in Internet Explorer.

The Vector Rewrite Attack is not the first time a NULL pointer dereference has been manipulated to cause an exploitable vulnerability - but I haven't been made aware of any published vulnerabilities that use the NULL address to overwrite interrupt entries to gain execution control. What I like about the Vector Rewrite Attack, is the fact that it can be leveraged both locally and remotely and is 100 per cent reliable - it also affects the most popular embedded architectures.

So we could remotely exploit a NULL pointer dereference if the code is running on a vulnerable architecture?

Barnaby Jack: Yes, if you can write to the NULL pointer with user defined data, this attack can certainly be exploited remotely. In fact, this attack is more reliable than a remote stack overflow, due to the fact that no offsets are required. You will always be writing to address 0.

The only data needed by an attacker is a copy of the vector table, which can be acquired by downloading and reversing the targets firmware, or retrieving the table via the JTAG interface. The vector table will remain static, and will only change with some firmware revisions.

The fact that your attack works without having to guess an offset means that it could be suitable for worms attacking these devices?

Barnaby Jack: As embedded exploitation is still in its infancy, I don't foresee a worm in the very near future - but yes, if a worm was targeting embedded devices, this would be a reliable attack vector.

What type of devices use this hardware?

Barnaby Jack: ARM cores are the most widely-used 32 bit cores in the world. Most mobile phones and PDA's are ARM based. Higher

end routers often use the XScale architecture, while home routers tend to split between ARM and MIPS based cores. In general, if you have a consumer electronics product, there is a high chance it has an ARM based processor.

Some of these devices features very limited resources, so what type of limits are there once you have broken in?

Barnaby Jack: As an example, I gave a live attack demonstration that remotely compromised a popular home router. The shellcode of the remote exploit first cleared the administrator password on the router by patching the password location in memory. The shellcode then set the flag that enables remote administration of the router. The exploit then forced a soft reset on the device. Once the device re-initialized, it was possible to log into the router, with administrator privileges, with no password, from anywhere on the internet.

The remote administration interface allows a remote firmware upgrade. The next step was to upload a modified version of the firmware. The firmware had additional code that would watch for any portable executable file being downloaded over the HTTP port. Once a PE file was detected, the PE file would be patched to include a stub that would retrieve a remote executable and execute the file, before returning to the host executable. i.e.: if a router you were using had been exploited, and the firmware patch was active, any seemingly legit executable download would be infected with a stub that would execute a file of my choosing. The hostile executable would run transparently along with the original executable.

This was a method to ultimately compromise an internal network via the router.

It really comes down to the creativity of the attacker, any device that is connected to a network poses a threat.

Was this example running on one of those cheap (like $100) SOHO routers?

Barnaby Jack: Yes, the example was a popular SOHO router. The same techniques used to exploit the cheaper consumer routers are applicable to high-end routers as well. In my opinion, the ideal attack for routers is a man-in-the-middle attack. The device sits on the perimeter, and sees all incoming and outgoing traffic. In my example, I injected data into incoming traffic to compromise internal hosts - but you could re-route traffic, sniff data, open a shell, the list goes on. Of course, any network connected device can be targeted, a router just seemed like an obvious example.

Which router manufacturers should be interested in your research?

Barnaby Jack: This reaches further than router manufacturers. Any manufacturer that uses an ARM or XScale, and even PowerPC processor, should take an interest in this research. All of these architectures allow remapping of the vectors to a high address, which essentially protects from this vulnerability class. This attack is not going to be the next stack overflow, but the simple truth is, these flaws do exist - and prevention is quick and simple. In the case of router manufacturers, I can only speak for ourselves - at Juniper, all research is distributed internally before being released to the public. Our engineers take this research and apply any necessary changes to our product line.

PowerPC. Does this mean that XBox360 and Playstation3 and Nintendo Wii might be vulnerable to this vector attack? Considering that they can be connected to the internet...

Barnaby Jack: All three consoles are using PowerPC based cores. If an exploitable NULL dereference was found that allowed an attacker to overwrite the NULL address, and vectors were mapped low, then an attack would be possible. From the little I have read, at least concerning the Xbox360 and its hypervisor mode, I would consider an attack unlikely. I don't know enough about the other game console architectures and their memory management implementations to say specifically if they would be vulnerable.

We have already seen some attacks against bug in wireless drivers for common OSes. I am wondering if this vector might help attackers exploit bugs in drivers included in embedded systems.

Barnaby Jack: Definitely. The wireless interface on embedded devices is generally the first place I would hunt for vulnerabilities. There are ample opportunities to find exploitable bugs. The same (or at least very similar) vector used to exploit wireless drivers under common OS's can be applied to embedded systems with a wireless stack. The most interesting aspect of the wireless interface is that many products will integrate a System-On-Chip design that has the wireless code built into the chip, and the developer will call the API provided by the chip manufacturer. These SoC designs are heavily used in all manner of consumer, and high-end devices. An exploitable flaw within a popular SoC would affect many devices.

Thinking at something like a blackberry... How do you extract the code from one of those embedded devices?

Barnaby Jack: There are a number of methods to retrieve the firmware image. If a JTAG connection can be made to the device, then the firmware image can be read off the flash chip via JTAG. There are both commercial and free products available that support reading and writing flash memory via the JTAG port. A popular opensource project for interfacing with JTAG enabled devices is jtagtools. The jtagtools software can program and read various external flash chips.

Often, the firmware can be downloaded from the vendors site. In many cases there will be no compression or encryption, or the firmware will be compressed with a known compression scheme. If a firmware image is encrypted or compressed with a proprietary scheme, the firmware image may contain an unencrypted copy of the bootloader - the bootloader can be reversed to find the compression algorithm, and a custom decoder can be written.

If connecting a JTAG isn't feasible and the firmware image is not available for download, then a last ditch effort is to physically remove the flash memory chip from the device, and read the image in an external reader. The simplest way to remove the chip from the device is by using a hot air rework tool. Apply hot air to re-flow the solder, and remove the chip. The chip can then be read externally in an eeprom reader. Another option is to use the "Chip Quik" product. It is a low melting point alloy, that when heated and fused with soldered joints, forms a new alloy that will stay in a molten state long enough for components to be removed.

Should vendors encrypt the firmwares available on their websites?

Barnaby Jack: Many vendors will encrypt or compress their firmware images. If the bootloader code is unencrypted in the image then the compression/encryption scheme can be reversed and a custom tool written to decrypt the image. If you have access to the device, and a debug session either over serial or JTAG, you can employ a trick that's been used since the dawn of executable packing - and that is to simply dump the image when it decrypts itself in memory. Once the image has decrypted itself in memory, the processor can be halted, and the decrypted code can be dumped to file. Then it's a simple matter of loading the code into your favorite disassembler.

Should final products ship with debugging features disabled?

Barnaby Jack: Ideally, yes. Many vendors will remove resistors leading from the JTAG port, or in the case of the ARM architecture, may drive the TRST pin low. Neither of these methods is sufficient to disable the JTAG functionality. Resistors are easily replaced, and pins can be pulled high. The ideal choice is to remove the JTAG traces altogether. The main argument against removing JTAG and UART ports is the cost factor.

Manufacturing boards is expensive, and the cost involved to manufacture both prototype and production boards may not be warranted. Debugging functionality may be needed in some production devices, for technicians to service the device, for example.

If the JTAG port is removed, it's certainly a roadblock for an attacker, but it will not stop someone who is determined to have access to the code - other methods such as tapping data traces and re-socketing chips can be employed.

In the end it all boils down to writing secure software. If the software on the device is vulnerable, removing debugging functionality won't change that fact.

Federico Biancuzzi is freelancer. In addition to SecurityFocus he also writes for ONLamp, LinuxDevCenter, and NewsForge.

This article originally appeared in Security Focus.

Copyright © 2007, SecurityFocus