darkreading: voting machines

[weld at vulnwatch.org (Chris Wysopal)]

I think there is an easy solution to this.  It is called a 3rd party
audit.  This is done all the time in the financial community.  Software
vendors fork over their latest product version and sometimes source code
and a credible 3rd party looks for holes.  It is sometimes paid for by the
customer and sometimes the customer makes it a requirement of purchase so
it is paid for by the vendor.  We did many of these at @stake.

Why do banks do this?  Some say it is because they don't like to go to
jail or be fined for not following the nebulous "reasonable care"
provisions of the regulations they are required to follow.  It is more
likely they don't want to tarnish their trusted brand image.

A voting commission has neither of these motivations.  No one gets fined
or fired or put in jail for fielding a system that ends up being used for
voter fraud.  There is no trusted image to protect.

The "pretend stuff in the lab" comment is especially discouraging because
what Rubin and Felten are doing in the lab is EXACTLY what Diebold should
be doing in their testing lab.  A product that has security requirements
is not fit to be fielded until security testing has been performed.

-Chris

-= The Art of Software Security Testing: Identifying Software Security
-= Flaws by Chris Wysopal, Lucas Nelson, Dino Dai Zovi, and Elfriede
-= Dustin, Available Nov 27, 2006

On Tue, 10 Oct 2006, Jeremy Epstein wrote:

> Gary,
>
> Interesting point.  I'm on the Virginia state commission charged with making
> recommendations around voting systems, and we watched the Princeton video as
> part of our most recent meeting.  The reaction from the election officials
> was amusing and scary: "if this is so real, why don't you hack a real
> election instead of this pretend stuff in the lab".  Pointing out that it
> would (most likely) be a felony, and people like Rubin, Felten, and others
> are trying to help security not go to jail didn't seem to impress them.
> Also pointing out that the Rubin & Felten examples used out-of-date code
> because vendors won't share anything up-to-date doesn't seem to impress
> them.  [This in response to Diebold's claim that they were looking at old
> code, and the problems are all "fixed".]
>
> I frankly don't think anything is going to impress the election officials
> (and some of the elected officials) short of incontrovertible evidence of a
> DRE meltdown - and of course, we know that there could well be a failure
> (and may have been failures) that are unproveable thanks to the nature of
> software.
>
> --Jeremy
>
> P.S. One of the elected officials on the commision insisted that Felten
> couldn't possibly have done his demo exploit without source code, because
> "everyone" knows you can't do an exploit without the source.  Unfortunately,
> the level of education that needs to be provided to someone like that is
> more than I can provide in a Q&A format.  I tried giving as an example that
> around 50% of the Microsoft updates are due to flaws found by people without
> source, but he wouldn't buy it.... (he was using a Windows laptop, but
> doesn't seem to understand where the fixes come from).
>
> > -----Original Message-----
> > From: sc-l-bounces at securecoding.org
> > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw
> > Sent: Monday, October 09, 2006 12:19 PM
> > To: SC-L at securecoding.org
> > Cc: dwallach at cs.rice.edu; felten at princeton.edu; rubin at jhu.edu
> > Subject: [SC-L] darkreading: voting machines
> >
> > Hi all,
> >
> > I'm sure that many of you saw the "Ed Felten and friends
> > break Diebold machines" story a couple of weeks ago...maybe
> > in DDJ or on /..  I wrote a piece about the crack for
> > darkreading, which you can find here:
> >
> > http://www.darkreading.com/document.asp?doc_id=105188&WT.svl=column1_1
> >
> > The most interesting thing from an sc-l perspective about
> > this column is that it emphasizes a client need we're often
> > forced to address---the need for a demo exploit.  Sometimes
> > those on the receiving end of a software security
> > vulnerability don't believe that findings are real.
> > An often-repeated excuse for doing nothing is "well, that's
> > just a theoretical attack and it's too academic to matter."
> > I can't tell you how many times I've heard that refrain.
> >
> > When that happens, building an exploit is often the only
> > clear next step.  And yet we all know how expensive and hard
> > exploit development is.
> >
> > In this case, Diebold consistently downplay'ed Avi Rubin's
> > results as "academic" or "theoretical."  Ed upped the ante.
> > Think it'll work??
> >
> > gem
> >
> > company www.cigital.com
> > podcast www.cigital.com/silverbullet
> > book www.swsec.com
> >
> >
> > --------------------------------------------------------------
> > --------------
> > This electronic message transmission contains information
> > that may be confidential or privileged.  The information
> > contained herein is intended solely for the recipient and use
> > by any other party is not authorized.  If you are not the
> > intended recipient (or otherwise authorized to receive this
> > message by the intended recipient), any disclosure, copying,
> > distribution or use of the contents of the information is
> > prohibited.  If you have received this electronic message
> > transmission in error, please contact the sender by reply
> > email and delete all copies of this message.  Cigital, Inc.
> > accepts no responsibility for any loss or damage resulting
> > directly or indirectly from the use of this email or its contents.
> > Thank You.
> > --------------------------------------------------------------
> > --------------
> >
> > _______________________________________________
> > Secure Coding mailing list (SC-L)
> > SC-L at securecoding.org
> > List information, subscriptions, etc -
> > http://krvw.com/mailman/listinfo/sc-l
> > List charter available at -
> > http://www.securecoding.org/list/charter.php
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php