Electronic Voting Virus Demonstrated

Wednesday, September 13, 2006 by Scott Karlin

Today, Ari Feldman, Alex Halderman, and Ed Felten of Princeton University posted their security analysis of a Diebold AccuVote-TS electronic voting machine. This type of voting machine was used in several elections yesterday.

Electronic voting machines are basically repackaged personal computers that run election software. The researchers exploited significant flaws in the hardware, software, and the procedures that election officials would use to run an election based on Diebold AccuVote-TS voting machines to develop both election-stealing software as well as a virus that can spread such malicious software.

The security analysis includes a video and a detailed report. (There is a companion posting on the Freedom to Tinker site.) The video includes a demonstration of a mock election with a race between George Washington and Benedict Arnold. The votes are cast 4-1 in favor of Washington but the machine reports a 3-2 win by Arnold. The election-stealing software leaves no trace that the results are fraudulent. Significantly, the malicious software can be installed on a given machine in under a minute. The viral spread of the software can occur in multiple ways. In particular, it can spread when the election machines are initialized before an election with names of the candidates in each race.

In related news, Diebold AccuVote-TS voting machines were used in Montgomery County, Maryland, where election staffers mistakenly left voting cards behind in a warehouse. As reported, Circuit Court Judge Eric M. Johnson issued an order to extend the election by an hour to accommodate voters that were turned away in the morning.

OSCON 2006 – Thursday Keynotes

Thursday, August 3, 2006 by Scott Karlin

Here’s my weblog entry on some of the Thursday keynotes at OSCON 2006.

The Zen of Free
Simon Phipps, Chief Open Source Officer, Sun Microsystems
(Note that since giving his keynote, Mr. Phipps posted a weblog entry that includes a PDF of the text of his talk. What follows here is my spin on his talk.)
The keynote opened with a description of the many open source projects that Sun supports. Specifically included was Linux. However, since Sun produces Solaris (a competitor to Linux) it would be more accurate to say that “Sun is supporting Linux without actually supporting Linux.” Mr. Phipps used this koan-like statement as a segue to five koans which express the Zen of free software.

  1. Altruism Without Sacrifice
    Open source developers know that keeping their work to themselves reduces the overall value of their work.
  2. Licensing Without Lawyers
    Free and open-source software has evolved to the point that we now have a library of appropriate licenses from which to choose.
  3. Community Without Controlling
    With open-source licensing effectively a done-deal, governance within a community becomes a far more important issue. The problem is that there are no codified “benchmarks” or reference designs for governance including the important issues of who has commit access to a project and who can make binding decisions.
  4. Lock-in is Lock-Out
  5. Staying Because of the Freedom to Leave
    (These two koans are closely related so I’ll lump them together.) Open source software is an important springboard to freedom; in particular, the freedom to stop using a particular software product is a key freedom. For example, if multiple software products all support a common data format, one has the freedom to try something new and/or different. The best way to scare off early adopters of a software product is to force them to use a proprietary data format. Just knowing that one can easily move from product to product is a great way of maintaining market share. Expanding on this, it is critical to have data formats that allow equal implementations on different operating systems, that the data format specifications be transparent (not handed down from a particular company), and that the standards be maintained by impartial stewarding organizations.

5 A Day
Robert “r0ml” Lefkowitz
This was a highly entertaining talk that is all but impossible to adequately capture in a weblog entry. On the surface, he basically said that open source software is like a tomato. (Perhaps you had to be there…) The main take-away is that organizations should have the goal of one-third of their software use be open source. Said another way, organizations should use (at most) twice the amount of closed source as open source software. Note that even though the copyright notice for Windows XP mentions that portions of its code are derived from Berkeley Unix, you can’t count it as open source. :-)

Developers: You’ve Got the Power – Now What?
Stephen O’Grady, RedMonk (industry analyst)
(The speaker provides links to his presentation slides in his blog entry.)
In this keynote, the speaker noted that “in the beginning” CIOs of companies controlled the money which in turn meant that they had control over developers. With the advent of open source software, there has been a power shift from the closed source companies to the open source development communities. In the words of several noted figures (including Spiderman), with this shift in power comes a shift in responsibility and stewardship. The speaker then gave five admonitions to open source developers:

  1. educate, evangelize, and market (the concept of open source software)
  2. make open data a priority
  3. lower the barriers to entry (one good way is superb documentation)
  4. be creative (don’t try to play the same game as competing closed source solutions)
  5. work together

