Sunday, July 13, 2003

Inside a US Election Vote Counting Program


Inside a US Election Vote Counting Program

As a software developer with a keen interest in such constitutionally-guaranteed rights as the right to vote in this country, this is exactly the kind of information I've wanted to get my hands on for*ever*.

But, I'm having difficulty reading the article because I keep falling down in an epileptic fit and choking to death on my tongue every time I read the words "Microsoft Access".

*thud*choke*choke*die*

Oh, and while I'm dying, someone buy Bev Harris's book for me, wouldja? I'll thumb through it while waiting for my loved ones to gesture me into the light. No, really.

What it looks like, at a glance, is that GEMS security is based on two things: ignorance, and restricted access to the ballot server. Anyone, apparently, with sysadmin skills and access to the machine could do some damage. Most of the people involved in a balloting process, however, do not fit that bill. Still, any programmer will tell you relying on ignorance is not a very robust security scheme.

The first thing that caught my eye is that there was no mention of enforced password changes on the part of the application, meaning it is humanly possible that there are dozens of implementations of this software running that use the default password.

The second is the description of working around user passwords by using Access directly and copying their encrypted password into the GEMS login. Only someone who has access to Access (by having physical and username access to the machine in question, or the Access DB for GEMS being mounted on a network, among others) would be able to do this, because you need to be able to look at the underlying database to pull this off. Ideally, the number of people with that level of access would be very small. In practice, however, that number of people is always higher than you think it is.

The fact that the audit log is editable in any way really worries me. I design and build software systems, frequently web applications using SQL databases, which means I spend a lot of time using tools that include the ability to edit db info at exactly the kind of level this this data is being manipulated at. If I may go off on a tangent for the confused:

This kind of software is multi-layered, just like my funk, baby. The bottommost layer is the information repository, the "database". The next layer up is usually referred to as an API - an established set of functions provided to perform common tasks such as "add record to database", "delete record from database", that kind of thing, which the software developers writing this application use in order to avoid reinventing the wheel constantly and instead focus on the next level up, the User Interface. Where Stuff Actually Happens, from your perspective.

When you register at yahoo, you the user fill out a web form (UI) which, maybe, error-checks your input & comes up with a password (API) and then adds your info into a database (DB).

If you develop software, you may need to test or 'workaround' a known bug or any number of things that require you to edit data in the database by hand. So, varying somewhat from database to database, there are multiple tools to help you do that. In some ways, I think, Microsoft Access blurs the line between UI and DB by making it so easy for a user to touch data directly in the database. MS Access as I understand it targets the development of simple systems, where the user and the developer are frequently the same person, and not terribly technical. That makes it easy to mess up, by virtue of that apparent transparency. It can also make it easy to hack someone else's work. Anyone who wants to screw around with data on a system I develop had better have a password to the db, permission to access the db server from the machine they're on, and a healthy dose of experience programming relational databases and in the use of the relevant db's command-line interface.

So, most of these screenshots and whatnot, they are of the MS equivalent of 'low-level database access', not of the GEMS application itself. Someone who is using GEMS is probably having a very different experience.

Now, back to the audit log. From a design perspective it makes perfect sense to have event tracking or an audit log in the same database as the data itself. I do it that way all the time...when writing using an SQL database. But Access makes it so easy for non-admin personnel to edit info in a database -- makes it seem so much like part of the normal user experience -- that now that I've considered the situation, I would argue strongly against an audit log in the same database as the data. Since, for this app, complete records of the manipulations to the data are so vital.

I would argue for the application requiring a second (thus, obfuscated, yes, not the best approach) db for that info, or store audit information (user X logged on, user X modified record Y, user X ran report ABC....) in a completely different medium -- a flat file, XML streamed to another server, in such a way that no access to the log is permitted. Encrypt it.

"Access encourages those who create audit logs to use auto-numbering, so that every logged entry has an uneditable log number. Then, if one deletes audit entries, a gap in the numbering sequence will appear. However, we found that this feature was disabled, allowing us to write in our own log numbers. We were able to add and delete from the audit without leaving a trace."


This quote makes it sound like the audit trail isn't driven by the GEMS application but by Access itself, in which case, disabling the auto-number sequencing was A Bad Idea™ and was either the GEMS application's responsiblity, or, possibly, that of the installer.

On the whole, it's difficult to assess exactly how endangered specific balloting servers might be -- so much relies on the people restricting access to machines, making sure the ballot server is not on a network, making sure only authorized personnel can sit down in front of the machine, etc., that it's really hard to tell exactly how hackable a balloting process would be that is using this system. That, in itself, is Very Bad News.


Bigger Than Watergate! - How To Rig An Election In The United States
Inside a US Election Vote Counting Program
Bald-Faced Lies About Black Box Voting Machines
Black Box Voting Ballot Tampering in the 21st Century

No comments: