Slashdot Mirror

← Back to Stories (view on slashdot.org)

Buffer Overflow Found in RFID Passport Readers

Posted by CowboyNeal on 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."

75 of 96 comments (clear)

  1. Of course they are vulnerable by Anonymous Coward · · Score: 3, Insightful

    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.

  2. Explain to me how... by binaryspiral · · Score: 2, Funny

    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.

    1. Re:Explain to me how... by zolf13 · · Score: 2, Funny

      Orifice overflow requires orifice patching.

    2. Re:Explain to me how... by Zerth · · Score: 5, Insightful

      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.

    3. Re:Explain to me how... by Nazlfrag · · Score: 4, Insightful

      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.

    4. Re:Explain to me how... by SagSaw · · Score: 3, Insightful

      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!
    5. Re:Explain to me how... by cgenman · · Score: 4, Informative

      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
    6. Re:Explain to me how... by Antique+Geekmeister · · Score: 1

      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 plenty of other possibilities.

    7. Re:Explain to me how... by DrSkwid · · Score: 1

      I recommend "The Shellcoders Handbook"

      --
      There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    8. Re:Explain to me how... by Dachannien · · Score: 1

      One would hope that a reader would run from firmware, but you never know.

    9. Re:Explain to me how... by Anonymous Coward · · Score: 1, Informative

      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.

    10. Re:Explain to me how... by TheAverageGuy · · Score: 1

      How exactly does "running from firmware" affect whether it is exploitable or not?

    11. Re:Explain to me how... by shivamib · · Score: 2, Funny
      Here, I corrected it for you.

      1. Passport is scanned
      2. Bufferoverflow runs handcrafted code
      3. RFID reader claims that this is indeed John Smith, and this is his picture, nonwithstaning the fact that there is
      [...]
      4. Profit!!

      Amsterdam, here we go!
    12. Re:Explain to me how... by DDLKermit007 · · Score: 1

      Yeah I'm wondering that too. Those without a clue seem to be multiplying.

    13. Re:Explain to me how... by westlake · · Score: 1
      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.

    14. Re:Explain to me how... by Tony+Hoyle · · Score: 1

      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.

    15. Re:Explain to me how... by h2g2bob · · Score: 4, Informative

      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.

    16. Re:Explain to me how... by Anonymous Coward · · Score: 2, Interesting

      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

    17. Re:Explain to me how... by solevita · · Score: 2, Funny

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

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

    18. Re:Explain to me how... by Warbothong · · Score: 1

      I know another way to screw up the readers. Smile: http://news.bbc.co.uk/1/hi/uk_politics/3541444.stm (of course the government is working on this as it is a very serious problem. Yep, in a few years time they'll manage to piss off everyone enough that nobody will be smiling, thus fixing the bug)

    19. Re:Explain to me how... by mpe · · Score: 1

      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 disruption of air transport they'd probably want to invalidate the passports of aircrew, especially pilots.

    20. Re:Explain to me how... by Dachannien · · Score: 1

      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.

    21. Re:Explain to me how... by swillden · · Score: 1

      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 don't have access to an on-line database where they can cross-check the data in your passport, you'll get away with it.

      But the fact that you got away with it does *not* constitute a security failure of the electronic passport. The e-passport achieved its purpose, by causing you to be singled out for greater scrutiny. In a world without e-passports, you'd have had only the same cursory examination that every passenger gets -- and that can't be very thorough, because immigration checkpoints have to process huge numbers of people in short periods of time, with relatively few staff and little space. So without e-passports, your paper alterations don't have to be as good, and you don't have to be as cool. The goal of the contactless smart card chip is to raise the difficulty of a successful forgery, and it does that quite well, not because chips can't be broken, but because they can't be broken undetectably, and because broken chips provoke greater scrutiny.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    22. Re:Explain to me how... by swokm · · Score: 1

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

  3. Re:Are borders are open! by Anonymous Coward · · Score: 2, Funny

    You should start with studying English. Your skills our lacking.

  4. Honestly... by The+tECHIDNA · · Score: 2, Insightful

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

    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.
    Other than "it'll get you through faster!!", what is the point of using chips when, more than likely, the passport clerk has to humanly-read it to verify the info anyway? Especially considering that the particular RFID chip technology used in the passport is going to be obsolete or cracked in 3 years, and most passports don't expire for five or ten years?

    1. Re:Honestly... by nneonneo · · Score: 1

      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 examples 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 code. Next up: the reader (and system in general) gets compromised to do the hacker's bidding.

    2. Re:Honestly... by proxy318 · · Score: 1

      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.
      4. When the ballot's correct, you hand it in to the election officials, as you currently do with standard paper ballots

      this hybrid solution offers the best of both worlds: it allows faster vote counting, but provides a paper trail if there's an error. It also eliminates the problems with scantron or punchcard style ballots (filled in wrong oval, or "hanging chad" type errors).
      --
      Saying your "phone ran out of batteries" is like saying your "car ran out of gas tanks".
  5. "..the Windows-based border-screening computer.." by adnonsense · · Score: 2, Funny

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

  6. Lost faith on RFID security long ago? by Lord+Satri · · Score: 2, Insightful

    Remember this /. story about RFID Passports Cloned Without Opening the Package? 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, this "Security analysis report" paper [91 pages pdf, 967k] is most informative (via this blog).

    --
    Animoog.org
  7. Re:Are borders are open! by couchslug · · Score: 1, Funny

    "The question is : should I study Arabic or Spanish to welcome our new overlords."

    Yes. :)

    --
    "This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
  8. JPEG2000 by Presto+Vivace · · Score: 1

    Why am I not surprised?

  9. Re:"..the Windows-based border-screening computer. by Anonymous Coward · · Score: 1, Insightful

    "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

    Nothing's "completely invulnerable"...

  10. Re:This is the reason closed source is good by MrCoke · · Score: 2, Insightful

    There is no architecture that is secure from a passionate developer armed with time, IDA Pro and an oscilloscope (if needed).

  11. That's interesting... by shivamib · · Score: 1

    It's just that they keep hiring complete morons that have no idea what they're doing to work on the systems.
    I see that where I work all the time! Must be the new trend...
  12. Great! by thatskinnyguy · · Score: 1

    Something else to make the experience of flying all that much more unpleasant for the rest of us!

    --
    The game.
  13. 30 more years of buffer overflows? by Futurepower(R) · · Score: 1

    Buffer overflows are so 90s. Isn't there a way to prevent them entirely, like using only good libraries?

    1. Re:30 more years of buffer overflows? by FireFlie · · Score: 1

      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.

    2. Re:30 more years of buffer overflows? by MCraigW · · Score: 1

      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 "Settings" in the performance frame. When the Performance Options box comes up, go to the Data Execution Prevention tab. If you want to be secure, you select "Turn on DEP for all programs and services except those I select:". I don't know how effective this is, but I assume that it works. If your passport reader is running on a Microsoft OS, then this option should be turned on. Note that this doesn't stop you from overflowing your buffers, but does stop the execution of that data, thus avoiding those types of exploits.

  14. the usual by m2943 · · Score: 2, Insightful

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

    1. Re:the usual by 808140 · · Score: 3, Insightful

      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.

    2. Re:the usual by Anonymous Coward · · Score: 1, Informative

      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. 64MB of RAM. Windows Mobile 2003. Here's another one 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 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.

    3. Re:the usual by zefrer · · Score: 1

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

    4. Re:the usual by 808140 · · Score: 1

      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're running so much shit on something that ought to be so simple, and I certainly don't think it's necessary, but as long as we are, I too am left to wonder why we're not doing the development in a saner language. I don't think I'd go so far as to write it in a language that needs a virtual machine, but there are many languages that compile to machine code that do bounds checking and automatic memory management. (Like Haskell! Whee!)

      Of course, even if we were to do that, we're left with the library problem -- the JPEG2000 library was presumably written in an unsafe language and bugs were the result. So even if the people developing the RFID software had written their system in Common Lisp, you couldn't reasonably expect them to re-implement the JPEG2000 standard, could you?

    5. Re:the usual by 808140 · · Score: 1

      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 that these bugs exist -- but once a program becomes large enough, well, its complexity makes catching some subtle errors difficult. With safer languages, the programmer is freed from having to concern himself overly much with questions like "when must I check the bounds on an array" (the safe language automatically checks all writes, even ones that strictly speaking don't require it), "when must I free memory" (the safer language implements automatic memory management and frees memory when it knows it can), etc.

      Of course this convenience is not without price; safe languages are slower than languages nearer to the machine level. In the past, that slow-down was too high a cost, but this is less the case with today's processors -- real bottleneck usually comes from choosing an O(n^2) algorithm when an O(n log n) algorithm exists, for example. No language is sufficiently smart to compensate for a stupid programmer.

      But with today's processors being what they are, there's really no reason to take the risk. Type-safety comes with a minuscule slowdown, one which, on today's processors, is negligible to the point of being irrelevant. Why shoot yourself in the foot by insisting on a language like C for a complex project, especially one where security is paramount? Write it in something safer, profile it, and replace key, individual routines with ones written in C as required. Sure, you could still mess those up, but by minimizing the unsafe portions of your project, you help minimize the chances of serious bugs occurring, and decrease the amount of code that must be audited when memory leaks or buffer overflows occur.

      It's win-win, really.

    6. Re:the usual by The+Master+Control+P · · Score: 1

      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/CSS/HTML/JavaScript to write interactive websites. It's amazing to do with a few lines in SVG what would take pages of code in C/OpenGL (open a window/area and draw some shaded shapes on it). I am also conscientious of the fact that C/OpenGL can animate hundreds to thousands of moving objects in real time. But they all have their place.

      So, do you believe it's foolish of nVidia to write their kernel module and interface in dangerous C?

    7. Re:the usual by 808140 · · Score: 1

      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.

    8. Re:the usual by 808140 · · Score: 1

      Why was this moderated troll? Just because of the juvenile ad homniem in the last sentence?

    9. Re:the usual by AdamInParadise · · Score: 1

      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 native code.
      --
      Nobox: Only simple products.
    10. Re:the usual by m2943 · · Score: 1

      Just because of the juvenile ad homniem in the last sentence?

      It's not a "juvenile ad hominem".

      We get a story about security-relevant buffer overflows in important C programs almost daily. These are serious problems. To address those, either we need better programmers or we need better tools. Since we can't educate the programmers any more than we already do, obviously it's the tools that aren't working, and that means that the people who are choosing the tools are making the wrong choice, and the GGP poster exemplifies the attitudes and technical misinformation that lead to these wrong choices.

      I've seen this go on for 30 years, and I'm really getting fed up with it.

      The problem really is people, people like the GGP poster.

    11. Re:the usual by AdamInParadise · · Score: 1

      Now, here is a funny thing: an exploitable buffer overflow 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 ...

      --
      Nobox: Only simple products.
    12. Re:the usual by RAMMS+EIN · · Score: 2, Informative

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

      --
      Please correct me if I got my facts wrong.
    13. Re:the usual by IchBinEinPenguin · · Score: 1

      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.

    14. Re:the usual by 808140 · · Score: 1

      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 problem which (as you mentioned) cannot be caught easily at compile time. Haskell, unlike OCaml, is not a speed demon (although it's actually quite fast these days, surprisingly -- faster than Perl, Python and Java, at any rate).

      Automatic bounds checking on array access doesn't incur much of a speed penalty anyway, unless you're trying to work on very large datasets which require a lot of array accesses. Obviously having the compiler optimize common iterations in a special way can speed this up a lot (I know the Haskell compiler I use, GHC, optimizes certain classes of list operations in a special way -- maps, folds, filters, to name a few) but ultimately if you're doing anything really complicated it's probably been done before by CS researchers who have done a provably safe implementation and who can give you a rigorous complexity analysis on the algorithm, so in those cases you'll probably do fine writing that portion of the code in C. But even on a very large, time-intensive project, it's unlikely you'd need to do that much. In my view, writing a whole program in C these days is, for most platforms and applications, a direct violation of the "optimize last" rule.

      Of course, my original post and its parent were both sort of silly in this particular case, because the vulnerability was in a JPEG2000 library, so writing the RFID reader's code in something type-safe would have helped not at all, unless they were prepared to re-implement the JPEG2000 standard in a type-safe language.

    15. Re:the usual by owlstead · · Score: 1

      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.

  15. Re:"..the Windows-based border-screening computer. by adnonsense · · Score: 2, Funny

    'k, I'm staying at home from now on...

  16. Computers help voters not vote counters. by jbn-o · · Score: 1

    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 & verification of voter-verified paper ballots is a serious advantage for blind and illiterate people to vote in private. The computer reads the candidate list aloud over headphones and the voter can press buttons to indicate their vote. This vote is printed on the ballot. All voters can use electronic devices to read the voter-verified paper ballot to double-check what the ballot says or bring in someone they trust to verify the ballot with them. Of course any electronic preparation or assistance must be optional for all voters.

    All ballots should be voter-verified and on paper so they can be stored and recounted whenever anyone wants.

    Champaign County in Illinois, USA uses a pair of ES&S machines to prepare and count (plus store) the ballots. Use of the ballot preparation machine is optional—one can fill in the bubbles manually with a pen or pencil. This machine can also (again, optionally) scan a completed ballot and report to the voter how it read the ballot (informing the user of how that user voted, and any over/undervotes). But all voters must feed their voter-verified paper ballot into the counting+storage machine. I despise the use of the second machine. I also despise that both of these machines run on proprietary software; some citizens in Urbana, Illinois are fighting for instant runoff voting for local elections and they have quite a fight ahead of them trying to convince the proprietor (ES&S) to change the vote-counting software to work with instant runoff. This is one reason I endorse the use of free software. Urbana ought to have the freedom to get whomever they want to alter the software to their liking. Urbana can pay to send their modified software through the government-required approval process.

    --
    Digital Citizen
  17. Re:Are borders are open! by Larry+Lightbulb · · Score: 1

    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

  18. Security Through Obscurity by RAMMS+EIN · · Score: 1

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

    --
    Please correct me if I got my facts wrong.
    1. Re:Security Through Obscurity by Aetuneo · · Score: 1

      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.

      --
      Everything is subjective.
  19. Re:This is the reason closed source is good by cianduffy · · Score: 1

    And possibly an electron microscope - lack of easy supply of these is probably the only reason DVB VideoGuard is still mostly unhacked after 9 years of use. Its been molested (smartcard sharing, CAM emulation) but there's no way to make clone cards or software patch boxes yet...

  20. Re:Are borders are open! by SL+Baur · · Score: 1

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

  21. Re:This is the reason closed source is good by ehrichweiss · · Score: 1

    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.

    --
    0x09F911029D74E35BD84156C5635688C0
  22. Re:Are borders are open! by morari · · Score: 1

    I'm still hoping that Latin will make a comeback, personally. I want a job where I can go out and catch Christians for the Colosseum games.

    --
    "He who can destroy a thing, controls a thing." --Paul Atreides, Dune
  23. Doesn't everyone check all inputs before using? by Futurepower(R) · · Score: 1

    I always check all inputs before using the data. Don't other people do that?

    1. Re:Doesn't everyone check all inputs before using? by karmatic · · Score: 1

      Validating all input can help, but it doesn't help when you have things like off-by-one errors. Remember people, null-terminated strings are 1 byte bigger than the number of characters in the string.

  24. Why use silly RFID toys? by dsgrntlxmply · · Score: 1
    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 24 hours for DNA sequencing results, in the departure hall with monopoly $3.75 bottled water, $9 greenish-ham sandwiches, Soviet-grade customer service, and incessantly repeated shrieky PA announcements, always makes me feel good because I am doing my part for national security.

    Eventually however, I might have to face the question of efficiency, and be compelled to move to some other country where I can inch through massive traffic congestion, then pay a fixer to have me waved into the squalid and grimy departure hall for a mere 2 hours, while watching the unsmiling gentlemen with the submachine guns make their frequent rounds. This followed by very close scrutiny of the rubber stamps on incomprehensible forms stamped only 45 seconds earlier by the person one floor below, as my luggage was being X-rayed to make certain that I was not trying to dodge both the stiff export tax on livestock and poultry, and the consequent opportunity to make a "facilitating payment".

  25. hardly a profitable business ... by freaker_TuC · · Score: 1

    ... if you are being so open about it.

    --
    --- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
  26. Re:Are borders are open! by MCraigW · · Score: 1

    They got better looking girls

    You never know, under those burkas...

  27. Re:Are borders are open! by photomonkey · · Score: 1

    You forgot Mandarin/Szechuan/Cantonese.

    --
    Message contains 1 attachment: spam.gif
  28. Re:This is the reason closed source is good by cianduffy · · Score: 1

    I follow it closely enough, although as all I want to get via satellite is unencrypted anyway, not as much as I used to. You might not, as it seems you're getting stuff mixed up...

    NDS CAMs can be emulated but they still need a real Videoguard card. This means you can use cards in unapproved units (Dreamboxes, or anything with a CI slot using a Dragon or TRex) but it doesn't mean you can get anything you've not paid for. Nobody has come close to extracting the keys from the card yet.

    Box patching is CAM emulation, or at least for all currently broken systems. Its been a very long time since they've done anything other than emulate a CAM to which you then provide keys. You can, at my last check, get the main satellite packages from most of Europe using a Technomate box appropriately altered - except those using DVB Videoguard.

  29. Re:This is the reason closed source is good by ehrichweiss · · Score: 1

    I think you're the one that's a bit mixed up. Using a card in an unapproved box is a hack, not emulation. See the definition of "emulate" for more details.

    --
    0x09F911029D74E35BD84156C5635688C0
  30. Re:This is the reason closed source is good by cianduffy · · Score: 1

    Its emulating the legitimate CAM - have you got a more appropriate word? Doubt it.

  31. Re:This is the reason closed source is good by ehrichweiss · · Score: 1

    If they could emulate the CAM they wouldn't need the card as a backup. They're not emulating the CAM, they're emulating the legit *receiver*. What you're describing is called "auxing" the card and they only use it because they haven't managed to get a bin dump/disassembly of the card. The device/computer simply mimics the correct box so they can send data to the card to get the correct keys for decryption and then send those to the actual receiver. And for the record they call that a HACK, not emulation.

    --
    0x09F911029D74E35BD84156C5635688C0
  32. Re:This is the reason closed source is good by cianduffy · · Score: 1

    I don't know if encryption systems work entirely different wherever you're from (DSS and 4DTV != DVB), but what you're proposing there makes absolutely no sense with DVB.

    Its entirely irrelevant what receiver I use, for instance, my Conax CAM - what is a PCMCIA card sized card reader - in. I can take it + the MTV Unlimited card in it out of my Technomate and put it in to my Humax and it'll work fine - as the CAM handles the entirity of the decoding. Now, a Dreambox or a Dragon/T-Rex CAM "mimics" (hey, guess what - thats emulating...) an original CAM of the format required, and uses the original card - or if the card has been hacked, emulates the card too.

    Now, the fact that DVB is the sole digital system here, and you appear to be in Kentucky - and its not even the dominant system there - may explain this...