Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Buffer Overflow Found in RFID Passport Readers

Posted by CowboyNeal on Sat Aug 11, 2007 09:20 AM
from the never-too-careful dept.
Security Technology IT
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."
+ -
story

Related Stories

Submission: Buffer Overflow in RFID Passport Readers by epee1221 (873140)
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Buffer Overflow Found in RFID Passport Readers 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Of course they are vulnerable (Score:3, Insightful)

    by Anonymous Coward on Saturday August 11 2007, @09:42AM (#20195235)
    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.

  • Explain to me how... (Score:3, Funny)

    by binaryspiral (784263) on Saturday August 11 2007, @09:48AM (#20195255)
    Explain to me how this is an "attack" on passport readers?

    Passport is scanned
    Reader goes casters up
    Reader is power cycled
    Passport is scanned again
    Reader goes casters up
    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.

    This does show the lack of testing and hardening, but it seems a buffer overflow situation like this would be relatively easy to patch.
    • Orifice overflow requires orifice patching.

    • Re:Explain to me how... (Score:5, Insightful)

      by Zerth (26112) on Saturday August 11 2007, @09:54AM (#20195309) Homepage
      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.
      • Because the way it will actually go is like this:
        Security Goon say "Shit, that's wierd. But the paper passport looks fine. Go on through."

        "Insightful," eh?

        A show of hands, please, from anyone willing to test this theory out.

        "Weird" is not a word I want to hear from the airport security guard when I am trying to board a plane for New York.

        • Exactly this happens with the 'secure' chip-on-pin credit cards. I have an old one and it's a bit wonky. Also the signature long since faded into nonexistance.

          Hand card to cashier.
          Scan card. Won't scan.
          Scan card again. Won't scan.
          "That's wierd. It won't scan. Sign here instead."

          I then walk out with the goods. No valid security check was made. This has happened multiple times at multiple shops.

          • Re:Explain to me how... (Score:5, Informative)

            by h2g2bob (948006) on Saturday August 11 2007, @11:54AM (#20196115) Homepage
            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: (Score:2, Interesting)

              by Anonymous Coward
              I'm envisioning:
              *passport is scanned*
              *reader does something weird [because it's being hijacked by buffer overflow exploit code], gives error message*
              *passport is re-scanned*
              *reader says, "Joe C. Terrorist is OK. His name does not appear in no-fly list. SSN# 666-69-6969 is valid."*
              -os

      • Owner of said passport traipses past security, making the E-passport no better than a regular one.

        Nonsense. What would actually happen is exactly what would happen if you just broke the contactless smart card chip in your passport -- since your passport isn't fully functional, you get routed out of the expedited "normal" flow, and into the "exceptional case" flow, which results in greater scrutiny of you and your passport. Assuming the alterations you made to the paper passport are undetectable, and assuming you manage to keep your cool and not give yourself away, and assuming the immigration agents

    • Re:Explain to me how... (Score:5, Insightful)

      by Nazlfrag (1035012) on Saturday August 11 2007, @09:57AM (#20195329) Journal
      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.
      • One would hope that a reader would run from firmware, but you never know.
          • Yeah I'm wondering that too. Those without a clue seem to be multiplying.
          • It permits separating the address space for running code from the address space for data, so you couldn't get it to run code in the RFID address space. It also makes it more difficult to overwrite the running code (since it's firmware and not software), even if the address spaces weren't kept separate, which would mean that after you crash the device and reboot it, the original software is running again.

      • I just hope that it's my face that contains the exploit code.

        Blackhat? No sir! I've just got an unfortunate face!"

    • Re: (Score:3, Insightful)

      by SagSaw (219314)
      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.
      • 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 other forged passports as valid.

        or that recognizes somebody else's passport (who may have flew in on the same flight) as invalid.

        They need not be on the same flight. Possibly not even on the same day, depending how the system might be hackable.
        If their intention were disru

    • Re:Explain to me how... (Score:5, Informative)

      by cgenman (325138) on Saturday August 11 2007, @09:58AM (#20195339) Homepage
      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.

    • It's a denial-of-service attack. By sending a few innocent sacrifical lambs with modified passports, it's possible to take out an entire security station's set of scanners and clob the entire security theatre operation of a small airport, and make fake passports much easier to get through the systems in the interim, especially if this becomes a common occurrence for a few days.

      Better yet, modify the passports of people you don't like to delay their passages through security and get them arrested. There are
    • I recommend "The Shellcoders Handbook"
  • ...if you pass a cracked RFID chip through a passport reader and then it crashes,

    #1: the guard will humanly read your inside cover photo with extra vigilance...the chip is not the only method of ID
    #2: you'll probably be detained for a bit while they re-test your passport; if it fails again, they'll tell you to get a new passport
    (#2a: or be placed on a no-fly list, because you're a terrorist)

    Plus, how exactly would a code-injection exploit work unless it's something like the GDI+ vulnerability that

    • All that being said, there are some things (i.e. voting machines) that just should not be electronic-ized, and I feel this is one of them.

      When it comes to counting voter-verified paper ballots, I would agree with you that this task should not be done electronically. Humans can (and do in many elections around the world) manually count voter-verified paper ballots.

      But when it comes to preparing the voter-verified paper ballot, I don't see the harm with electronic assistance: electronic preparation

      • Buffer overflows are so 90s. Isn't there a way to prevent them entirely, like using only good libraries?
          • I always check all inputs before using the data. Don't other people do that?
            • Validating all input can help, but it doesn't help when you have things like off-by-one [wikipedia.org] errors. Remember people, null-terminated strings are 1 byte bigger than the number of characters in the string.

          • The company that I work for has mainframes that disallow the execution of data, and this is, or has been, prevented by hardware. It just isn't possible to execute data. Oh... it has been this way ever since I've worked at this company, over 25 years.

            Even Microsoft now has, in XP and I'm guessing later OSes, Data Execution Prevention (DEP). Most people don't turn it on because it does have a slight effect on performance. You can find the option by going to My Computer, Properties, Advanced Tab; Click "Se

  • FTFA: "If a reader could be compromised using Grunwald's technique, it might be reprogrammed to misreport an expired passport as a valid one, or even -- theoretically -- to attempt a compromise of the Windows-based border-screening computer to which it is connected."

    That does it. From now on I'm only travelling to countries which use OpenBSD to operate their border gateway protocols.

    And: "Additionally, the International Civil Aviation Organization recommends that issuing countries protect biometric data on the e-passport with an optional feature known as Extended Access Control, which protects the biometric data on the chip by making readers obtain a digital certificate from the country that issued the passport before the equipment can access the information."

    Sounds like in the future, the only people who'll be able to traveler with any degree of success will be those who can forge their passports...

  • Remember this /. story about RFID Passports Cloned Without Opening the Package [slashdot.org]? I'm not sure if RFID and security will ever get along at a satisfying level or if will be similar to the systematic breaking of DRM locks. Amongst other RFID stories [slashgeo.org], this "Security analysis report" paper [91 pages pdf, 967k] [bridge-project.eu] is most informative (via this blog [vector1.eu]).

  • the usual (Score:2, Insightful)

    by m2943 (1140797)
    The problem is, as usual, the use of inherently unsafe and dangerous programming languages like C and C++.

    There is no reason why any modern programming language should permit accidental buffer overflows; they are easily preventable without pushing the burden onto the programmer even in programming languages with the same power as C and C++.

    • Re:the usual (Score:4, Insightful)

      by 808140 (808140) on Saturday August 11 2007, @01:14PM (#20196755)
      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.

      • Re: (Score:3, Informative)

        by RAMMS+EIN (578166)
        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
        • Thanks for the correction. Actually, an earlier poster pointed out to me that these machines are embarrassingly overpowered for what they do, and so my criticism was pretty much moot anyway.

          As for type-safety, I actually know what you mean -- I do most of my programming is in Haskell these days, which has a very powerful type system. Runtime errors are relatively infrequent as a result, but when they do occur, it's often because I'm trying to take the head of an empty list, or something similar, a proble
      • So write the reader in C for efficiency if you must, but DO NOT LET THE READER INTERPRET THE DATA!!

        The reader simply passes the data to the PC, which is powerful enough to use a 'safe' language (with bounds checking, garbage collection, VM-sandboxing etc. etc.). Data obtained from the card is untrusted and should be treated as such until proven otherwise.

        The problem here is not the reader, but the JPEG library running on the host.
        • I am indeed aware that most cell phones run a JVM, but I guess I don't think of cell phones as being "embedded" (not saying they aren't, just that I feel like they've long since ceased to be appliances and have started becoming small, hand-held computers in both capability and application).

          I will admit that I assumed that an RFID reader would not be as powerful as they appear to be. I guess we have hardware bloat these days, huh? Well, in light of the evidence, I withdraw my critique. I don't see why we'
          • Now, here is a funny thing: an exploitable buffer overflow [sun.com] was recently found in the native library handling images in Sun's JVM. This is one of the most significant security bug found in this JVM for the past few years.

            Programs in Java are more secure than programs in native code, but only as long as they don't rely on native libraries ...

        • Hint: most cell phones run their software almost exclusively on a JVM.

          Hum, no. Many cell phones can run Midlets, but the main firmware (user interface, call handling, SMS, picture processor...) is programmed in native code. On Symbian and Windows Mobile cell phones, you can actually install additional native appliations. Midlets are only used for user-downloaded applications programmed in Java, which is a really small market. Blackberries are the only cell phones that run every program in Java, including the user interface, but even them rely on significant portions of nativ

        • Right, I don't think anyone here really disagrees with you. However, the fact is, many programmers are not as careful as they think they are, nor are they as leet as they consider themselves to be -- even well-written software like the Linux kernel, Samba, and OpenBSD, whose hackers are a million times more competent than you, I, or indeed, 99.9% of programmers out there, have had bugs resulting from simple buffer overruns, sign overflow errors, and memory leaks.

          It most certainly is not the fault of C tha
            • But in business, rapid development is important. Higher level languages, in general, make for more rapid time-to-market than low level languages, precisely because there's less bug-chasing.
        • Why was this moderated troll? Just because of the juvenile ad homniem in the last sentence?
    • I've worked with high and low level programming languages, and they all have uses. I once wrote a machine language program to draw rectangles on my 24 year old laptop by poking about 20 bytes into memory; It did in one second what took BASIC one minute. I also made a mistake before that and had to salvage my data by dumping the machine's memory through a serial port. That doesn't mean I should stick with BASIC because it's overflow-proof, or never use assembly because it's dangerous.

      I'm also learning SVG
  • ``Grunwald suggests that vendors are typically using off-the-shelf JPEG2000 libraries, which would make the vulnerability common.''

    Because everybody knows that, had they written their own code, it would have been much more secure. Just like magic.

    • Re: (Score:2, Funny)

      by Anonymous Coward
      You should start with studying English. Your skills our lacking.
    • "The question is : should I study Arabic or Spanish to welcome our new overlords."

      Yes. :)
    • Chinese could probably be the most useful - you can get earworms for that, and those other two languages, from http://www.earwormslearning.com/intro.html [earwormslearning.com]
    • Mandarin Chinese. Follow the money. (There's no monopoly on stupidity, after gutting the US manufacturing sector, Japan has also sold Japan, Inc. to the Chinese).

      RFID passports were a stupid idea in the first place. I do not want the id in my pocket broadcasting to the world "I'm an American Passport! Kidnap the holder!" (and kidnapping is an issue in places of the world I need to go, like where my in-laws and children are).

    • Re: (Score:2, Insightful)

      by MrCoke (445461)
      There is no architecture that is secure from a passionate developer armed with time, IDA Pro and an oscilloscope (if needed).
        • You must not follow the sat hacking community at all. CAM emulation is the thing that most of the people seem to be waiting on since an emulated CAM means that any ECMs won't affect a real card that would then have to be replaced. Nobody wants Black Sunday all over again afterall. And as far as I'm aware there haven't really been any recent systems where one could patch the *box* and get free tv. Those days are long, long gone.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.