Making Tech Documentaries: How and Why
Jason Scott, Curator, TEXTFILES.COM
This was a rather interesting keynote in that it wasn’t really about technology. It was more about preserving the history of technological development. The speaker finished a documentary last summer on the history of bulletin board systems (BBSes) and is currently working on “Get Lamp”—a documentary of text adventure games. The talk revolved around the process of collecting the footage and concluded with the recommendation that people capture some history for posterity. In particular, he suggests capturing photographs of your workplace and saving interesting artifacts as well as committing to words some of what you remember about your personal history. I think this is a great idea and I plan to post entries describing the good-old days of computing from time to time.

How Open Source Projects Survive Poisonous People (And You Can Too)

Monday, July 31, 2006 by Scott Karlin

OSCON 2006 Session Report
Title: How Open Source Projects Survive Poisonous People (And You Can Too)
Speakers: Brian W. Fitzpatrick, Ben Collins-Sussman — Google, Inc.

The central theme of this talk is that attention and focus are the currency of an open source project and which must be protected. Poisonous people can erode both of these attributes. The speakers presented their opinions based on their experiences with the Subversion project. As they describe it, the Subversion project uses the “community model” rather than the “benevolent dictatorship model.” The implication is that surviving poisonous people in this model may require more subtlety.

While discussing poisonous people, the speakers also gave their take on the environment and culture of a healthy open source project.

Avoid Paralysis
Besides focus and attention, I think another key element of a project is momentum. The speakers’s take on this is to avoid paralysis. Specifically, watch out for perfectionists as well as the process-obsessed. Both of these types of people are often well-meaning but their traits, in some cases, can bog down a project. The quote they used (I missed the attribution) was, “The perfect is the enemy of the good.”

Interact Effectively with the Community
When interacting with members of the community, it is important to use politeness, respect, trust, and humility. In addition, it is important to have a thick skin and not take things too personally. When dealing with users on discussion lists, don’t try to reply to every message in a thread. Also, don’t rehash old discussions; when these come up, send people to the mail archives or documentation.

Document
In addition to documenting the current state of the project, it is also important to document the history. A changelog captures bug fixes and enhancements. Just as important to capture, however, are design decisions and lessons learned (i.e., mistakes made). By documenting design decisions, one can avoid rehashing settled matters on the discussion lists.

Have Healthy Code-Collaboration Policies
The speakers recommended the following (non-inclusive) list of healthy code-collaboration policies:

  • Send commit emails and encourage reviews of the committed code.
  • Make big changes on branches for easier review.
  • Encourage developers with big ambitions (1) to pre-announce their intentions and (2) to have them commit in small pieces on a separate branch. This gives everyone the chance to both review the design as well as review the code as it develops. Huge, unreviewed commits (i.e., “power plants”) slow progress and can lead to animosity between the committer and the developers.
  • Be generous with code branches.
  • Maintain a high “bus-factor” on the components of the project. The “bus-factor” represents how many developers would have to get hit by a bus before development on a component would become crippled.
  • Don’t allow names in files. This is part of the culture of humility.

Have Well-Defined Development Processes
This speakers emphasized the need to have well-defined development processes in place at the beginning of the project. This includes software releases (e.g., backport bug fixes, test releases, tarball builds), patch acceptance/review, and admitting new committers (the project founders establish the culture and from there it becomes self-selecting). In rare cases, issues must be put to a vote (remember, there is no benevolent dictator in their model), but this should be a last resort; a healthy community rarely needs to vote.

Detect Poisonous People
Because poisonous people put a drain on the project, it is important to detect them. Some common traits of poisonous people include: use of silly (or multiple) nicknames, overuse of capital letters in their postings, generally clueless (e.g., they are unable to pick up the mood of the discussion, they don’t understand project goals, they don’t read the documentation), are hostile (e.g., insults, demands, threats of blackmail, accusations of conspiracy), and a lack of cooperation (willing to complain–but not help, unwilling to discuss design, too insecure to take criticism).

