Buffer Overflow Found in RFID Passport Readers

epee1221 writes "Wired ran a story describing Lukas Grunwald's Defcon talk on an attack on airport passport readers. After extracting data from the (read-only) chip in a legitimate passport, he placed a version of the data with an altered passport photo (JPEG2000 is used in these chips) into a writable chip. The altered photo created a buffer overflow in two RFID readers he tested, causing both to crash. Grunwald suggests that vendors are typically using off-the-shelf JPEG2000 libraries, which would make the vulnerability common."

Re:Explain to me how...

[cgenman]

In a buffer overflow situation, a system may crash because it attempts to run the overflow data as code and fails. However, 99% of the time you can use buffer overflows to inject your own code to run. You just need to know what system it will be running on.

A buffer overflow is a serious vulnerability, in that finding one is the biggest step towards cracking a system open.

Re:Explain to me how...

[Anonymous Coward]

It makes no difference at all. Unless the reader's MMU is set to trap when executing from non-firmware memory, it doesn't matter. A buffer overflow is not saving this code to disk or anything; it's just executing it.

Re:Explain to me how...

[h2g2bob]

A buffer overflow [wikipedia.org] can do a lot more than just crash systems. Done right they can cause the machine to run ANY code the hacker wants while the computer owner is none the wiser. TFA suggests changing the picture generated, which probably wouldn't be too hard considering it looks like it's the JPEG2000 libraries which are affected anyway.

Re:the usual

[Anonymous Coward]

This is not 1990 anymore. Embedded systems are not underpowered. Embedded systems today are quite literally THOUSANDS of times more powerful than the supercomputers that you and I grew up with. Here's one example of an RFID reader [adazonusa.com]. 64MB of RAM. Windows Mobile 2003. Here's another one [arm.com] with an XScale processor. XSCALE. DO YOU HAVE ANY IDEA HOW POWERFUL AN XSCALE PROCESSOR IS? When I first was working with garbage collection and automatic bounds checking, I dreamed for something even a fraction as powerful as an XScale processor.

Granted, an RFID reader is not a desktop computer. But I guarantee the RFID readers these people are using have enough power to read an RFID, play a copy of Doom in the background, and have plenty to spare.

Garbage collection and automatic bounds checking were feasible when I used them on a 16MHz processor with 1MB of RAM. I'm going to go out on a limb and say they're STILL feasible on a 266MHz processor with 64MB of RAM.

You can't run a JVM on this thing, and even if you wanted to, it would be a bad idea.

I suspect that "this thing", like most embedded systems, supports the Jazelle [arm.com] instructions specifically because, actually, not only is running a JVM on an embedded system a good idea, but it's very common.

Hint: most cell phones run a JVM. Hint: most cell phones run their software almost exclusively on a JVM. Hint: an RFID reader is much more powerful than a cell phone. This is not 1990 anymore. "Embedded" does not mean underpowered. "Embedded" means the processing power is only slightly absurd.

Re:the usual

[RAMMS+EIN]

While I appreciate your attempt to correct your parent's somewhat narrow view of programming (as you correctly point out, not all systems are equally powerful), I feel compelled to point out some flaws in your argument.

Your argumentation suggests that a type-safe language will necessarily lead to more cpu-intensive code. This is simply not the case. For the most part, type-safety can be enforced at compile time. The result is a program that is type-safe by construction, without requiring any run-time checks.

There is one case that deserves particular attention: array access. Theoretically, it is possible to construct a static type checker that will refuse to accept array accesses that it cannot prove are within bounds, and yet accept enough of them to make the language usable. However, this is difficult, so many languages take a more pragmatic approach. Lone array accesses incur a run-time check, but common patterns of accessing arrays (such as iterating over every element of the array) are implemented in the language in ways that are both safe and efficient.

Now, to give all this more substance, I will point interested readers to the OCaml programming language. OCaml is just one language that is type-safe, yet has an implementation that generates efficient code. A well written OCaml program should be on par with a well written C program in terms of speed and memory usage. At the same time, OCaml provides many conveniences to the programmer that C doesn't. Polymorphism, namespaces, pattern matching, an object system, the list goes on. Also, it plays well with existing systems. Interfaces to the standard Unix system calls are provided, and the compiler can generate stand-alone executables (i.e. no need to install a runtime on target systems).