Embedded problems: exploiting NULL pointer dereferences

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

[Hayden Clark]

What are the exception vectors doing in RAM?

Normally they'd be in Flash - not writable by a simple write operation anyway.

[Rob Crawford]

How fast people forget

Vector redirection is hardly a new thing as many of us probably remember (senility hasn't taken over yet)

Even on the sinclair spectrum (involved replacing the ROM or paging in ram instead though). On the Amiga and Atari ST this was used (the Rob Northern protection system messed with the execution vectors)

On dos machines you had to patch the vectors to do anything worthwhile. (MS-)DOS viruses even followed the chained vectors to avoid the resident antivirus packages.

Infact I would have been surprised if sich exploits didn't exist in embedded devices.

No doubt somebody will discover revectoring of API functions. Oops did that on the Amstrad CPC (in 1985), and Win XP (and below) many years ago.

Can I have a job please, it's so much more interesting than being an network analyst (and probably pays better too)

Rob...

[David Knapman]

Exception vectors in RAM

I'm by no means an expert on embedded systems/flash, but I'd imagine that the vectors are in RAM so that the system can react to interrupts and the like *whilst* it's flashing the flash memory.

[Brett Brennan]

This is SO retro!

As an old (52) guy, this is one of the first "new tech" exploits I intuitively understand. It goes back to work I was doing (before getting my "Management Lobotomy") back in the '70s and '80s - "When Men were Men and Computers had WIRES". I would regularly "write" a debug "hack" (toggled in from the front panel switches on my PDP-11 or GA-440) to patch address 0 with a JSR or JMP to another address for debugging. Zero was (usually) the HALT location for a system - a bad stack pop would usually load the PC with zero and JMP. Zero usually came with all zeros in it - to stop execution and halt the system, because as we all know, a scrambled stack is BAD. Putting a JMP to a toggled-in debugger was an honored way of getting hold of the system to let you trip through the (hopefully) uncorrupted stack trace to see where things went wrong.

Ahhh, I remember doing this many, many nights. In fact, this is how I "won the heart" of my wife of 22 years: she would drive up to the plant to visit me while I was in the midst of a long debug session, and, having nothing better to do, would "help out" by writing RATFOR routines to assist in my efforts. This got her to change her major (yes, it was THAT long ago!) from Preschool Teaching to Computer Science...and she's now CEO of our company.

Not much of a comment on the content here, but nice to see something that has a bit of disco dancing associated with it...

[Torben Mogensen]

Not only null pointers are bad

No matter where the interrupt-vector table sits in memory, it is an exploitable weakness if it isn't write-protected: You just set a pointer to whatever you like and off you go. In C, this is easily done with either a cast or pointer arithmetic, and if you have access to assembly language, it is even easier.

The only place where a 0-based vector table is slightly worse than other locations is if the hacker can't write code. In this case, he _might_ be able to exploit a buggy program that in special cases writes through a null pointer.

In any case, the fault is not really in having the vector table at any specific address but allowing writes to it from code that a user can run.

Also, if you are worried about null-pointer exploits, simply avoid null pointers. Many languages do not allow null pointers or pointer arithmetic at all (and this is checked at compile-time), so use one such. If you really need null pointers, make sure to check before every dereference of a pointer that can be null (and make the compiler enforce this).

[Dillon Pyron]

PowerPC

PowerPC 5, yes. PowerPC 6, no. PowerQuik, no. This vuln has been out for several months. Or at least IBM and Freescale have known about it.

[Anonymous Coward]

It is FUD -- Not News

Quoting the report's "Solutions" section:

"If the processor is equipped with an MMU (Memory Management Unit), the vector area may be marked as non-writeable."

In other words, all they are really doing is explaining a detail of how to exploit a vulnerability that could only exist if your OS programmers were mentally handicapped.

This looks like an ill-conceived bid by Juniper Networks to garner undeserved attention by spreading FUD to consumers courtesy of El Reg.

[Anonymous Coward]

This is a non-story

> all they are really doing is explaining a detail of how to exploit a vulnerability that could only exist if your OS programmers were mentally handicapped.

Agreed. For instance I know that all versions of Symbian OS are immune to this exploit; memory at address 0 isn't even *readable* to user-mode processes.

> This looks like an ill-conceived bid by Juniper Networks to garner undeserved attention by spreading FUD to consumers

Looks that way to me too.

[Anonymous Coward]

Learn something about embedded systems

Obviously you guys haven't been around many embedded devices. LOADS of systems don't have an MMU. They're not always needed on consumer products.

And guess what, even those that do, hardly ever protect the exception vectors. I'm an embedded devloper and we use VXWorks as a base. The VXWorks manual even recommends NOT protecting vectors so they can be re-routed.

Also, when exploiting these devices you usually WILL be in kernel mode, and can write to anywhere

sharpen up folks!

[Jasmine Strong]

This is irrelevant and obsolete

Firstly, all ARMv5 processors support "high vectors"- that is, vectors at another address to 0. All reasonable OSes use this.

Secondly, all ARMv5 processors have either a Protection Unit (which allows regions of memory to be protected) or a full MMU (which allows paging, protection and virtual addressing).

Thirdly, dereferencing a null pointer is an exception condition. It's trapped by the OS.

[call me scruffy]

Not just FUD, but FAD:Absolute Bullsh*t

Three things need to go wrong before this can be exploited, all of which indicate that the application is so buggy that hardware protection is a waste of time.

1.) The application must ignore a null return from malloc. (And the attacker must be able to reliably stimulate that.)

