Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Security Technology IT

Buffer Overflow Found in RFID Passport Readers 96

Posted by CowboyNeal from the never-too-careful dept.
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."
This discussion has been archived. No new comments can be posted.

Buffer Overflow Found in RFID Passport Readers More

Buffer Overflow Found in RFID Passport Readers

Comments Filter:

  • 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.

    • Re: (Score:2, Funny)

      by zolf13 ( 941799 )
      Orifice overflow requires orifice patching.

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

      by Zerth ( 26112 ) on Saturday August 11, 2007 @09:54AM (#20195309)
      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.

        • Re: (Score:1, Informative)

          by 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.
        • How exactly does "running from firmware" affect whether it is exploitable or not?
          • 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.

      • Re: (Score:3, Funny)

        by solevita ( 967690 )
        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:1)

        by swokm ( 1140623 )
        (Hooded figure waves passport.)
        Hooded: "I am not the terrorist you're looking for."
        (Guard 1 glances at hacked scanner and turns to Guard 2.)
        Guard 1: "Ahh... yeah, this isn't the terrorist we're looking for. Move along, move along..."

    • 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.

      • Re: (Score:2)

        by mpe ( 36238 )
        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

    • Re: (Score:2)

      by DrSkwid ( 118965 )
      I recommend "The Shellcoders Handbook"

    • Re: (Score:1, Troll)

      by tomhudson ( 43916 )

      "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 [trolltalk.com] (Warning: NSA - Not Safe Anywhere) or any of these [trolltalk] (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 inter

  • Honestly... (Score:2, Insightful)

    by The tECHIDNA ( 677584 ) *
    ...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

    • Plus, how exactly would a code-injection exploit work unless it's something like the GDI+ vulnerability that occurred with WMF files? (If a rogue guard is injecting evil code into the machine, the government had waaay more scary problems ahead than with some 'sploiting a passport reader).

      As TFA mentions, this is a buffer overflow problem. Most buffer overflows can be exploited easily unless additional OS safeguards are in place -- StackGuard, Address Space Randomization, etc., and even then, a determined hacker may still find his way in.

      There are a few existing [secunia.com] examples [securitytracker.com] of buffer overflows against JPEG2000, and they can be exploited much in the same way the WMF exploit is -- malformed file is read into reader, causes buffer overflow in JPEG2000 library, causing the execution of arbitrary

      • Buffer overflows are so 90s. Isn't there a way to prevent them entirely, like using only good libraries?
        • If it this was not a current problem we wouldn't be having this discussion. Buffer overflows can be a result of bad programming regardless of what libraries are being used. Choosing vulnerable libraries or functions is just one way of creating such problems.
          • 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.

          • Re: (Score:2)

            by MCraigW ( 110179 )

            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

    • 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

    • there are some things (i.e. voting machines) that just should not be electronic-ized

      I think voting machines can be computerized, but it would have to work like this:
      1. the machines are sealed with something other than a furniture key
      2. they're prefereably open source
      3. After you're done voting, it prints a copy of the ballot for you to verify. It doesn't count the ballot until you press the verify button. If it's wrong, you throw the ballot into a convenient paper shredder, and make your corrections.

  • "..the Windows-based border-screening computer.." (Score:3, Funny)

    by adnonsense ( 826530 ) on Saturday August 11, 2007 @09:55AM (#20195319) Homepage Journal

    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...

    • Re: (Score:1, Insightful)

      by Anonymous Coward
      "That does it. From now on I'm only travelling to countries which use OpenBSD to operate their border gateway protocols." - by adnonsense (826530) on Saturday August 11, @10:55AM (#20195319)

      Cambridge Researcher Breaks OpenBSD Systrace:

      http://it.slashdot.org/it/07/08/09/138224.shtml [slashdot.org]

      Nothing's "completely invulnerable"...
  • 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]).
  • Something else to make the experience of flying all that much more unpleasant for the rest of us!

  • 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:1, Informative)

        by 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

        • Re: (Score:2)

          by 808140 ( 808140 )
          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

      • Re: (Score:1)

        by zefrer ( 729860 )
        Exactly, and besides that fact, how is it the language's fault if the programmer doesn't do proper checking? _Because_ C is not a type safe language is why programmers need to be extra careful in making proper checks when dealing with buffers _especially_ on a f***** passport reader...

        • Re: (Score:2)

          by 808140 ( 808140 )
          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

      • 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

        • Re: (Score:2)

          by 808140 ( 808140 )
          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'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
    • Yeah, they should have used Java. Then again, the underlying JPEG libraries are still written in C++, if my information is still correct. So the wait is on for a rewrite in Java or maybe C#. You would not want a scripting language to do the JPEG decoding I suppose, that would bring the system performance down too much.
  • ``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.
    • No; if they had written their own code, the vulnerabilities would have varied between systems, making the effectiveness of an attack less than it is in a monoculture. Of course, had they done that, there would have been a slew of new and exiting vulnerabilities, which might be much more major.
  • I for one look forward to the superior alternative of Definitive Biometric Real ID for air travel.

    Undressing in front of the uniformed agent, undergoing endoscopy with low-bid lubricant, then going through the rotating-brushes Lockheed Martin AlloScrub body wash to remove all possible caches and residues of others' DNA before having the blood draw, is the highlight of any ordinary business trip. The $635 airport security fee is a bit of a burden, though, as are the 12 hour fast and prep. enema.

    Waiting

Slashdot Top Deals

This is clearly another case of too many mad scientists, and not enough hunchbacks.

Close