Handle Poisonous People
Once you have identified a poisonous person, don’t engage them, don’t get emotional, and don’t take the flamebait.
That said, do pay careful attentions to newcomers even if they are annoying at first—they may turn out to be valued contributors. If someone posts a flame, try hard to discern the issue and address only that. Ultimately, you must know when to give up and ignore them (or even expel them from the community). Stay cool but stand your ground.

The talk wrapped up with a summary of the above followed by some Q&A.

OSCON 2006 Recap

Monday, July 31, 2006 by Scott Karlin

Last week, I attended a part of the O’Reilly Open Source Convention (OSCON 2006) in Portland, Oregon. The next few posts will be a recap of my notes for some of the sessions I attended.

RFID Passports – Hi, I’m a Foreigner

Friday, July 14, 2006 by Scott Karlin

The CNNMoney.com article “e-Passports: Ready or not here they come” reports on the security and personal safety risks associated with the RFID (radio frequency identification) tags that will be embedded in U.S. passports by August 2006. These tags are meant to be read via radio waves from a “short” distance by a passport reader; they are designed to protect against counterfeit passports and to streamline the processing of visitors. However, as the article states, there are concerns:

“Basically, you’ve given everybody a little radio-frequency doodad that silently declares ‘Hey, I’m a foreigner,’” says author and futurist Bruce Sterling, who lectures on the future of RFID technology. “If nobody bothers to listen, great. If people figure out they can listen to passport IDs, there will be a lot of strange and inventive ways to exploit that for criminal purposes.”

There are two issues. The first is that, currently, few people carry around anything with an RFID tag. By simply detecting the presence of such a tag, a bad guy could infer that the person is likely to be a foreigner. The second issue is that the tags are likely to be cracked — meaning that the personal information in the passport would be available to ID thieves.

I definitely see a market for passport holders with RF shielding.

Via Slashdot.

Net Neutrality

Tuesday, July 11, 2006 by Scott Karlin

Ed Felten has posted a paper called Nuts and Bolts of Network Neutrality. It provides just enough technical details of the Internet to nicely cover the policy issues of network neutrality.

Watch for Automatic Updates

Tuesday, June 13, 2006 by Scott Karlin

I was quite pleased to see the Google has deployed a new beta release of Google Earth with support for Linux. After downloading it and beginning the install process I was stopped in my tracks by this clause in the license agreement:

4. AUTOMATIC UPDATES The Software may communicate with Google servers from time to time to check for available updates to the Software, such as bug fixes, patches, enhanced functions, missing plug-ins and new versions (collectively, “Updates”). By installing the Software, you agree to automatically request and receive Updates.

I don’t mind the software checking to see if there are updates available; I do mind if these are automatically installed. I can’t tell from their wording if “receive Updates” means both download and install. Two issues come to mind with this kind of mechanism. First, an automatic update mechanism is a potential vector for infection. Second, I may not want the update as it may remove a feature or cause an incompatibility with other software installed on my computer.

Google’s AJAX Generator

Thursday, May 18, 2006 by Scott Karlin

As reported by Slashdot, Google has announced the Google Web Toolkit (GWT) which allows web developers to create AJAX applications in Java. The GWT then translates the Java code into client-side code. The client-side code is either Java bytecode (“hosted mode”) during development or JavaScript and HTML (“web mode”) for production deployment.

It should be noted that the GWT is not without privacy concerns. As clearly stated by Google, hosted mode does send some information back to Google:

Privacy notice: When you use the Google Web Toolkit’s hosted web browser, the application sends a request back to Google’s servers to check to see if you are using the most recent version of the product. As a part of this request, Google will log usage data including a timestamp of the date and time you downloaded the Google Web Toolkit and the IP address for your computer. We won’t log cookies or personal information about you, and we will use any data we log only in the aggregate to operate and improve the Google Web Toolkit and other Google Services. Please see the Google Privacy Policy for more information.