2.) The attacker must be able to entirely control what's written. If the aplication prepends any housekeeping or other (ATM packet header?) to the front of the buffer then this won't work.

3.) _Then_ the vector table needs to be writable. It's often in a bootloader that's in true ROM so that the application can be reflashed, and so that the table is populated on power up. For a more sophisticated embedded system (BSD,Linux etc, you'll probably have an MMU anyway.)

Anyone who's read the datasheet for any ARM SoC will know well these issues and what precautions are taken and recomended to avoid them. (For example some microcontrollers are hard wired not to permit writes to the first 4k of the map.)

This publicity show is akin to "Don't trust those Nurses! They stick syringes in you and might hit something important!"

[Phil]

Good joke.

It's a good joke, I must admit. Clearly complete and utter b*llocks, but written in a believable way.

I just worry about the number of people who aren't going to realise it's not real. Particularly since these days, the number of (decent) programmers who've never touched a hardware vector outnumbers those who have.

You *do* realise it's a joke, don't you?

[igor]

Why there are still security holes.

Ah, "Old school" programmers. It's easy to tell when someone doesn't have much security knowledge. It's especially apparent when it's the "old fellas".

NULL pointer deref's are common, malloc can be forced to have an out of memory error, and most wrappers will return NULL if passed 0! You do realise, that in the security world, NULL derefs are reported as DoS attacks daily.

Now, have a look at one of the millions, of say, ARM7 consumer embedded device. Go on. Tell me how many of these network enabled devices run in kernel mode. And now, tell me how many protect their vectors. Not many!

You guys are great, you're the reason there are security holes and that we have jobs.

Thanks!

[Anonymous Coward]

Re: "Why there are still security holes"

Your comment makes exactly no sense.

There is no excuse, at all, for not checking that malloc returns non-zero.

The "Old Fellas" have been used to writing for graceful failiure, and memory back off for years, they tend not to take memory for granted. Ignorance of that point leads, as you say to DoS attacks, on all platforms, so how does that validate this platform bashing?

A brief survey of ARM devices with embedded ethernet controllers indicates that many of them have full MMUs and the rest have MPUs! Again it is inexcusable that these features aren't used! If the application is running in "kernel"(ITYM "Supervisor" or "System"!)mode then this exploit becomes even more meaningless, since a stack-smash would still get you priveleged execution.

Programmers this grossly incompetent (and lord knows I've seen enough of em.) would screw up on any platform you gave them. They (and the cretins that hire them) are the reason there are security holes, and there have been no comments here so far to give them any quarter.