What are the exception vectors doing in RAM?
Normally they'd be in Flash - not writable by a simple write operation anyway.
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' …
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)
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...
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).
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.
> 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.
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!
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.
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!"
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?
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.
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.
Biting the hand that feeds IT © 1998–2019