lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 28 Sep 2004 08:04:29 -0400 (EDT)
From: trh <s0le@...ll.5013.org>
Cc: bugtraq@...urityfocus.com
Subject: Re: Diebold Global Election Management System (GEMS) Backdoor Account
    Allows Authenticated Users to Modify Votes



Didn't diebold get owned?

Weren't a bunch of incriminating memo's published by a reporter?

Wait... Isn't the CEO a huge contributor to the Republican Party?

All I have to say is wake up.

Seriously.







On Mon, 27 Sep 2004, Bob Toxen wrote:

> Diebold having "swore up and down" that their closed-source system
> is secure and then it's been proven otherwise is exactly why we
> NEED an open source solution or go back to punched card/mechanical
> solutions.
>
> Open Source in this case does not need to be free source.  Diebold can
> get a software patent if they want while still keeping the source
> available by audit by everyone.
>
> In answer to the other poster's question as to why didn't Diebold
> use Schneier's public methods, I suggest that it was some combination
> of arrogance and stupidity.  I've discussed in the past ways to
> have cryptographically-signed records originated on each voting booth
> device and which travel all the way to the final tallying systems.
> The would would stop a LOT of potential tamper points.
>
> Best regards,
>
> Bob Toxen
> Author,
> "Real World Linux Security: Intrusion Detection, Prevention, and Recovery"
> 2nd Ed., Prentice Hall, (C) 2003, 848 pages, ISBN: 0130464562
> Also available in Japanese, Chinese, and Czech.
>
> On Thu, Sep 23, 2004 at 06:21:03AM -0400, Jeremy Epstein wrote:
>> As someone who's been involved in the electronic voting controversy, I'd
>> like to add a few points:
>>
>> (1) I agree that source code should be inspected by someone truly
>> independent and competent, and that the standards for approving voting
>> machines should be stronger.  However, that's NOT the same as open source.
>> And I'd strongly discourage folks from calling for open source, as it plays
>> directly into the hands of folks like Diebold, who claim that the people
>> (like me) who want Voter Verified Paper Audit Trails (VVPATs) are really
>> trying to kill free enterprise.  [Yes, I know all the examples of businesses
>> based on open source, but that's not what this is about.]  As an example,
>> Harris Miller, the president of ITAA (www.itaa.org), a politically
>> influential consortium of technology vendors, is on record as having equated
>> the VVPAT groups with the open source community.  So rather than putting
>> your energy into trying to get Diebold et al to move to open source, it
>> would be far more productive to put your energy into VVPATs.  Towards that
>> end, I'll encourage everyone participating in this discussion to look at
>> www.verifiedvoting.org.  VVPATs can give us the assurance we need of
>> accurate elections, without delving into the political morass of open source
>> and related topics.
>>
>> (2) WRT the web page showing a "Sun server when discussing Windows", I hope
>> people realize that web pages for companies are made up by marketing people
>> who don't understand the difference.  Don't hold that against them... There
>> are plenty of real reasons to oppose Diebold.
>>
>> (3) WRT requiring that the technology protect itself in case the users
>> don't, that's simply unrealistic.  In *any* real computer system, there are
>> expectations about the environment (e.g., the administrators aren't hostile
>> to the functioning of the system).  It's important to state what those
>> expectations are, but there will ALWAYS be some that rely on non-technical
>> means.  The important part about election systems is that they be explicitly
>> stated, and they be enforceable using non-technical means (e.g., by having
>> locks on doors).  The problem today is that some of the assumptions (e.g.,
>> the vendor provided software doesn't have any bugs) are clearly unrealistic.
>>
>> (4) WRT getting one set of software approved, and then installing another...
>> that's an old problem in any environment.  The way it's supposed to work in
>> election systems is that a particular version is approved, and it's illegal
>> for the vendor to install something different.  If there are teeth in the
>> law, and the vendor can be fined for installing illegal software, then it's
>> a reasonable non-technical measure.  Of course, one could also use things
>> like cryptographic checksums to verify that what's installed is what was
>> approved.  That still requires non-technical elements, such as that the
>> people who ran the checksums weren't deliberately trying to cover up a
>> change, the checksums were protected from tampering, the software that
>> calculated the checksums wasn't subverted, etc.  [For those of us old enough
>> to remember, vendors were required to address this as part of "Orange Book"
>> evaluations, and are now required to address it as part of Common Criteria
>> evaluations.]
>>
>> Bottom line, election systems are no different than any other systems in
>> that the security of the whole system is based on risk management.  While we
>> should have higher expectations of election software than office automation
>> software, let's recognize what it is.  IMHO, VVPATs are the only real way to
>> go.
>>
>> --Jeremy
>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