Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Buffer Overflow Found in RFID Passport Readers

CowboyNeal posted more than 7 years ago | from the never-too-careful dept.

Security 96

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

Sorry! There are no comments related to the filter you selected.

This is the reason closed source is good (0, Flamebait)

LiquidCoooled (634315) | more than 7 years ago | (#20195141)

With closed source protected access software this kind of thing would not happen.
The open source commie pig brigade can't go messing with your plans.

(tongue in cheek of course)

Re:This is the reason closed source is good (2, Insightful)

MrCoke (445461) | more than 7 years ago | (#20195499)

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

Re:This is the reason closed source is good (1)

cianduffy (742890) | more than 7 years ago | (#20196785)

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

Re:This is the reason closed source is good (1)

ehrichweiss (706417) | more than 7 years ago | (#20197037)

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.

Re:This is the reason closed source is good (1)

cianduffy (742890) | more than 7 years ago | (#20205251)

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.

Re:This is the reason closed source is good (1)

ehrichweiss (706417) | more than 7 years ago | (#20207821)

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.

Re:This is the reason closed source is good (1)

cianduffy (742890) | more than 7 years ago | (#20213163)

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

Re:This is the reason closed source is good (1)

ehrichweiss (706417) | more than 7 years ago | (#20267485)

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.

Re:This is the reason closed source is good (1)

cianduffy (742890) | more than 7 years ago | (#20275347)

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

JPEG2000 (0, Troll)

mosiadh (1045736) | more than 7 years ago | (#20195161)

Nothing to see here, please move along

JPEG2000 (1)

Presto Vivace (882157) | more than 7 years ago | (#20195443)

Why am I not surprised?

Of course they are vulnerable (3, Insightful)

Anonymous Coward | more than 7 years ago | (#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.

Re: "The only thing .." (0)

Anonymous Coward | more than 7 years ago | (#20197401)

Yeah BUT .. there is something the makers of compilers could do (if they wanted to thoroughly distinguish their product from all the others) - and that is to have the ability (if told to do so) to insert the necessary code to automatically handle data overflows the right way (and every programmer worth their salt knows what that is).

Are borders are open! (0)

Anonymous Coward | more than 7 years ago | (#20195243)

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

Re:Are borders are open! (2, Funny)

Anonymous Coward | more than 7 years ago | (#20195263)

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

Re:Are borders are open! (0)

Anonymous Coward | more than 7 years ago | (#20195279)

lol

Re:Are borders are open! (1, Funny)

couchslug (175151) | more than 7 years ago | (#20195409)

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

Yes. :)

Re:Are borders are open! (0)

Anonymous Coward | more than 7 years ago | (#20196247)

Hope we have to learn Spanish. They got better looking girls, and we white are not reproducing anymore anyways, because we lacking the motivation that Hispanic people they have.
But, continuing on the topic, we should be learning Chinese Mandarin instead. The Chinese hackers are able to bypass that Chinese Wall of Fire, and not only that, they hacked e-passports long time ago. On the back rooms of the "silk market" stores you can find people that sells any passport from any country that deployed or will deploy e-passport technology. And those passports are even better than the ones issued by the respective governments. Anyways, with the sub-prime doom, China will be buying out our country in like 2 months, with those 2 trillion dollars in gold they got on their federal reserve building basement.

Re:Are borders are open! (1)

MCraigW (110179) | more than 7 years ago | (#20203289)

They got better looking girls

You never know, under those burkas...

Re:Are borders are open! (1)

morari (1080535) | more than 7 years ago | (#20197751)

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.

Re:Are borders are open! (1)

photomonkey (987563) | more than 7 years ago | (#20204325)

You forgot Mandarin/Szechuan/Cantonese.

Re:Are borders are open! (1)

Larry Lightbulb (781175) | more than 7 years ago | (#20196461)

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]

Re:Are borders are open! (1)

SL Baur (19540) | more than 7 years ago | (#20196885)

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

Explain to me how... (2, Funny)

binaryspiral (784263) | more than 7 years ago | (#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:Explain to me how... (2, Funny)

zolf13 (941799) | more than 7 years ago | (#20195297)

Orifice overflow requires orifice patching.

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

Zerth (26112) | more than 7 years ago | (#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.

Re:Explain to me how... (1)

westlake (615356) | more than 7 years ago | (#20195849)

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.

Re:Explain to me how... (1)

Tony Hoyle (11698) | more than 7 years ago | (#20195919)

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... (4, Informative)

h2g2bob (948006) | more than 7 years ago | (#20196115)

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:Explain to me how... (2, Interesting)

Anonymous Coward | more than 7 years ago | (#20196193)

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

Re:Explain to me how... (0)

Anonymous Coward | more than 7 years ago | (#20200029)

At the store I work at, my personal procedure, one which the rest have followed me on, is that if the card does not scan, then ask for another card or another method of payment. For any credit card we already ask for a state issued photo ID (passport, FOID card, ID, or Driver's License). Even if the card has a picture of the person on it, I will still ask for the state issued photo ID. *

I work in an adult "novelty" shop. If anyone complains I inform them that this is my policy, if they do not like it then they can order online or go to the next nearest shop carrying these items, which is a bit of a drive away. So I do have a bit of luxury in my position of forcing an ID check.

On debit cards, we only require the user to know the PIN number. That may seem wrong to some, but if someone has both your card and your PIN number, you have already lost. That is unless they have written the "See ID" on the back. I will respect their wish and ask for the ID even with a debit card in those situations.

Even if the general population does not feel the need to be overly secure, I will still do my best to keep some checks in place. I just wish I could find more stores that do what I do when making a purchase. That is the main reason I do it. I got tired of no one asking for an ID, or making any check that I was who I was, even when I had my ID in my hand waiting. I have since stopped using cards and started paying cash for anything I buy in person.

*IDs can be faked, even after the REALID goes into effect, IDs will be faked. But it is the reaction of the people when being asked for their ID even though their photo is on their card that can help out. Most will thank me for the added checking, others will run to their car to get their ID, while usually muttering under their breath about something. But the next time they come in, they are prepared.

Re:Explain to me how... (1)

swillden (191260) | more than 7 years ago | (#20200183)

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.

Re:Explain to me how... (4, Insightful)

Nazlfrag (1035012) | more than 7 years ago | (#20195329)

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.

Re:Explain to me how... (1)

Dachannien (617929) | more than 7 years ago | (#20195583)

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

Re:Explain to me how... (1, Informative)

Anonymous Coward | more than 7 years ago | (#20195669)

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.

Re:Explain to me how... (1)

TheAverageGuy (1124919) | more than 7 years ago | (#20195673)

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

Re:Explain to me how... (1)

DDLKermit007 (911046) | more than 7 years ago | (#20195777)

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

HERE (0)

Anonymous Coward | more than 7 years ago | (#20196941)

They-reboot-it-after-each-customer?

Re:Explain to me how... (1)

Dachannien (617929) | more than 7 years ago | (#20198129)

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:Explain to me how... (2, Funny)

solevita (967690) | more than 7 years ago | (#20196243)

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

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

Re:Explain to me how... (1)

swokm (1140623) | more than 7 years ago | (#20200993)

(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:Explain to me how... (3, Insightful)

SagSaw (219314) | more than 7 years ago | (#20195331)

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:Explain to me how... (1)

mpe (36238) | more than 7 years ago | (#20198003)

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.

Re:Explain to me how... (0)

Anonymous Coward | more than 7 years ago | (#20195333)

Passport is scanned
Bufferoverflow runs handcrafted code
RFID reader claims that this is indeed John Smith, and this is his picture, nonwithstaning the fact that there is no valid signature
Nobody takes a closer look, because the high-tech toys are happy
Owner walks on

Re:Explain to me how... (2, Funny)

shivamib (1034310) | more than 7 years ago | (#20195689)

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!

hardly a profitable business ... (1)

freaker_TuC (7632) | more than 7 years ago | (#20202089)

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

Re:Explain to me how... (-1, Redundant)

Anonymous Coward | more than 7 years ago | (#20195335)

A buffer overflow could let a bad passport inject code into the card reader, such as forcing it to show passports as valid, or accessing the big passport database that it authenticates against. So far, it's just a crash, which is not a big deal. But it could very well be code injection with another week of "research"

Re:Explain to me how... (4, Informative)

cgenman (325138) | more than 7 years ago | (#20195339)

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.

Re:Explain to me how... (1)

Warbothong (905464) | more than 7 years ago | (#20197193)

I know another way to screw up the readers. Smile: http://news.bbc.co.uk/1/hi/uk_politics/3541444.stm [bbc.co.uk] (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)

Re:Explain to me how... (1)

Antique Geekmeister (740220) | more than 7 years ago | (#20195433)

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.

Re:Explain to me how... (0, Troll)

shivamib (1034310) | more than 7 years ago | (#20195501)

Would it be possible to find out if my flight is going to crash? (Yeah, I live in Sao Paulo)

Re:Explain to me how... (1)

DrSkwid (118965) | more than 7 years ago | (#20195505)

I recommend "The Shellcoders Handbook"

Re:Explain to me how... (0, Troll)

tomhudson (43916) | more than 7 years ago | (#20195713)

"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 intervene, they all claim work-related traumatic stress disorder, go on permanent disability.

Honestly... (2, Insightful)

The tECHIDNA (677584) | more than 7 years ago | (#20195281)

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

Re:Honestly... (1)

nneonneo (911150) | more than 7 years ago | (#20195425)

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

30 more years of buffer overflows? (1)

Futurepower(R) (558542) | more than 7 years ago | (#20195813)

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

Re:30 more years of buffer overflows? (1)

FireFlie (850716) | more than 7 years ago | (#20196675)

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.

Doesn't everyone check all inputs before using? (1)

Futurepower(R) (558542) | more than 7 years ago | (#20197951)

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

Re:Doesn't everyone check all inputs before using? (0)

Anonymous Coward | more than 7 years ago | (#20198117)

I'm not exactly a secure programming expert, so bear with me...
How do you check the data before placing it into some memory buffer?

Re:Doesn't everyone check all inputs before using? (1)

karmatic (776420) | more than 7 years ago | (#20198977)

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:30 more years of buffer overflows? (1)

MCraigW (110179) | more than 7 years ago | (#20203565)

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.

Re:30 more years of buffer overflows? (0)

Anonymous Coward | more than 7 years ago | (#20209347)

ote that this doesn't stop you from overflowing your buffers, but does stop the execution of that data, thus avoiding those types of exploits.

Incorrect. It only makes it (a little bit) harder to exploit. Google "return to libc".

Computers help voters not vote counters. (1)

jbn-o (555068) | more than 7 years ago | (#20196367)

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 [irvforurbana.net] 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 [counterpunch.org] . 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.

Re:Honestly... (1)

proxy318 (944196) | more than 7 years ago | (#20196415)

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

obvious solution (1)

ILuvRamen (1026668) | more than 7 years ago | (#20195287)

It's not that RFID passports are a bad, insecure idea. It's just that they keep hiring complete morons that have no idea what they're doing to work on the systems. You know, kinda like voting machines.

That's interesting... (1)

shivamib (1034310) | more than 7 years ago | (#20195623)

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

"..the Windows-based border-screening computer.." (2, Funny)

adnonsense (826530) | more than 7 years ago | (#20195319)

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:"..the Windows-based border-screening computer. (1, Insightful)

Anonymous Coward | more than 7 years ago | (#20195489)

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

Re:"..the Windows-based border-screening computer. (2, Funny)

adnonsense (826530) | more than 7 years ago | (#20196179)

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

07706585058 (-1, Troll)

Anonymous Coward | more than 7 years ago | (#20195327)

07706585058

rob davies lytham st annes lancashire england united kingdom

Lost faith on RFID security long ago? (2, Insightful)

Lord Satri (609291) | more than 7 years ago | (#20195361)

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

Great! (1)

thatskinnyguy (1129515) | more than 7 years ago | (#20195775)

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

So glad my passport is valid for 10 years (1)

verucabong (1008319) | more than 7 years ago | (#20195825)

How did they expect something that is to be valid for 10 years to remain technologically impregnable? I think the RFID chips have been in US passports for what, 2 years now, and significant inroads are already being made into their innards. Glad I've still got a few years left on my "old skool" passport while they possibly find a better solution. On a similar note, why's everyone up in arms about Real ID? They say it's a national ID card...um, so just what the hell is a passport?!

the usual (2, Insightful)

m2943 (1140797) | more than 7 years ago | (#20196037)

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 (3, Insightful)

808140 (808140) | more than 7 years ago | (#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:the usual (1, Informative)

Anonymous Coward | more than 7 years ago | (#20197171)

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 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 [arm.com] 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.

Re:the usual (1)

808140 (808140) | more than 7 years ago | (#20197681)

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?

Re:the usual (1)

AdamInParadise (257888) | more than 7 years ago | (#20201277)

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

Re:the usual (1)

AdamInParadise (257888) | more than 7 years ago | (#20201201)

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.

Re:the usual (1)

zefrer (729860) | more than 7 years ago | (#20197503)

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:the usual (1)

808140 (808140) | more than 7 years ago | (#20197803)

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.

Re:the usual (0)

Anonymous Coward | more than 7 years ago | (#20199379)

Security isn't that high on the list... it's business, sorry.

Re:the usual (1)

808140 (808140) | more than 7 years ago | (#20200549)

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.

Re:the usual (0, Troll)

m2943 (1140797) | more than 7 years ago | (#20198491)

Why was this, do you think?

Because a whole generation of CS students was raised on C and didn't know any better.

Because in those days, computer resources were so expensive that it was foolish to waste them. Here's a hint: garbage collection is a bad idea if you have so little memory that you're actually likely to run out of it. Automatic bounds checking on arrays is expensive if your processor is slow enough.

You really don't know what you're talking about. First of all, although they are certainly useful, I didn't advocate specifically bounds checking and garbage collection, I advocated type safety; you can have a type safe language with exactly the same functionality and performance as C; in fact, several existed before C. C's lack of safety is both unnecessary and unusual. Second, you greatly overestimate the overhead of garbage collection and bounds checking; we are talking a few percent overhead at most, and often, safe languages give better performance (less fragmentation, more opportunities for compiler optimization). Third, you don't understand what this device is doing; this device is decompressing a JPEG2000 image and displaying it on some bitmapped display. Most likely, it's a small embedded PC--basically, a slow desktop machine.

You can't run a JVM on this thing, and even if you wanted to, it would be a bad idea.

Of course, you can run a JVM on this thing, first because "this thing" is likely as powerful as a slow desktop, and second because JVMs run even on smartcards. But I'm not advocating a JVM; JVMs are trying to solve a much harder problem than safety, namely sandboxing. All I'm saying is that the industry should move to a safe language instead of C; that costs nothing in terms of performance.

No, the problem why these problems keep cropping up is because many programmers are prejudiced, uneducated, and don't know what they're doing. Kind of like you.

Re:the usual (1)

808140 (808140) | more than 7 years ago | (#20200561)

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

Re:the usual (1)

m2943 (1140797) | more than 7 years ago | (#20201269)

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.

Re:the usual (2, Informative)

RAMMS+EIN (578166) | more than 7 years ago | (#20201469)

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

Re:the usual (1)

808140 (808140) | more than 7 years ago | (#20204211)

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.

Re:the usual (1)

IchBinEinPenguin (589252) | more than 7 years ago | (#20201831)

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.

Re:the usual (0)

Anonymous Coward | more than 7 years ago | (#20205931)

Actually, most of the inspection systems do run on a general purpose computer. You cannot handle biometrics and things like that on a reader alone. Sure thing, there is a reader, and the reader has firmware, but that is not the part that contains the JPEG libraries for sure. Anyway, you can run JVM's on all kinds of embedded devices, even smart cards, so you are definitely completely wrong there.

Re:the usual (1)

The Master Control P (655590) | more than 7 years ago | (#20199683)

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?

Re:the usual (1)

owlstead (636356) | more than 7 years ago | (#20206001)

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.

Security Through Obscurity (1)

RAMMS+EIN (578166) | more than 7 years ago | (#20196609)

``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:Security Through Obscurity (0)

Anonymous Coward | more than 7 years ago | (#20196725)

His point was that if vendors are using off-the-shelf libraries instead of each making their own, a vulnerability in one library would show up in all the vendors using that library. Hence, common.

Re:Security Through Obscurity (1)

Aetuneo (1130295) | more than 7 years ago | (#20196739)

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.

Why use silly RFID toys? (1)

dsgrntlxmply (610492) | more than 7 years ago | (#20201609)

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

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?