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."
These passports are full featured CPU's with up to 72KB of data. The "RFID reader" is actually a very bad name for a software system that is going to read out these passports. In most documents it will be referred to as an inspection system. It will not only read out the passport, but it will also test the biometrics, communicate with other systems etc.. This is a complicated process that will most likely take place on a full featured CPU, containing a modern OS, and a modern software stack. This allows for maximum flexibility, but it will also make the systems vulnerable for attack.
The only thing the manufacturers of these systems can do is thoroughly test their software, and make the attack possibilities as small as possible. For instance, they should check the signature under the data before passing the data on to the next layers. Of course, for this you need the certificate of the issuing state. You should also test if the underlying libraries that do this initial check are not vulnerable.
Because the way it will actually go is like this:
Passport is scanned
Reader goes casters up
Reader is power cycled
Passport is scanned again
Reader goes casters up
Security Goon say "Shit, that's wierd. But the paper passport looks fine. Go on through."
Owner of said passport traipses past security, making the E-passport no better than a regular one.
At the moment it crashes. With the right sequence of bytes it looks like:
Hacker crafts jpeg with exploit code
Passport is scanned
Exploit code is injected
Reader silently executes exploit code
Reader continues operation with nobody any the wiser
A compromised reader lets you bypass the biometrics.
Explain to me how this is an "attack" on passport readers?
It might be possible for an attacker to exploit the buffer overflow in order to cause the reader to execute software chosen by the attacker. For example, the attacker might insert code that recognizes his forged passport as valid, or that recognizes somebody else's passport (who may have flew in on the same flight) as invalid.
Come test your mettle in the world of Alter Aeon!
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.
The ______ Agenda
A buffer overflow 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.
Don't do much embedded programming, do you? Garbage collection, automatic bounds checking, and the vast majority of features that you think of as "modern" were available in quite a number of programming languages from the 1960s -- lisp, for example. While they were extremely popular in academic circles, and were without a doubt extremely powerful and capable, most development continued to be done in assembly, and then later C. Why was this, do you think? 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.
Now if you're saying that there's no need to develop the vast majority of today's computer software in assembly, C, or C++, then I agree with you wholeheartedly -- but we're not talking about a computer, we're talking about an RFID reader. You know, a small device that doesn't have the latest gaming processor from AMD and Intel and 2 gigs of RAM. It has enough memory for what it needs to do and that's it; and, to be low power, it has a small, simple embedded processor.
You can't run a JVM on this thing, and even if you wanted to, it would be a bad idea.