Slashdot Mirror
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."
Nothing to see here, please move along
Would it be possible to find out if my flight is going to crash? (Yeah, I live in Sao Paulo)
"Owner of said passport is hauled off to some secret room where all of their orifices are checked by an ex-prison guard with large hands."
And if this (Warning: NSA - Not Safe Anywhere) or any of these (also NSA - Not Safe Anywhere) was the passport photo, pity the poor guard ...
The revised scenario:
Passport is scanned
Reader goes casters up
Reader is power cycled
Passport is scanned again
Reader goes casters up
Guard looks at passport photo
Guard throws up, as do the next dozen who try to intervene, they all claim work-related traumatic stress disorder, go on permanent disability.
Why was this, do you think?
Because a whole generation of CS students was raised on C and didn't know any better.
Because in those days, computer resources were so expensive that it was foolish to waste them. Here's a hint: garbage collection is a bad idea if you have so little memory that you're actually likely to run out of it. Automatic bounds checking on arrays is expensive if your processor is slow enough.
You really don't know what you're talking about. First of all, although they are certainly useful, I didn't advocate specifically bounds checking and garbage collection, I advocated type safety; you can have a type safe language with exactly the same functionality and performance as C; in fact, several existed before C. C's lack of safety is both unnecessary and unusual. Second, you greatly overestimate the overhead of garbage collection and bounds checking; we are talking a few percent overhead at most, and often, safe languages give better performance (less fragmentation, more opportunities for compiler optimization). Third, you don't understand what this device is doing; this device is decompressing a JPEG2000 image and displaying it on some bitmapped display. Most likely, it's a small embedded PC--basically, a slow desktop machine.
You can't run a JVM on this thing, and even if you wanted to, it would be a bad idea.
Of course, you can run a JVM on this thing, first because "this thing" is likely as powerful as a slow desktop, and second because JVMs run even on smartcards. But I'm not advocating a JVM; JVMs are trying to solve a much harder problem than safety, namely sandboxing. All I'm saying is that the industry should move to a safe language instead of C; that costs nothing in terms of performance.
No, the problem why these problems keep cropping up is because many programmers are prejudiced, uneducated, and don't know what they're doing. Kind of like you.