The three winners of this year's EFF Pioneer Award (announced at Computers, Freedom, and Privacy 2004 on 22 Apr 2004) are Kim Alexander, David Dill, and Avi Rubin. The three were honored for their "pioneering work spearheading and nurturing a popular movement for integrity and transparency in modern elections." Relating to the question of whether the vendors' claims that pre-testing and post-testing demonstrate that nothing can go wrong during an election, Kim Alexander's acceptance speech cited this quote: 'An extra bias routine could be added to the vote-counting program that would have certain characteristics to make it undetectable by the official "logic and accuracy" test. This routine could be arranged so as not to go into effect until a larger number of ballots had been counted than were in the logic and accuracy test sample, or could be prevented from being operative during the test and be activated by a computer operator only for the official count.' Her speech continued as follows: "It sounds like something Dave Dill, or Avi Rubin or David Jefferson, or Rebecca Mercuri or any number of computer scientists might have said in the past year or two. But it dates back to 1970, when computer experts, working with civil rights leader Dr. James Farmer, first sounded the alarm over computerized vote counting risks. "When I first read this passage in a 1975 study by Roy Saltman, I had a sinking feeling. People have been warning of the potential to accidentally or deliberately alter election results through computer software for decades, ever since we started using software to count punch card ballots in the 1960's. "This is not a new problem. It's an old problem that never got solved. But I'm optimistic we will solve it. And the reason is because we have the tools to do so. We have the Internet. We have the ability to share information, to connect with each other, and to make a public problem so apparent that it can no longer be ignored. "The history of this country has been one long struggle for freedom. It continues today through the efforts being made by thousands of people across this country who are working to ensure we have voting systems which produce results which can be verified."
Melrose Park, IL, was recently (today) the scene of a collision between two fire trucks heading to the same fire. There may be an inherent risk just in emergency vehicles not following the standard rules of the road in which one vehicle should have yielded, or possibly going too fast to an intersection despite being an emergency vehicle and having the right of way over normal traffic. But more interesting is that the intersection has the Opticon (assuming I heard that right on the news) system, which changes the light to green for emergency vehicles, and no one is (yet) sure what happened as the two vehicles approached the intersection from perpendicular directions -- might it have changed to green both ways? We'll hopefully know soon, but I hope not -- shouldn't there be a failsafe that wouldn't allow two greens no matter what? Russ Perry Jr 2175 S Tonne Dr #114 Arlington Hts IL 60005 1-847-952-9729 email@example.com
193 Brits have been wrongly labelled as criminals because of mistakes in records between Jan 2003 and Feb 2004. By incorrectly linking these people to various crimes recorded on the police national computer (PNC), the Criminal Records Bureau (CRB) may have inadvertently blighted the employment prospects of scores of innocent individuals. (The CRB vets the records of people hoping to work with children or vulnerable members of society, and made over 2.5M queries during 2003.) Some of the mistakes are the result of clerical error while others are the result of offenders giving false details to police in an attempt to avoid getting a criminal record. [Source: John Leyden, *The Register*, 16 Apr 2004; PGN-ed] http://www.theregister.co.uk/2004/04/16/criminal_records_snafu/
The UK business sector is suffering more hacking attacks, viruses and network breaches than ever before, with large companies typically being compromised every week, according to this year's official survey of British IT security. The DTI Information Security Breaches Survey 2004 (ISBS 2004), published in full on 27 Apr 2004, showed that two-thirds of firms fell victim to a network attacks in the last year. The average cost of a serious breach has actually fallen to 10,000 pounds ($17.900), compared to 30,000 pounds ($53,600) in 2002, but with the number of malicious incidents on the rise the overall cost of IT security breaches remains broadly static. The results from ISBS 2004 show that many major firms are losing millions through failed IT security. The average cost of a serious break to a large company is 120,000 pounds ($214,500), and these large firms are suffering around four breaches a month--compared to one a month for all businesses. According to e-commerce minister Stephen Timms, "We can't yet say on the base of this survey that risks are being well-managed by UK companies." [Source: Graeme Wearden: UK firms face weekly attacks, ZDNet (UK), 27 Apr 2004] http://zdnet.com.com/2100-1105-5200649.html
I found a misspelled word on a web page so sent e-mail to the author. I got back a message with an https address for me to confirm my mail, Being Dan 'Batch Jobs' Jacobson, I rigged up a batch job to fetch that page, as I am not going to be hurried into clicking on things during my brief modem sessions. But no, there lay a further quiz with Enter the text you see below into the box to its right. This step is for added security. Visually impaired? Click here My batch job did not retrieve their image... and alas too late, dwindling resources upstairs say I'm no match for this. In other news, Mom will be proud of me as I receive lots of "VIP conference invitation" spam whereas others certainly just get regular spam.
The Australia and New Zealand Banking Group has reinforced its commitment to fighting online fraud and beefed up its scrutiny of large and high-risk technology projects. The "growing trend in electronic fraud" has forced it to focus very heavily on fraud prevention and detection, in response to incidents such as hoax e-mails, false Web sites and computer viruses. [Source: Iain Ferguson and Kristyn Maslog-Levis, ZDNet Australia, 27 Apr 2004; PGN-ed] http://zdnet.com.com/2100-1105-5201041.html
I recently was e-mailed an obvious (to me) phishing attempt, which is nothing new in itself but what raised my eyebrows was the way the URL was hidden. Not by exploiting browser display bugs, not by clever use of username syntax or any of the unusual URL formats, but by hiding all the information in plain sight. To anyone using a sans-serif font, that URL might look completely genuine -- even if that person carefully reads the source code of the incoming html e-mail. In fact, throughout the whole message each lower case "l" was replaced with capital "I" (so even if the mailer draws those characters in a slightly different way, there is no discrepancy in the way they are written in the URL, so the visual cue is lost). Risk? Throwing information away by mapping different characters onto excessively similar glyphs (though used to great effect in endless obfuscated contest entries, no doubt). Andrew Collier http://www.intensity.org.uk [It was a real glyph-hanger! PGN]
I'm British and fill in a UK tax form. My wife is American and fills in both UK and US tax forms. A British tax for is typically 20-odd pages, large type, lots of whitespace, with an instruction booklet that is pretty simple to comprehend. My wifes "simple" US tax form and instructions looks like a badly written, small font, thin paper telephone directory for a small city. Having seen the two, I can't imagine how anyone can describe the UK form as difficult. Now the standard of the UK Inland Revenue's website and support? That really is another matter! Last year it was impossible to determine whose electronic software had been validated for use, unless you first registered with the website. Problem was I wanted to at least investigate the options before deciding whether to bother with electronic filing. BTW, electronic filing will do the calculation for you. In the UK, the Inland Revenue will do this for you anyway but I was interested to know and the "do it yourself calculation guide" is always cryptic.
Vivendi Universal Entertainment and Universal Music Group have developed a software solution to automatically disable net access for people accused of illegally sharing copyrighted material. According to the description found here: <http://news.com.com/2100-1027_3-5194341.html?tag=macintouch> the software, called ACNS (Automated Copyright Notice System) would be run by universities. When a notice of copyright infringement is received, the system automatically cuts off network access for the accused. The ACNS software is open source. The claims of infringement are submitted in a special XML-format, also open source. There is no apparent attempt to verify the accuracy of the claim. Which means that presumably anyone can be denied net access simply by accusing them of piracy. RISKS aplenty. Steve Klein, Phone (248) YOUR-MAC-EXPERT (or 248-968-7622)
*The Montreal Gazette* recently reported that a man was convicted in a recent traffic accident case based on data from an automotive "black box". "Eric Gauthier, 26, was sentenced yesterday [April 14, 2004] to 18 months...." "...police [used] information culled from the data recorder, better known as a black box, from Gauthier's car." "The recording device, which stores data on how a car is driven in the last five seconds before a collision, showed four seconds before impact, Gauthier had the gas pedal to the floor. He didn't brake before impact." References: http://www.canada.com/montreal/montrealgazette/news/story.html?id=6a58a759-3fb5-4862-bbc0-39238d048874
Stupidity/cluelessness = Risk? I sent off an e-mail message to an acquaintance, and got, as a response a message that said that the recipient was using spamBlocker and gave me a URL to go to. When I got there I saw a form with the following (in pretty HTML} (Asterisk strings mine) Please complete the short form below. If firstname.lastname@example.org chooses to allow e-mail from your address, the message(s) that have been intercepted will be delivered immediately, and any future message(s) will be delivered without delay. Your First Name: P&G M.I. Your Last Name: W******** Enter your additional e-mail addresses here: Address 1: w**@***********.com Add other addresses (if you have more than one). Please type a short message to email@example.com. (100 characters, max.) This step is for added security. Enter the text you see below into the box to its right. [the usual large, but distorted anti-OCR text] Visually impaired? Click here I duly filled out the form, clicked submit and was told that the name field had illegal characters - only alphas, - and _ were permitted. i.e. although the & was in the e-mail as part of my name, Earthlink would not send the request message to the recipient. There was no indication as to whether theis screening actually used the name in incoming e-mail messages to filter or not. (there's nothing in the standard that would limit & from the name). The insensitivity/cluelessness issue is that, although the distorted text is quite large, the "Visually impaired? Click here" option is in their normal, small text - only a bit of thinking would have made them realize that increasing the size of a message to a visually impaired person might help. The RISK - there may be no way for an unsophisticated Internet user (who has an "illegal" character in their name) to get a message to the spamBlocker subscriber to add their name to the pass list.
I've received a number of replies, and so thought it might be helpful to summarize. Peter Ladkin points out this problem is all too common. Ben Kamen points out that Sendmail can do reverse DNS (user configurable), but many domains have messed up DNS records that make this less useful. Przemek Klosowski says: "I believe Drew is misinterpreting the Received: header. I don't know if it is written up somewhere, but in practice, most Received: headers are of the form: Received: from <claimedDomain> (<lookedUpDomain> [<observedIP>]) ..." [<claimedDomain> comes from the remote MTA's SMTP HELO command.] Uh, no, I'm not. 16 years of SMTP mail has conditioned me fairly well. I'm complaining that the MTA in question (a commercial, "anti-virus" MTA), is doing nothing to note that the <claimedDomain> may have absolutely nothing to with the numeric IP address displayed next to it. In fact, this happens all of the time -- the same is true of legitimate mail that I receive. In Przemek's terminology, <lookedUpDomain> is always the empty string. It should do forward and/or reverse DNS lookup(s), and it would be really nice if it noted discrepancies when they occur. That this MTA is suboptimal in its use of DNS is a common RISK -- improper DNS use was one of the first bugs we (Dan Wallach, Ed Felten, and I) found in Sun's early JVM. Patrick LoPresti points out that the behavior I observed is all too common, and probably the reverse DNS lookup failed. It worked immediately the next morning (when I first read the mail), but I can't rule out a transient failure. The really clever spammer might even launch a DoS attack against the appropriate DNS servers to try to hide their tracks. Patrick also notes experience similar to Ben's (above), that things often aren't configured properly, and goes on that he found too many false positives when he tried to use this as a spam filter. Malcom Pack received 2 copies of the mail (from very different places), and starts along the same line as Przemek Klosowski. However, he goes on to give a concrete example where a mismatch is actually legitimate. I do, however, rather like how the MTA he uses handled the phishing mail: | Received: from barclays.co.uk (wbar1.nyc1-18.104.22.168.nyc1.elnk.dsl.genuity.net [22.214.171.124]) | by smtpserver.homeip.net with SMTP (Mailtraq/126.96.36.1998) id SMTPF3B8F140 | for firstname.lastname@example.org; Wed, 21 Apr 2004 08:58:38 +0100 Now that's what I'd like the Received: header to look like. (If you notice in the headers I provided earlier, a different SRI mail server, running a different MTA, does something similar.) And if the reverse DNS lookup fails, (as it apparently did for my mail server), I'm just asking for a warning (e.g., (reverse DNS failed [w.x.y.z]). Is that really too hard? Jonathan de Boyne Pollard also replied. His reply starts along the same lines as Malcom Pack's, and points out that at one point this was meant for loop detection, although that has many related problems. He goes on to say: But that's not the risk here at all. The risk here is erroneously assuming that the "HELO"/"EHLO" domain names recorded in "Received:" headers tell one _anything at all_, let alone that they tell one something about the legitimacy of messages. In other words: The risk is that of false conclusions being drawn from the mis-use of a protocol element for something other than its actual purpose. Of course, the way to check a mail message, purporting to come from Barclays Bank (or anyone else), for legitimacy is the same as it always has been (both for SMTP-based Internet electronic mail and for physical mail): check that the message is signed and that the signature is valid. These are certainly reasonable points. However, I still believe that the observed MTA behavior I originally reported is just about the worst possible thing to do. I'm not necessarily asking for information to judge the validity of the mail message (after all, someone could break into the target's mail server, or an insider could launch a phishing scam, etc.), but to give me all observable information about the mail servers a message traversed. There are simple improvements (already present in other MTAs) that would significantly mitigate the RISK I observed. Alas, S/MIME is still not widely deployed: I note that Jonathan's message wasn't signed. :-) And yes, I do have it (mostly) working on my end, although only in the last week or so. My thanks to all who took the time to respond.
*The Register* and the BBC recently covered a story about a boy who was trapped in an automated public bathroom. "A young boy [thought to be 10 or 12] had to be freed by the Fire Service after becoming trapped inside an automated public lavatory in Devon... in Plymouth's Central Park on Saturday [April 17, 2004]." They do not yet know why the boy was trapped, but apparently there is some sort of weight sensor to detect if someone is present or not. References: http://www.theregister.co.uk/2004/04/22/cyberloo_kidnaps_kiddie/ http://news.bbc.co.uk/1/hi/england/devon/3648633.stm
I was the project manager for high speed testing for one of the Big 3 car makers. I was driving home in a company car on an Interstate highway under cruise control when a similar thing happened. Fortunately, my driver training enabled me to make my way through traffic until I found a clear spot where I could safely turn towards the median and turn off the ignition. We towed the car back to the garage. Our garage manager told me that the small, plastic, speed-transducer gear in the transmission had disintegrated. The computer thought that the car was slowing down and moved the pedal to the metal. Now here's the risk: The computer didn't understand what the problem was. As the manager explained to me, stepping on the brake should have reset the computer speed control. But through a programming glitch, the computer did not obey the brake signal because it thought that I was already stopped. What was obviously needed was a hard electrical-reset, not a signal to reset if the program indicated that conditions are suitable. This was an early production of a new transmission model. When investigation showed several similar failures, the manufacturer went back to the powdered-metal drive gear. I don't know if the software was corrected. Thank goodness, for other drivers' sakes, that the police have learned the blocking technique to stop runaway vehicles. According to several news stories over the years since my misadventure, they have used it several times. It leads me to think that there are still glitches in drive-by-wire schemes. Bernard W. Joseph http://www.appliedgrammar.com
I read the original coverage of this, and I don't believe it. Reports at the time also claimed the car later attacked a mechanic and pinned him to the wall of the garage. Can anyone in RISKS-land come up with a malfunction that would simultaneously interfere with the car's ignition, transmission, and both braking systems, including the parking brake, WHICH IS MECHANICAL AND HAS NO LINKS TO ANY OTHER SYSTEM? I strongly suspect this of being a hoax/urban legend. Carl Fink, email@example.com, Manager, Dueling Modems Computer Forum http://dm.net
BKNTSCES.RVW 20031210 "Network Security Essentials", William Stallings, 2000, 0-13-016093-8, U$48.00/C$75.81 %A William Stallings firstname.lastname@example.org %C One Lake St., Upper Saddle River, NJ 07458 %D 2000 %G 0-13-016093-8 %I Prentice Hall %O U$48.00/C$75.81 201-236-7139 fax: 201-236-7131 %O http://www.amazon.com/exec/obidos/ASIN/0130160938/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0130160938/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0130160938/robsladesin03-20 %P 366 p. %T "Network Security Essentials: Applications and Standards" The existence of this book is a bit odd, particularly in view of the fact that it shares so much material with Stallings' "Cryptography and Network Security." The (clear and structured) preface, however, states that the intent is to provide a practical survey of network security applications and standards, particularly those in widespread use. As with the earlier work, this book is intended to serve both as a textbook for an academic course of study, and as a self-study and reference guide for practicing professionals. There is reduced detail in regard to cryptography. Chapter one is an introduction, and provides a good list of basic concepts and vocabulary. It may not be completely apparent to all readers that the emphasis is on threats to data transmissions and there is limited review of attacks on functioning systems. Part one deals with cryptography. Chapter two covers symmetric block ciphers in fundamental but sound terms, illustrated by an explanation of DES (Data Encryption Standard). The logic is heavily symbolic at times, but that should not be an impediment to the reader. It is interesting that chapter three views asymmetric cryptography as an extension of message authentication codes, but the explanations are articulate, including both algebraic and numeric examples, although the numeric illustrations could be fuller. Part two deals with network security applications. Chapter four looks at authentication applications, concentrating on Kerberos and X.509. The examples of e-mail security systems given in chapter five are PGP (Pretty Good Privacy) and S/MIME (Secure/Multipurpose Internet Mail Extension). Security provisions for the Internet Protocol (IP) itself are reviewed in chapter six. Web security, in chapter seven, discusses SET (Secure Electronic Transaction) and SSL (Secure Sockets Layer). Chapter eight reviews SNMP (Simple Network Management Protocol) both in terms of network management for security purposes, and in regard to cryptography for authentication of the application itself. Part four outlines general system security. Intruders and malicious software are lumped together in chapter nine, with a reasonable outline of the types of malware, but not dealing as well with viruses themselves. (Activity Monitors are referred to as "third generation" tools, when they actually predate both signature scanners ["first generation"] and heuristics ["second generation"].) Chapter ten finishes off the book with a description of firewalls, but has a rather odd inclusion of basic access control and trusted systems. Each chapter ends with a set of recommended readings and problems. Many chapters also have appendices giving additional details of specific topics related to the subject just discussed. A very reasonable guide, although possibly less practical than it intended to be. copyright Robert M. Slade, 2003 BKNTSCES.RVW 20031210 email@example.com firstname.lastname@example.org email@example.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer