ARM 'security hole' is ofla cousin - RISC OS News, Software and Information

ARM 'security hole' is ofla cousin

Published: 24th Apr 2007, 23:46:40GMT Source: drobe.co.uk
By the Drobe news desk

Page 1 of 1

One man's exploit is another's .ofla.ofla.ofla

A computer security researcher who claimed he found a serious vulnerability in ARM-compatible processors has in fact stumbled across a class of bug infamous to RISC OS users - the ofla.

The 'ofla' bug is seen when a confused program tries to read information from an inappropriate part of the computer's memory, and winds up mistaking executable code for text. This machine code is then displayed to the user in error messages and other windows, and shows up as the string of 'ofla's.

However, Juniper Networks's Barnaby Jack said by doing the reverse of this, a malicious hacker could overwrite this executable code with a new program, thus breaking into and taking over an ARM-powered gadget. He presented his findings at an international security conference this month, and compromised a D-Link router as a demonstration - drawing the attention of the mainstream IT press. Barnaby had billed his work as the discovery of a 'major vulnerability' in ARM-based systems. ARM remains the popular choice for mobile phones, routers, gadgets and other embedded kit, with over a billion ARM-based chips manufactured a year.

Doubts
While developers contacted by drobe.co.uk remain skeptical that hackers will be able to leverage Barnaby's work into effective attacks on devices, the news took some commentators by surprise. Analyst Russ Cooper at Cybertrust told reporters: "The ARM processor is supposed to be a secure environment, so that this flaw exists represents a bigger problem."

Technically speaking, Barnaby is worried that the majority of devices with ARM and XScale processors at their hearts store their hardware vectors starting at address 0 - although modern cores can optionally locate their vector tables in high memory. When software de-references a pointer, it is usually set to null, or zero, so by tricking a device's firmware into using the null pointer to store data, you can hijack the vector table and execute arbitrary code in a privileged mode.

The hardware vector table tells the processor what to do when certain situations arise, such as when the machine is reset, or peripherals and users' programs need attention from the operating system. If this table is read back as ASCII, it will appear as the familiar 'ofla's; try memoryi 0 in a taskwindow to see them and the table's instructions.

On RISC OS, you can do what Barnaby is suggesting by running from BASIC SYS"OS_File",16,"$.evilcode",0. You will stiff your machine if you try to load random data, such as a sprite file, at address 0 with OS_File.

Compromise
To do this on other platforms, the hacker must find similar vulnerabilities in a device's operating system. This can be non-trivial, however Barnaby was able to abuse debugging features enabled in production models of kit to probe firmware and discover these flaws. By compromising systems such as routers and wireless base stations, it is possible to reflash ROMs, take over a networks, and infect desktop and server systems by intercepting simple network transfers. Non-ARM systems, and most PC operating systems, lock the first page of memory to trap all null accesses - blocking the form of attack described above.

Barnaby said: "Security needs to reach further than a home PC. Insecure devices pose a serious threat to the entire network. Hardware vendors must take security into consideration."

Links
Firmware flaw threatens routers, phones

This article has been linked to, or is available in the following formats:

[Printable] [Digg this] [Blog search]

rjek (+5.4) 25/4/07 12:00AM	One should note that many "home" routers are actually MIPS based (all NetGear, Linksys and D-Link ones certainly, plus many others, like Motorola) and so won't be effected by this. It's also a big of a silly thing to make a song and dance about. You need to be running in supervisor mode to write to these "vectors" at address zero anyway, and thus there is much more mischief you can get up to. The only difference is that 0 is a slightly easier pointer to corrupt through. The solution of course is to use high vectors - where the vectors start half-way up in memory rather than at the bottom of it. This is a non-issue bought up by a security company to help sell their products.
druck (+4.3) 25/4/07 9:16AM	It is bull, its up to the OS to set up the MMU so zero page to be protected against writes (and reads if necessary), just as it is for any processor to set protection on certain critical pages containing jump tables. Later versions of RISC OS protect against user mode writes to zero page but not SVC mode, which is should really do as only OS_ClaimProcessorVector has a legitimate reason to write there (if we can ignore the legacy FIQ handlers which were poked in at the last vector entry). While we are at it, OS_File should be doing a bit of argument validation, as it still crashes Select (on VRPC) - where are all those improvements?
msww (+3.2) 25/4/07 9:45AM	I'm not convinced that the solution is to reduce the problems caused by dereferencing a null pointer, as opposed to producing tools which help programmers detect and fix the null-pointer dereference bugs in the first place.
druck (+1.1) 25/4/07 11:15AM	Zero page should be protected against reads and writes so that dereferencing a null pointer produces a trappable exception, rather than letting the program stumble on regardless.
rjek (+1.0) 25/4/07 12:07PM	*In reply to druck:* As it is on Linux, which is one of the most common OSes to run on routers and embedded networking devices. You choose precisely the right word when describing this as "bull".
adrianl (+1.1) 25/4/07 12:47PM	Many embedded CPUs, some ARM-based chips included, do not have a MMU and therefore cannot protect the memory at address 0, leaving the processor vectors vulnerable. RISC OS needn't suffer the same problem because the chips it uses do have full MMUs but it would need work on the kernel and even a few support modules to make (since they have private words at defined addresses within the first 4KB) to resolve this issue properly on all of the processors that it currently supports.
rjek 25/4/07 1:37PM	*In reply to adrianl:* Yes, that's true, and a fine argument for using devices that use Linux verses VxWorks or some home-grown OS. (And assume they don't use uCLinux which is a pain and I can't think of any networking appliances that use it.)
Loris (+1.0) 25/4/07 7:43PM	If I've got this straight, an attacker would have to find a specific bug in the device's programs: - a null pointer under reproducible conditions - before a STM, or better still, a looping store - and where arbitrary data can be inserted And then be able to force a reset or execute some other vector. And for it to work the device mustn't: allow writes to zero page, or use ROM directly (or flash-ROM which isn't directly writable), or put its vector table elsewhere. I'd have thought finding other security bugs might be easier.
bavison (+1.0) 25/4/07 10:44PM	FIQ handlers would indeed be a problem if the vectors were moved to &FFFF0000. I wouldn't exactly describe them as a legacy feature; the Iyonix still supports podule FIQs, and certain ARM-based SoC's have some of their peripherals hard-wired as FIQs. Of course, the RISC OS API could easily be extended to allow the correct address for installation of a FIQ handler to be determined. Actually, one of the reasons why page 0 has remained unprotected in privileged modes is that it is home to the IRQ semaphore. It's undesirable to require the page tables to be updated (and back again) around every IRQ, and the address is so low in memory that we can't even use the extra-small 1K pages available in modern MMUs to control it independently of the processor vectors and FIQ handler. Ideally, the IRQ semaphore would be moved out of the way, but unfortunately it's one of those magic addresses which some modules "know" about and use directly. RISC OS 5 added an OS_ReadSysInfo 6 reason code to read the address of the IRQ semaphore, but it probably won't get heavy use until the IRQ semaphore is moved and people find their modules breaking.