November 24, 2024

Posts Comments

Election 2008: What Might Go Wrong

November 3, 2008 by

Tomorrow, as everyone knows, is Election Day in the U.S. With all the controversy over electronic voting, and the anticipated high turnout, what can we expect to see? What problems might be looming? Here are my predictions.

Long lines to vote: Polling places will be strained by the number of voters. In some places the wait will be long – especially where voting requires the use of machines. Many voters will be willing and able to wait, but some will have to leave without casting votes. Polls will be kept open late, and results will be reported later than expected, because of long lines.

Registration problems: Quite a few voters will arrive at the polling place to find that they are not on the voter rolls, because of official error, or problems with voter registration databases, or simply because the voter went to the wrong polling place. New voters will be especially likely to have such problems. Voters who think they should be on the rolls in a polling place can file provisional ballots there. Afterward, officials must judge whether each provisional voter was in fact eligible, a time-consuming process which, given the relative flood of provisional ballots, will strain official resources.

Voting machine problems: Electronic voting machines will fail somewhere. This is virtually inevitable, given the sheer number of machines and polling places, the variety of voting machines, and the often poor reliability and security engineering of the machines. If we’re lucky, the problems can be addressed using a paper trail or other records. If not, we’ll have a mess on our hands.

How serious the mess might be depends on how close the election is. If the margin of victory is large, as some polls suggest it may be, then it will be easy to write off problems as “minor” and move on to the next stage in our collective political life. If the election is close, we could see a big fight. The worse case is an ultra-close election like in 2000, with long lines, provisional ballots, or voting machine failures putting the outcome in doubt.

Regardless of what happens on Election Day, the next day — Wednesday, November 5 — will be a good time to get started on improving the next election. We have made some progress since 2004 and 2006. If we keep working, our future elections can be better and safer than this one.

Filed Under: Uncategorized Tagged With: , ,

Report on the Sequioa AVC Advantage

October 17, 2008 by

Today I am releasing an in-depth study of the Sequoia AVC Advantage direct-recording electronic (DRE) voting machine, available at citp.princeton.edu/voting/advantage. I led a team of six computer scientists in a monthlong examination of the source code and hardware of these voting computers, which are used in New Jersey, Pennsylvania, and other states.

The Rutgers Law School Constitutional Litigation Clinic filed a lawsuit seeking to decommission of all of New Jersey’s voting computers, and asked me to serve as an expert witness. This year the Court ordered the State of New Jersey and Sequoia Voting Systems to provide voting machines and their source code for me to examine. By Court Order, I can release the report no sooner than October 17th, 2008.

Accompanying the report is a video and a FAQ.

Executive Summary

I. The AVC Advantage 9.00 is easily “hacked” by the installation of fraudulent firmware. This is done by prying just one ROM chip from its socket and pushing a new one in, or by replacement of the Z80 processor chip. We have demonstrated that this “hack” takes just 7 minutes to perform.

The fraudulent firmware can steal votes during an election, just as its criminal designer programs it to do. The fraud cannot practically be detected. There is no paper audit trail on this machine; all electronic records of the votes are under control of the firmware, which can manipulate them all simultaneously.

II. Without even touching a single AVC Advantage, an attacker can install fraudulent firmware into many AVC Advantage machines by viral propagation through audio-ballot cartridges. The virus can steal the votes of blind voters, can cause AVC Advantages in targeted precincts to fail to operate; or can cause WinEDS software to tally votes inaccurately. (WinEDS is the program, sold by Sequoia, that each County’s Board of Elections uses to add up votes from all the different precincts.)

III. Design flaws in the user interface of the AVC Advantage disenfranchise voters, or violate voter privacy, by causing votes not to be counted, and by allowing pollworkers to commit fraud.

IV. AVC Advantage Results Cartridges can be easily manipulated to change votes, after the polls are closed but before results from different precincts are cumulated together.

V. Sequoia’s sloppy software practices can lead to error and insecurity. Wyle’s Independent Testing Authority (ITA) reports are not rigorous, and are inadequate to detect security vulnerabilities. Programming errors that slip through these processes can miscount votes and permit fraud.