Since this information is only sent in hosted mode, it will mostly apply to developers. A deployed system would use web mode which does not appear to contact Google. Of course, depending on the security requirements of a deployed application, one would want to audit the generated JavaScript and HTML code as a bug (or worse) in the GWT could lead to security holes. To see what I mean, read the classic Ken Thompson’s ACM Turing Award lecture, Reflections on Trusting Trust (PDF).

While this kind of technology has been around for a while, the fact that Google has published their own toolkit may lead to a de facto standard. I expect to take the GWT for a spin soon.

Boarding Pass to Identity Theft

Thursday, May 4, 2006 by Scott Karlin

The Guaridan reports that with just a discarded British Airways boarding-pass stub that was found in a dustbin, the journalist and his computer expert was able to access personal details:

We logged on to the BA website, bought a ticket in [the passenger's] name and then, using the frequent flyer number on his boarding pass stub, without typing in a password, were given full access to all his personal details – including his passport number, the date it expired, his nationality (he is Dutch, living in the UK) and his date of birth. The system even allowed us to change the information.

I’m a bit surprised that this level of access was granted without typing a password. I wonder if the lack of a password is a system-wide feature or something that is configurable on a per-account basis.

The article then dives into the recent history of information gathering by the airlines/governments including the CAPPS II and subsequent Secure Flight programs. For additional background, see these weblog postings by Bruce Schneier and Ed Felten.

Composing Thunderbird E-Mail with Vi

Wednesday, May 3, 2006 by Scott Karlin

Do you ever wish you could use the vi text editor to compose e-mail messages while using Thunderbird? If so, then read on:

For my day-to-day e-mail, I use Mutt as my e-mail client and Vim as my editor for composing messages. Most of the time, Mutt’s advantages outweigh its disadvantages (e.g., a plain text e-mail client insulates me from various forms of malware). On occasion, I find that I need to view an HTML-only message or want to check an RSS feed. This is when I fire up Thunderbird. For me, the downside to Thunderbird is that the integrated editor is not vim—my fingers keep reaching for the “i” key and the “Esc” key and I find myself wanting to pipe portions of my messages through various Unix filters such as sort and expand. Rather than wean myself off of vim, I use Alexandre Feblot’s External Editor extension to Thunderbird so I can use gvim (graphical vim) to compose messages while I use Thunderbird. Of course, I could always compose a message in vim and then paste it into the compose window of Thunderbird; however, that’s not nearly as slick. Installation steps below were adapted from the External Editor site and this article.

Prerequisites

  1. Thunderbird and gvim should already be installed on your machine.

Get the External Editor extension

  1. Download the External Editor extension (an .xpi file) to your local machine. (At the time of this post, the downloaded file is named exteditor_v072.xpi.)

Install the Extension

  1. Start Thunderbird
  2. From the menu bar, select Tools –> Extensions and then click “Install”
  3. Browse to your .xpi file and open it; in the window that pops up, click “Install Now”
  4. Quit and then restart Thunderbird so that it picks up the extension.

Configure External Editor to use gvim

  1. From the menu bar, select Tools –> Extensions. Select the External Editor extension and then click “Options.”
  2. In the window that opens enter the text editor information
  3. This step depends on the operating system you are using.
    For Linux:
    Enter “gvim --nofork” in the Text Editor box and adjust the Edit headers section as desired. For example:

    External Editor Settings Window
    For Windows:
    Use the Browse button to find the path to the gvim.exe and then tack on “--nofork” to the end. I used “C:\Program Files\Vim\vim63\gvim.exe --nofork” — note that the nofork option doesn’t seem to have an effect under Windows. I left it there to be consistent with the Linux directions.
  4. Click “OK” to dismiss the External Editor Settings window and then close the Extensions window.

Add the toolbar to the compose window

  1. Open a compose window by clicking on the “Write” icon.
  2. From the menu bar of the Compose window, select View –> Toolbars –> Customize to open a Customize Toolbar window.
  3. Drag and drop the icon for “External Editor” in the Customize Toolbar window to the toolbar of the Compose window.
  4. Dismiss the Customize Toolbar window by clicking the “OK” button
  5. Close the empty compose window and click “Don’t save” in the requestor that pops up

The next time you compose a message, there will be a Gvim icon on the toolbar (in place of the “External Editor” icon) that you can use to edit your message.

Enjoy.