Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
A federal jury awarded Montgomery County, Penn., more than $1 million Wednesday in a suit against an Indiana company that sold the county 900 computer voting machines that repeatedly broke down. The jury found MicroVote Corp. breached its implied warranties, but rejected all of the county's other claims, including fraud and breach of contract. The county had sought $4.3 million against the company. [Source: *The Legal Intelligencer* <from http://www.law.com>]
It's election day, and as chair of the Iowa State Board of Examiners for Voting Machines and Electronic Voting Systems, it seems like a fair time to pause and think about the state of the art. Over the past several years, an important trend has been evident in the voting machines that have come before our board for approval in Iowa. This is the replacement of custom-built software with off-the shelf commodity software, usually some variant of Windows and largely dependent on Microsoft Office. Computers in voting machines are old technology at this point, whether they're used for central count systems based on punched cards or mark sense readers, or whether they're precinct count systems based on mark sense or direct recording electronic voting machines. There are still lever machines in use, of course, but those haven't been changed in years and therefore, we don't see them coming up for examination. Under the current Federal Election Commission guidelines for electronic voting systems, all custom-built software is subject to examination by an independent third party. On the other hand, "industry standard components" are acceptable, as is. The FEC has no enforcement power, but the FEC guidelines have been enacted into the voting law of numerous states. The reason this concerns me is that we see a larger and larger fraction of the software inside the voting system becoming proprietary product of a third party and exempt from the requirement that it be available for a source code inspection. Furthermore, the size of commercial operating systems is immense, so an effective inspection is very hard to imagine! What threat does this present? If I wanted to fix an election, not this year, but 4 years from now, what I might do is quit my job at the University of Iowa and go to work for Microsoft, seeking to insinuate myself into the group that maintains the central elements of the window manager. It sounds like it might be fun, even if the job I'd need would largely involve maintenance of code that's been stable for years. My goal: I want to modify the code that instantiates a "radio button widget" in a window on the screen. The specific function I want to add is: If the date is the first tuesday after the first monday in a year divisible by 4, and if the window contains text containing the string "straight party", and if the radio buttons contain, at least, the strings "democrat" and "republican", one time in 10, at random, switch the button label containing the substring "democrat" with any of the other labels, at random. Of course, I would make every effort to obfuscate my code. Obfuscated coding is a highly developed art! Having done so, what I'd have accomplished is a version of windows that would swing 10 percent of the straight party votes from the Democratic party to the other other parties, selected at random. This would be very hard to detect in the election results, it would be unlikely to be detected during testing, and yet, it could swing many elections! This is just one example attack! There may be similar vulnerabilities, for example, in the off-the-shelf database packages being used for ballot storage and counting. I don't mean to this example to reflect any ill feelings toward Microsoft, but it is true that their software is used in the vast majority of new voting systems I've seen. This threat does not require any cooperation from the vendor of the window manager or other third party component exempt from source code inspection. All it requires is a mole, working their way into the vendor and producing code which is not detected by the company's internal testing and inspection. Obfuscation is easy, and the art of the "easter egg" in commercial software makes it very clear that huge numbers of unofficial features are being routinely included in commercially released software without the cooperation of the software vendors. (OK, I know that some easter eggs are officially approved.) Having said this, it is worth noting that Microsoft has indicated a preference about the outcome of today's presidential election, and there are excellent reasons to treat proprietary software produced by a partisan agency with great suspicion when it is included in a voting system! My conclusion? The time has come for computer professionals to press for a change to the guidelines for voting machines, asking that all software included in such machines be either open source, available for public inspection, or at least open to inspection by a third party independent testing authority. There are no technical obstacles to this! Linux, Free BSD and several other fully functional operating systems are available and will run on the hardware currently being incorporated into modern voting machines! But, this is not the end of the problem! How do you prove, after the fact, that the software in the voting machine is the software that was approved by the board of examiners and tested by the independent testing authority? No modern machine I'm aware of makes any real effort to allow this proof, although several vendors do promise to put a copy of their source code in the hands of an excrow agency in case a question arises. Doug Jones <firstname.lastname@example.org> http://www.cs.uiowa.edu/~jones/voting/ [Note: Doug, Rebecca Mercuri <Mercuri@gradient.cis.upenn.edu> is just putting the finishing touches on her PhD thesis on the subject of electronic voting, at the University of Pennsylvania. I highly recommend you contact her for a copy, which should be available very soon. For everyone else, we will announce it here when the thesis is ready. Also, my book *Computer-Related Risks* has lots of background on risks in electronic elections and what to do about them. Rebecca has carried the analysis much further than I did. Her thesis will be a very valuable contribution that significantly raises the bar as to what should be demanded, not just hoped for, plus an analysis of the residual risks that would still remain. PGN]
I recently participated in an interesting workshop sponsored by the NSF by request of President Clinton on the feasibility of e-voting in public elections. The workshop web page is http://www.netvoting.org/ From the Web site: "On October 11 & 12, 2000, the Internet Policy Institute (IPI) will conduct a workshop to examine the issues associated with conducting public elections via computer networks. Sponsored by the National Science Foundation (NSF) and chaired by C.D. Mote, Jr., president of the University of Maryland, this workshop is part of a request by the White House to study the feasibility of Internet voting." It was a collection of technical experts, Social Scientists, election officials, the Department of Justice, and the NSF. The workshop was fascinating. The technical participants were: Erich Bloch, Washington Advisory Group Lorrie Cranor, AT&T Labs - Research Michael Fischer, Yale University Dan Geer, @Stake, Inc. Lance Hoffman, George Washington University David Jefferson, Compaq Systems Research Center Carl Landwehr, Mitretek Systems, Inc. Raymond Miller, University of Maryland Adam C. Powell, III, The Freedom Forum Ron Rivest, Massachusetts Institute of Technology Avi Rubin, AT&T Labs - Research Barbara Simons, Association for Computing Machinery I spoke about security challenges/risks associated with remote electronic voting related to host security and Internet availability. I was asked to write up my comments. The paper is available at http://avirubin.com/e-voting.security.html Avi Rubin http://avirubin.com/ [Added at PGN's request] The workshop (http://www.netvoting.org/) held in October in DC was sponsored by the NSF by directive from President Clinton to study the feasibility of electronic voting in public elections. Subject matter experts were invited from the social science community, the technical and security community, election officials, and representatives from the department of justice. The meeting was chaired by Dan Mote, the president of the University of Maryland. Panels were held discussing issues such what e-voting means, whether or not e-voting would improve accessibility, whether it would widen the digital devide, and whether more people would vote. On the technical side, there were panels about the security requirements, the current state of security on desktops as related to voting. The mandate was to cover the following issues: * How to ensure the security and reliability of the voting process; * How to protect the privacy of voters; * How to authenticate voter identity; * How to achieve broad and equitable access to online voting systems; * How to assess the impact of online voting on representative democracy and community; and * How to ensure that online voting systems are convenient, flexible, and cost-effective. The group is going to produce a report that will be submitted to the White House and to Congress and to election officials all over the country. My participation was as a panelist on security. I wrote up my comments. They are available at http://avirubin.com/e-voting.security.html Avi
I have a 1-year-old Saturn. As a safety feature, my Saturn will prevent me from going faster than is safe with my suspension or tires. When I first got the car, I had to try this feature out, so I found a long straight road and floored it. When I got to 105MPH the engine lost power and I slowed down. Experimentation revealed that I couldn't regain power until I dropped below 100, then I could accelerate again. A couple of days ago I drove through a fairly steep chasm with a road straight down one side and up the other. I figured I needed as much momentum as possible, so I pushed the clutch in and coasted down. Somewhere along the way I hit 105MPH. Just as I was starting up the opposite side I noticed that virtually all of my warning lights were on, and the engine was at 0RPM. A still engine means no power steering and no power brakes. I'm quite glad there weren't any turns or traffic that might have forced me to turn or brake. The problem was the assumption that I got to an excessive speed by using the engine to accelerate. The default action works great when the clutch is engaged. In my case, I ended up with a car that suddenly became very hard to control when I was already doing something unsafe.
On Yahoo news today, they carried this message from the Reuters feed "Smart Tires to Warn Drivers Via Mobile Messages". http://dailynews.yahoo.com/h/nm/20001023/tc/tires_phones_dc_1.html It details impending tire developments from Finland to put Bluetooth enabled chips in their product. The tire will phone the driver if the pressure drops too low. Future developments include detection of wear, as well as hydro-planing (tire losing contact with the road due to water). Standard security type risks, which phone gets the message? Even better, timing and distraction risks. Like the fighter pilot with so much information that they cannot cope, the modern driver may soon have a phone ringing that they are losing control of the car. "Really officer, it was an important call from my car that I had to answer. And see, I did hit the tree it told me I was going to." Reading my analog speedometer. sdg
*Aviation Week & Space Technology*, 6 Nov 2000, p. 24 "NASA's X-38 Vehicle 131R did a slow, 360-deg. roll after release from its B-52 carrier aircraft on Nov. 2. It was the first free flight of the vehicle, which automatically stabilized under the preprogrammed deployment of a drogue chute and made a successful landing under parafoil on a dry lakebed runway, as scheduled, at Edwards AFB, Calif. The vehicle sustained no damage in the test. Project officials said they would have to do some trouble-shooting to figure out why the Crew Return Vehicle (CRV) prototype rolled at an estimated average rate of about 20 deg. per sec. during its 24 sec. of scheduled free flight. A software problem in the vehicle's flight control system was suspected, although project officials were also looking at whether aerodynamic disturbances immediately after separation might have played a role. Actual separation from the B-52 was clean, and the flight control system maintained angle of attack throughout the 18-sec. roll. The vehicle is an 80%-scale version of the CRV designed to provide emergency escape for International Space Station crews." There's an F-16 test pilot somewhere thinking, "Been there, done that." James Paul Annandale Virginia <email@example.com>
Dozens of travelers were stuck on an underground passenger train at Denver International Airport on 19 Oct 2000 after a computer problem sent the train shooting past the main terminal. It took workers about 20 minutes to move the train to a station, where passengers got off. No one was injured. A circuit board on the automated train lost its memory and failed to read a bar code that signals it to stop. The train overshot the station and safety mechanisms kicked in. [Source: AP item, 20 Oct 2000, PGN-ed] [ERRONeous URL removed by request, 7 Sep 2011. PGN] The RISKS archives are of full of engineering designs without fail-safe features. One would think that the train would have a hardware interlock to stop the it if something disturbed the computer. Fail-safe also suggests that sensor events are required to enable and maintain motion rather than stop it. The lack of sensor input or keep-alive should result in a graceful shutdown. I'd guess that this train requires a computer to unlock the doors, rather than a fail-safe design that would require the computer to keep them locked.
National Instruments (http://www.ni.com) sells a device for gatewaying between ethernet (TCP/IP) and the IEEE-488 (GPIB) bus commonly used for controlling laboratory instruments, such as oscilloscopes, voltmeters, motion-controllers, etc. I was somewhat astounded, upon purchase of this device, to find that it had no security whatsoever. That is, if you properly configure it and attach it to your instruments, anyone in the world with the proper software can control your lab equipment. Worse, there is no mention in any of the documentation or marketing materials that security is an issue. The manual even suggests "If you are directly linked to the Internet... you can contact the... support department to update your firmware." without any consideration of the risks of the device being connected. Marketing materials also promote Internet-connected use without discussion of the risks involved. Securing this device requires putting it on its own ungatewayed ethernet segment. This is not mentioned in the manual, and reduces the utility of the device (cannot share existing wiring). The RISKS: - End users could unknowingly assemble systems that are open to attack or accidental disruption by intruders. Most laboratory scientists are not particularly well-versed in the minutiae of network security. As GPIB is commonly used for mechanical control, there is the real danger of physical damage. - Security issues are still sufficiently esoteric that a respected and generally competent company such as National Instruments can develop (and market for several years) a device for the Internet that has no security whatsoever. I am hoping that National Instruments can develop a firmware update that adds at least a minimal passcode for access control. Steve Holland, Dept. of Theoretical and Applied Mechanics, Cornell University firstname.lastname@example.org
A Milton Keynes Council worker sent a reply to one or more people who were commenting on proposals for a travelers' halting site. The letter had an embarrassing addition to the intended text. In small letters at the bottom was the file name: "H:\Gypsy letter to whingers.doc". Of course this risk is equally the risk of not proof-reading a printed copy. Charles Bryant - email@example.com
I'm not sure why "no one was sure exactly what triggered the glitch". It's reasonably obvious what happened: a sensitive file was accidentally left in a directory the web server could get to, the local search engine dutifully indexed it, and from then on it was sitting there just waiting for someone's search to unearth it. Steve Summit <firstname.lastname@example.org>
Please report problems with the web pages to the maintainer