VI. Anomalies noticed by County Clerks in the New Jersey 2008 Presidential Primary were caused by two different programming errors on the part of Sequoia, and had the effect of disenfranchising voters.

VII. The AVC Advantage has been produced in many versions. The fact that one version may have been examined for certification does not give grounds for confidence in the security and accuracy of a different version. New Jersey should not use any version of the AVC Advantage that it has not actually examined with the assistance of skilled computer-security experts.

VIII. The AVC Advantage is too insecure to use in New Jersey. New Jersey should immediately implement the 2005 law passed by the Legislature, requiring an individual voter-verified record of each vote cast, by adopting precinct-count optical-scan voting equipment.

Filed Under: Uncategorized Tagged With: , ,

Hot Custom Car (software?)

October 17, 2008 by

I’ve found Tim’s bits on life post-driving interesting. I’ve sometimes got a one-track mind, though- so what I really want to know is if I’ll be able to hack on that self-driving car. I mentioned this to Tim, and he said he wasn’t sure either- so here is my crack at it.

We’re not very good at making choices like this. Historically, liability constrained software development at large institutions (the airlines had a lot of reasons not to let people to hack on their airplanes) and benign neglect was sufficient to regulate hacking of personal software- if you hacked your PC or toaster, no one cared because it had no impact (a form of Lessig’s regulation by architecture). The net result was that we didn’t need to regulate software very much, we got lots of innovation from individual developers, and we stayed bad at making choices like ‘how should we regulate people’s ability to hack?’

Individuals are now beginning to own hackable devices that can also harm the neighbors, though, so the space in between large institution and isolated hacker is filling up. For example, the FCC regulates your ability to modify your own wireless devices, so that you can’t interfere with other people’s spectrum. And some of Prof. Jonathan Zittrain’s analysis suggests that we might want to even regulate PCs, since they can now frequently be vectors for spam and viruses. Tim and I are normally fairly anti-regulation, and pro-open source, but even we are aware that cars running around all over the place driven by by potentially untested code might also fit in this gap- and be more worthy of regulation.

So what should happen? Should we be able to hack our cars (more than we already do), and if so, under what conditions?

It’d help if we could better measure the risks and benefits involved. Unfortunately, probably because we regulate software so rarely, our metrics for assessing the risks and benefits of software development aren’t very good. One such metric is Prof. Zittrain’s ‘generativity’; Dan Wallach’s proposal to measure the ‘O(n)’ of potential system damage is another. Neither are perfect fits here, but that only confirms that we need more such tools in our software policy toolkit.

This lack of tools shouldn’t stop us from some basic, common-sense analysis, though. On the pro side, the standard arguments for open source apply, though perhaps not as strongly as usual, since many casual hackers might be discouraged at the thought of hacking their own car. We probably would want car manufacturers to pool their safety expertise, which would be facilitated by openness. Finally, we might also want open code for auditing reasons- with millions of lives on the line, this seems like a textbook case for wanting ‘many eyes‘ to take a look at the code.

If we accept these arguments on the ‘pro’ hacking side, what then? First, we could require that the car manufacturers use test-driven development, and share those tests with the public- perhaps even allowing the public to add new tests. This would help avoid serious safety problems in the ‘original’ code, and home hackers might be blocked from loading new code into their cars unless the code was certified to have passed the tests. Second, we could treat the consequences very seriously- ‘driving’ with bad code could be treated similarly to DUI. Third, we could make sure that the safety fallbacks (emergency brake systems, etc.) are in separate, redundant (and perhaps only mechanical?) unhackable systems. Having such systems is going to be good engineering whether the code is open or not, and making them unhackable might be a good compromise. (Serious engineers, instead of compsci BAs now in law school, should feel free to suggest other techniques in the comments.)

Bottom line? First, we don’t really know- we just have pretty poor analytical tools for this type of problem. But if we take a stab at it, we can see that there are some potential solutions that might be able to harness the innovation and generativity of open source in our cars without significantly compromising our safety. At least, not compromising it any moreso than the already crazy core idea 🙂

[picture is ‘Car Show 2‘, by starmist1, used under the CC-BY license.]

Filed Under: Privacy & Security Tagged With:

Popular Websites Vulnerable to Cross-Site Request Forgery Attacks

September 29, 2008 by

Update Oct 15, 2008 We’ve modified the paper to reflect the fact that the New York Times has fixed this problem. We also clarified that our server-side protection techniques do not protect against active network attackers.

Update Oct 1, 2008 The New York Times has fixed this problem. All of the problems mentioned below have now been fixed.

Today Ed Felten and I (Bill Zeller) are announcing four previously unpublished Cross-Site Request Forgery (CSRF) vulnerabilities. We’ve described these attacks in detail in a technical report titled Cross-Site Request Forgeries: Exploitation and Prevention.

We found four major vulnerabilities on four different sites. These vulnerabilities include what we believe is the first CSRF vulnerability that allows the transfer of funds from a financial institution. We contacted all the sites involved and gave them ample time to correct these issues. Three of these sites have fixed the vulnerabilities listed below, one has not.

CSRF vulnerabilities occur when a website allows an authenticated user to perform a sensitive action but does not verify that the user herself is invoking that action. The key to understanding CSRF attacks is to recognize that websites typically don’t verify that a request came from an authorized user. Instead they verify only that the request came from the browser of an authorized user. Because browsers run code sent by multiple sites, there is a danger that one site will (unbeknownst to the user) send a request to a second site, and the second site will mistakenly think that the user authorized the request.

If a user visits an attacker’s website, the attacker can force the user’s browser to send a request to a page that performs a sensitive action on behalf of the user. The target website sees a request coming from an authenticated user and happily performs some action, whether it was invoked by the user or not. CSRF attacks have been confused with Cross-Site Scripting (XSS) attacks, but they are very different. A site completely protected from XSS is still vulnerable to CSRF attacks if no protections are taken. For more background on CSRF, see Shiflett, Grossman, Wikipedia, or OWASP.

We describe the four vulnerabilities below:

1. ING Direct (ingdirect.com)

Status: Fixed

We found a vulnerability on ING’s website that allowed additional accounts to be created on behalf of an arbitrary user. We were also able to transfer funds out of users’ bank accounts. We believe this is the first CSRF vulnerability to allow the transfer of funds from a financial institution. Specific details are described in our paper.

2. YouTube (youtube.com)

Status: Fixed

We discovered CSRF vulnerabilities in nearly every action a user could perform on YouTube. An attacker could have added videos to a user’s "Favorites," added himself to a user’s "Friend" or "Family" list, sent arbitrary messages on the user’s behalf, flagged videos as inappropriate, automatically shared a video with a user’s contacts, subscribed a user to a "channel" (a set of videos published by one person or group) and added videos to a user’s "QuickList" (a list of videos a user intends to watch at a later point). Specific details are described in our paper.

3. MetaFilter (metafilter.com)

Status: Fixed

A vulnerability existed on Metafilter that allowed an attacker to take control of a user’s account. A forged request could be used to set a user’s email address to the attacker’s address. A second forged request could then be used to activate the "Forgot Password" action, which would send the user’s password to the attacker’s email address. Specific details are described in our paper.

(MetaFilter fixed this vulnerability in less than two days. We appreciate the fact that MetaFilter contacted us to let us know the problem had been fixed.)

4. The New York Times (nytimes.com)

Status: Not Fixed. We contacted the New York Times in September, 2007. As of September 24, 2008, this vulnerability still exists. This problem has been fixed.

A vulnerability in the New York Time’s website allows an attacker to find out the email address of an arbitrary user. This takes advantage of the NYTimes’s "Email This" feature, which allows a user to send an email about a story to an arbitrary user. This emails contains the logged-in user’s email address. An attacker can forge a request to active the "Email This" feature while setting his email address as the recipient. When a user visit’s the attacker’s page, an email will be sent to the attacker’s email address containing the user’s email address. This attack can be used for identification (e.g., finding the email addresses of all users who visit an attacker’s site) or for spam. This attack is particularly dangerous because of the large number of users who have NYTimes’ accounts and because the NYTimes keeps users logged in for over a year.

Also, TimesPeople, a social networking site launched by the New York Times on September 23, 2008, is also vulnerable to CSRF attacks.

We hope the New York Times will decide to fix these vulnerabilities now that they have been made public. The New York Times appears to have fixed the problems detailed above.

Mitigation

Our paper provides recommendations for preventing these attacks. We provide a server-side plugin for the PHP MVC framework Code Igniter that can completely prevent CSRF. We also provide a client-side Firefox extension that can protect users from certain types of CSRF attacks (non-GET request attacks).

The Takeaway

We’ve found CSRF vulnerabilities in sites that have a huge incentive to do security correctly. If you’re in charge of a website and haven’t specifically protected against CSRF, chances are you’re vulnerable.

The academic literature on CSRF attacks has been rapidly expanding over the last two years and we encourage you to see our bibliography for references to other work. On the industry side, I’d like to especially thank Chris Shiflett and Jeremiah Grossman for tirelessly working to educate developers about CSRF attacks.

Filed Under: Uncategorized Tagged With: ,

How Yahoo could have protected Palin's email

September 21, 2008 by

Last week I criticized Yahoo for their insecure password recovery mechanism that allowed an intruder to take control of Sarah Palin’s email account. Several readers asked me the obvious follow-up question: What should Yahoo have done instead?

Before we discuss alternatives, let’s take a minute to appreciate the delicate balance involved in designing a password recovery mechanism for a free, mass-market web service. On the one hand, users lose their passwords all the time; they generally refuse to take precautions in advance against a lost password; and they won’t accept being locked out of their own accounts because of a lost password. On the other hand, password recovery is an obvious vector for attack — and one exploited at large scale, every day, by spammers and other troublemakers.

Password recovery is especially challenging for email accounts. A common approach to password recovery is to email a new password (or a unique recovery URL) to the user, which works nicely if the user has a stable email address outside the service — but there’s no point in sending email to a user who has lost the password to his only email account.

Still, Yahoo could be doing more to protect their users’ passwords. They could allow users to make up their own security questions, rather than offering only a fixed set of questions. They could warn users that security questions are a security risk and that users with stable external email addresses might be better off disabling the security-question functionality and relying instead on email for password recovery.

Yahoo could also have followed Gmail’s lead, and disabled the security-question mechanism unless no logged-in user had accessed the account for five days. This clever trick prevents password “recovery” when there is evidence that somebody who knows the password is actively using the account. If the legitimate user loses the password and doesn’t have an alternative email account, he has to wait five days before recovering the password, but this seems like a small price to pay for the extra security.

Finally, Yahoo would have been wise, at least from a public-relations standpoint, to give extra protection to high-profile accounts like Palin’s. The existence of these accounts, and even the email addresses, had already been published online. And the account signup at Yahoo asks for a name and postal code so Yahoo could have recognized that this suddenly-important public figure had an account on their system. (It seems unlikely that Palin gave a false name or postal code in signing up for the account.) Given the public allegations that Palin had used her Yahoo email accounts for state business, these accounts would have been obvious targets for freelance “investigators”.

Some commenters on my previous post argued that all of this is Palin’s fault for using a Yahoo mail account for Alaska state business. As I understand it, the breached account included some state business emails along with some private email. I’ll agree that it was unwise for Palin to put official state email into a Yahoo account, for security reasons alone, not to mention the state rules or laws against doing so. But this doesn’t justify the break-in, and I think anyone would agree that it doesn’t justify publishing non-incriminating private emails taken from the account.

Indeed, the feeding frenzy to grab and publish private material from the account, after the intruder had published the password, is perhaps the ugliest aspect of the whole incident. I don’t know how many people participated — and I’m glad that at least one Good Samaritan tried to re-lock the account — but I hope the republishers get at least a scary visit from the FBI. It looks like the FBI is closing in on the initial intruder. I assume he is facing a bigger punishment.

Filed Under: Privacy & Security Tagged With: , ,