RISKS-LIST: Risks-Forum Digest Weds 10 November 2010 Volume 26 : Issue 20 ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <http://www.risks.org> as <http://catless.ncl.ac.uk/Risks/26.20.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: Stephen Colbert's voting machine satire (PGN) J. Alex Halderman, Hacking DC, Freedom to Tinker (PGN) Trust the Vote -- not! (Rebecca T Mercuri) Voting machines selecting default candidates (Lauren Weinstein) Data mining Facebook reveals when you're most likely to be dumped (David McCandless via Mark Thorson) Getting Crypto Wrong (Neal Ungerleider via Gene Wirchenko) Something has been going right in the fight against spam, viruses, ... (Jonathan Kamens) Rise of VoIP systems open new market for exploitation (Dennis van Dok) Banks Rush to Fix Security Flaws in Wireless Apps (Spencer E. Ante via Monty Solomon) U.S. Daylight Saving Time ends with bug in iOS4 (Tony Finch) The most expensive SW bug in recorded human history (Henry Baker) Crowdsourcing videosurveillance (Jeremy Epstein) Student Password Extension (Geoff Kuenning) Risks of listening to cries for help (Nick Brown) Remote starter risk (e-p) Cellphone's Missing Dot Kills Two People, Puts Three More in Jail (Gene Wirchenko) Texting Stinks? (Gene Wirchenko) Re: Medical Errors (Una) Re: Risks of not following standards (Jerry Leichter) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 3 Nov 2010 12:17:22 PDT From: "Peter G. Neumann" <neumann_at_private> Subject: Stephen Colbert's voting machine satire PGN-ed excerpts from a wonderful parody toward the end of The Colbert [coal-bear] Report on Comedy Central on the evening of Election Day in the U.S.: Now, there have been reports of voting machine irregularities ... For instance in Jackson County, West Virginia, machines have actually changed votes, which would explain why `Candidate Page error 404' is now headed to the House of Representatives [with 93% of the vote]. Congratulations! Now, for more on this very disturbing story, let's go to where the polls are still open -- Kalua, Hawaii. ... [with Colbert inside the voting machine, behind the touchscreen, with the camera able to see the voter!] Colbert: Hello voter! Voter: Hey, Steven Colbert is in my voting machine! Colbert: Shhh. Have you seen anything suspicious? Colbert does a lovely Alex Halderman imitation, flipping the voter's straight-party selections to the other party. http://www.colbertnation.com/the-colbert-report-videos/364228/november-02-2010/indecision-2010---gop-takes-house ------------------------------ Date: Tue, 5 Oct 2010 18:47:05 PDT From: "Peter G. Neumann" <neumann_at_private> Subject: J. Alex Halderman, Hacking DC, Freedom to Tinker Freedom to Tinker ... is your freedom to understand, discuss, repair, and modify the technological devices you own. J. Alex Halderman, Hacking the D.C. Internet Voting Pilot, 5 Oct 2010 The District of Columbia is conducting a pilot project <http://www.dcboee.us/DVM/> to allow overseas and military voters to download and return absentee ballots over the Internet. Before opening the system to real voters, D.C. has been holding a test period in which they've invited the public to evaluate the system's security and usability. This is exactly the kind of open, public testing that many of us in the e-voting security community -- including me -- have been encouraging vendors and municipalities to conduct. So I was glad to participate, even though the test was launched with only three days; notice. I assembled a team from the University of Michigan, including my students, Eric Wustrow <http://ericw.us/trow> and Scott Wolchok <http://scott.wolchok.org>, and Dawn Isabel, a member of the University of Michigan technical staff. Within 36 hours of the system going live, our team had found and exploited a vulnerability that gave us almost total control of the server software, including the ability to change votes and reveal voters' secret ballots. In this post, I'll describe what we did, how we did it, and what it means for Internet voting. D.C.'s pilot system The D.C. system is built around an open source server-side application <http://github.com/trustthevote/DCdigitalVBM> developed in partnership with the TrustTheVote project <http://www.trustthevote.org>. Under the hood, it looks like a typical web application. It's written using the popular Ruby on Rails framework and runs on top of the Apache web server and MySQL database. Absentee overseas voters receive a physical letter in the mail instructing them to visit a D.C. web site, http://www.dcboee.us/DVM/, and log in with a unique 16-character PIN. The system gives voters two options: they can download a PDF ballot and return it by mail, or they can download a PDF ballot, fill it out electronically, and then upload the completed ballot as a PDF file to the server. The server encrypts uploaded ballots and saves them in encrypted form, and, after the election, officials transfer them to a non-networked PC, where they decrypt and print them. The printed ballots are counted using the same procedures used for mail-in paper ballots. A small vulnerability, big consequences We found a vulnerability in the way the system processes uploaded ballots. We confirmed the problem using our own test installation of the web application, and found that we could gain the same access privileges as the server application program itself, including read and write access to the encrypted ballots and database. The problem, which geeks classify as a shell-injection vulnerability, has to do with the ballot upload procedure <http://github.com/trustthevote/DCdigitalVBM/blob/6020c7158f679e29b0b263d93c4529244498d5d3/lib/paperclip_processors/encrypt.rb#L42>. When a voter follows the instructions and uploads a completed ballot as a PDF file, the server saves it as a temporary file and encrypts it using a command-line tool called GnuPG <http://www.gnupg.org/>. Internally, the server executes the command gpg with the name of this temporary file as a parameter: |gpg [] /tmp/stream,28957,0.pdf|. We realized that although the server replaces the filename with an automatically generated name (stream,28957,0) in this example), it keeps whatever file /extension/ the voter provided. Instead of a file ending in .pdf, we could upload a file with a name that ended in almost any string we wanted, and this string would become part of the command the server executed. By formatting the string in a particular way, we could cause the server to execute commands on our behalf. For example, the filename ballot.$(sleep 10)pdf would cause the server to pause for ten seconds (executing the sleep 10 command) before responding. In effect, this vulnerability allowed us to remotely log in to the server as a privileged user. Our demonstration attacks D.C. launched the public testbed server on Tuesday, September 28. On Wednesday afternoon, we began to exploit the problem we found to demonstrate a number of attacks: * We collected crucial secret data stored on the server, including the database username and password as well as the public key used to encrypt the ballots. * We modified all the ballots that had already been cast to contain write-in votes for candidates we selected <http://www.cse.umich.edu/~jhalderm/pub/dc/evil_ballot.pdf>. (Although the system encrypts voted ballots, we simply discarded the encrypted files and replaced them with different ones that we encrypted using the same key.) We also rigged the system to replace future votes in the same way. * We installed a back door that let us view any ballots that voters cast after our attack. This modification recorded the votes, in unencrypted form, together with the names of the voters who cast them, violating ballot secrecy. * To show that we had control of the server, we left a calling card -- on the system's confirmation screen, which voters see after voting. After 15 seconds, the page plays the University of Michigan fight song. Here's a demonstration <http://www.cse.umich.edu/~jhalderm/pub/dc/thanks/>. Stealthiness wasn't our main objective, and our demonstration had a much greater footprint inside the system than a real attack would need. Nevertheless, we did not immediately announce what we had done, because we wanted to give the administrators an opportunity to exercise their intrusion detection and recovery processes -- an essential part of any online voting system. Our attack remained active for two business days, until Friday afternoon, when D.C. officials took down the testbed server after several testers pointed out the fight song. Based on this experience and other results from the public tests, the D.C. Board of Elections and Ethics has announced that they will not proceed with a live deployment of electronic ballot return at this time, though they plan to continue to develop the system. Voters will still be able to download and print ballots to return by mail, which seems a lot less risky. D.C. officials brought the testbed server back up today (Tuesday) with the electronic ballot return mechanism disabled. The public test period will continue until Friday, October 8. What this means for Internet voting The specific vulnerability that we exploited is simple to fix, but it will be vastly more difficult to make the system secure. We've found a number of other problems in the system, and everything we've seen suggests that the design is /brittle/: one small mistake can completely compromise its security. I described above how a small error in file-extension handling left the system open to exploitation. If this particular problem had not existed, I'm confident that we would have found another way to attack the system. None of this will come as a surprise to Internet security experts, who are familiar with the many kinds of attacks that major web sites suffer from on a daily basis. It may someday be possible to build a secure method for submitting ballots over the Internet, but in the meantime, such systems should be presumed to be vulnerable based on the limitations of today's security technology. We plan to write more about the problems we found and their implications for Internet voting in a forthcoming paper. Professor J. Alex Halderman <http://alexhalderman.com/> is a computer scientist at the University of Michigan./ Freedom to Tinker is hosted by Princeton's Center for Information Technology Policy <http://citp.princeton.edu/>, a research center that studies digital technologies in public life. Here you'll find comment and analysis from the digital frontier, written by the Center's faculty, students, and friends. ------------------------------ Date: Mon, 08 Nov 2010 11:02:53 -0500 From: Rebecca T Mercuri <notable_at_private> Subject: Trust the Vote -- not! I was shocked to find on the DCBOEE's website (<http://www.dcboee.us/DVM/default.asp>) that they had decided to proceed with the use of the voting system they obtained from OSDV to collect Internet ballots in the 2 Nov 2010 general election, despite it having been proven to be highly flawed in terms of both security and integrity. I have become increasingly concerned that the recent wave of "voting hack exhibitions" are having the reverse effect. I'm not saying that these experiments shouldn't continue, but by somehow validating that the systems have been subjected to "testing" (even when this testing exposes massive vulnerabilities), the vendors and election officials seem to feel that it is appropriate to go ahead with deployment of these products. "At least we know [some of] the problems" is no way to run elections. A lengthy 22 Oct posting by Gregory Miller at the OSDV's TrustTheVote Project blog (at <http://www.trustthevote.org/d-c-reality-check---the-opportunities-and-challenges-of-transparency/comment-page-1#comment-9463>) underscores this "head in the sand" attitude by lauding the fact that "the District owns 100% of the source code, which is fully transparent and open source" as somehow a good thing. Actually this "ownership" means that the DC Election Officials had the freedom to deploy it, and they apparently did do so, despite knowing that it was vulnerable to international attack. Does the DCBOEE really think that their website admonishment about the paltry $10,000 fine and possible imprisonment is going to stop anyone, especially foreign hackers (who may not be subject to US laws), from using proxy servers to avoid detection? Does the OSDV truly believe that the DCBOEE has the ability to detect tampering if it occurs? And if they discover that the system was hacked during the actual election, do they have a plan to allow the affected voters to recast their ballots in a secure way? Heck, when consumer electronics or automobiles are discovered to have systemic problems, they are RECALLED! Shouldn't the OSDV folks be ashamed of themselves for not including a clause in their distribution that IMMEDIATELY RECALLS THIS PRODUCT and ENSURES IT WOULD NOT BE USED IN ANY ACTUAL GOVERNMENT ELECTION, if any vulnerabilities test or subsequent data exposes it as insecure and/or unreliable? Even more disconcerting is the cavalier attitude by the DCBOEE, in deciding to go ahead with this moronic experiment, knowing that the system was so massively flawed. This proves EXACTLY WHAT I (and others, especially PGN) HAVE ALWAYS SAID ABOUT OPEN SOURCE VOTING -- even if OSDV had been able to provide an update to remedy all of the KNOWN problems, there would be no time to adequately test it, and there would be no way for the voters to ensure that the CORRECTED version (and not a flawed or hacked one) is being used at the time of the election. Open source voting thus provides a false sense of security about electronic elections, which this sad experience has vividly demonstrated. As Ken Thompson said in 1984: "You can't trust code that you did not totally create yourself. No amount of source-level verification or scrutiny will protect you from using untrusted code." This is still true, whether the election community, seemingly well-intentioned developers, and security experts want to believe it or not. Transparency is NOT equivalent to Trust, especially in voting systems. Don't get me wrong, of course I believe that open source is a good thing for many types of applications -- voting (especially over the Internet or in fully electronic systems) just is NOT one of these. Sure, all aspects of voting systems must be open to thorough review. But the voting problem CANNOT BE SOLVED using open source. (If this sounds like a contradiction, it is, as I described in my doctoral dissertation, downloadable at <www.notablesoftware.com/evote.html>, because there is an inherent conflict in the ability to create a trusted system that also provides full anonymity.) Our election integrity colleagues must ensure that these points are made whenever they demonstrate vulnerabilities. Anyone who allows voters, election officials, and members of the press to think otherwise is contributing to this outright fraud. Perhaps if the VENDORS are fined $10,000 and threatened with jail sentences, this charade will finally end. ------------------------------ Date: Tue, 26 Oct 2010 09:30:09 -0700 From: Lauren Weinstein <lauren_at_private> Subject: Voting machines selecting default candidates Some voters in Las Vegas have noticed that Democratic Senator Harry Reid's name is checked by default on their electronic voting machines. By way of explanation, the Clark County Registrar says that when voters choose English instead of Spanish, Reid's Republican opponent, Sharron Angle, has her name checked by default. *Slashdot*, 26 Oct 2010 http://bit.ly/cBXWSj [Reid won re-election, perhaps because of the strong Latino vote. PGN] ------------------------------ Date: Wed, 3 Nov 2010 16:41:18 -0700 From: Mark Thorson <eee_at_private> Subject: Data mining Facebook reveals when you're most likely to be dumped [David McCandless plotted occurrences of "break up" and "broken up" from 10,000 facebook status updates. The highest peaks were around spring breaks (perhaps he counted items such as "I'm spending my break up in the mountains?" and "I'm all broken up over my bad grades.") and the first few weeks of December. Beware of Breaks-Bearing gifs. PGN] Very interesting that April Fool's day represents a [secondary] peak. I wonder how many of those were actual break-ups. [Source: http://www.dailymail.co.uk/sciencetech/article-1325915] ------------------------------ Date: Fri, 05 Nov 2010 17:47:43 -0700 From: Gene Wirchenko <genew_at_private> Subject: Getting Crypto Wrong Neal Ungerleider, How Haystack Risked Exposing Iranian Dissidents, FastCompany.com, 20 Sep 2010 http://www.fastcompany.com/1690075/haystack-austin-heap-iran-fail In 2009, Iran was in turmoil, and the Islamic Republic was blocking and monitoring sites used by opposition groups -- until a team led by American IT specialist Austin Heap built a program, Haystack, and touted it as a secure and anonymous Web portal for Iranians. *The Guardian* lauded it, and U.S. Secretary of State Hillary Clinton personally praised Heap. The U.S. government even gave him rare permission to export his cryptological software to Iran. Among an elite group of beta testers -- and many more unauthorized users -- Haystack was a godsend. Then in Sept. 2010, security experts discovered a problem: Iranian authorities, the very ones Haystack was supposed to circumvent and shield against, were exploiting massive holes in the encryption scheme to snoop on dissidents. [Beware of anonymity-bearing gifts. As we have noted here before, ALWAYS look a gift (trojan) horse in the mouth. PGN] ------------------------------ Date: Sat, 02 Oct 2010 23:15:07 -0400 From: Jonathan Kamens <jik_at_private> Subject: Something has been going right in the fight against spam, viruses, ... We see a lot of depressing news reported in RISKS, so I thought I'd share something a bit more upbeat. I monitor some basic statistics about the impact of spam on my personal email server. In particular, I capture the number of spam messages that bogofilter successfully blocks and allows through, and the number of bogus SMTP connections successfully blocked each day by way of the Spamhaus ZEN blocklist on my primary and secondary SMTP servers. For those who are curious, I post graphs of these statistics, updated on a daily basis, at <http://stuff.mit.edu/~jik/#spam>. In the last few months, I've noticed a dramatic decrease in the number of bogus SMTP connections. Today I finally took a few minutes to run the numbers. When looking at a 30-day running average, the number of bogus connections has dropped an astounding 51% since May 14, from 29,184 per day to 14,287! I've posted a graph showing the decline at <http://stuff.mit.edu/~jik/spam.html#20101002>. I surmise that some very significant zombie botnets must have been shut down in the past few months. To whoever is responsible for this: kudos and keep up the good work! There has also been a reduction in the spam that gets through the blocklist, from an average of 168 per day to 132, i.e., a 21% drop. That's significant, but not nearly as dramatic as the decrease in blocked SMTP connections. ------------------------------ Date: Mon, 11 Oct 2010 10:15:38 +0200 From: Dennis van Dok <dvandok_at_private> Subject: Rise of VoIP systems open new market for exploitation The trend in telecommunication to replace traditional phone switches with software-based VoIP systems means that there is a growing market for scanning the Internet for systems on port 5060, breaking in and re-selling phone services through them. An unsuspecting company that recently installed a new VoIP based switch, often with poor default security, suddenly receives a hefty phone bill for calls to (often expensive) numbers. The perpetrators make money by offering these services on the cheap, while their costs are virtually zero. See the ZDnet article for a rise in abuse in Australia: http://www.zdnet.com.au/thousands-lost-in-rising-voip-attacks-339306478.htm There are a number of things to ponder over here: * The vendors possibly ship these systems with a default password, or allow anonymous VoIP registration, so it works 'out of the box'. * The people who install these systems may be coming from a different branch than the system administrators who have had to deal with protecting their servers against the big bad Internet for years. ------------------------------ Date: Sun, 7 Nov 2010 10:43:15 -0500 From: Monty Solomon <monty_at_private> Subject: Banks Rush to Fix Security Flaws in Wireless Apps Spencer E. Ante, *Wall Street Journal*, 5 Nov 2010 A number of top financial companies and banks such as Wells Fargo & Co., Bank of America Corp. and USAA are rushing out updates to fix security flaws in wireless banking applications that could allow a computer criminal to obtain sensitive data like usernames, passwords and financial information. The central problem is that the apps, which run on Apple Inc.'s iPhone and Android-based devices from Google Inc., are storing a user's information in the memory of a cellphone, a basic lapse that the security researcher who found the flaws said could allow a cybercriminal to access a person's financial accounts. The data could be gleaned if a criminal got physical access to the phone. It could also be obtained remotely if an attacker were able to con a user into visiting a malicious website, according to Andrew Hoog, chief investigative officer of viaForensics, a Chicago computer and mobile security firm that discovered the flaws. ... http://online.wsj.com/article/SB10001424052748703805704575594581203248658.html ------------------------------ Date: Mon, 1 Nov 2010 10:59:52 +0000 From: Tony Finch <dot_at_private> Subject: U.S. Daylight Saving Time ends with bug in iOS4 The iPhone / iPod Touch OS has a "clock" application that can act as a stopwatch, countdown timer, multi-timezone world clock, and daily alarm. (This alarm is distinct from the appointment reminders you can set up with the calendar app.) I have an alarm set to go off at 07:00 on week days. On Sunday when the clocks went back, my iPhone's time display correctly followed the change, and the alarm continued to show the 07:00 setting. However this morning the alarm went off at 08:00. (This wasn't actually a problem since our four-year-old son woke us at about half past six...) ------------------------------ Date: Sun, 07 Nov 2010 06:45:38 -0800 From: Henry Baker <hbaker1_at_private> Subject: The most expensive SW bug in recorded human history NPR's Planet Money 5 Nov 2010 details a bug on the U.S. Freddie Mac website which refuses to accept an "appreciation rate" for housing which is a negative number. At some point in the last several years, hundreds of trillions of dollars (face value) in derivatives were outstanding based on this same bug, and Ben Bernanke has put the U.S. dollar printing presses into overdrive trying to get the nominal value of home prices up so that people will feel richer & start to spend again. Of course, Ben is p*ssing into the winds of a category V hurricane, but he deserves a Nobel for trying. http://www.npr.org/blogs/money/2010/11/05/131105373/the-friday-podcast-finally-an-apology#more ------------------------------ Date: Mon, 1 Nov 2010 11:25:35 -0400 From: Jeremy Epstein <jeremy.j.epstein_at_private> Subject: Crowdsourcing videosurveillance Interesting piece I heard about on NPR On The Media the other day (http://www.onthemedia.org/transcripts/2010/10/08/02). A British company is setting up closed circuit TVs in stores, and then inviting people to sign up to watch the cameras in real time (four cameras at a time). If you see something bad (i.e., someone shoplifting), you notify the shopowner via their site. There's obviously tremendous opportunity for people causing mischief (i.e., by tagging customers based on appearance), but they seem to have given consideration to privacy and reliability concerns. Several interesting things: - They have a rating system for watchers - if you cause too many false alarms, you're kicked out. - Watchers are unpaid (+), although they can get some rewards. They believe that because people want to reduce crime they'll volunteer their time. Voyeurism, anyone? - Watchers can't choose what cameras they see, and are assigned stores far from where they live (*). - Shopowners pay about 100 pounds/month for the service (don't know if that's for one camera or many). Lots of opportunities for mischief here (e.g., can the cameras be re-aimed, will shopowners point the cameras at dressing rooms). I can't imagine that it would be interesting for very long, but perhaps if you're really bored.... After all, this is what minimum wage rent-a-cops do in shopping malls. This is a great example of the risks of technology (Internet & cameras), combined with people's wanting to help their communities, tempered with a healthy dose of voyeurism. http://interneteyes.co.uk/ (+) In fact, they *pay* to register! "Payment of the membership fee helps prevent misuse of the system and acts as a barrier to entry to stop voyeurism." (*) Presuming the watcher gives an accurate home address, one presumes. ------------------------------ Date: Mon, 01 Nov 2010 18:36:56 +1300 From: Geoff Kuenning <geoff_at_private> Subject: Student Password Extension The following was just sent to all faculty and staff at the institution where I am teaching (some information removed to protect the guilty): > Student Password Extension > What will happen > All students who were created in [...] before 2006 had > a 6-digit password. For security reasons, we intend to extend all those > students' passwords to 8-digits. After this change is implemented, > those students with 6-digit passwords will have their passwords extended > by two letters -- qz. The number of affected students is estimated to be > 2130. (Bear in mind this is not the total number of changes, it is just > the number of students who enrolled this year who have a 6-digit > password.) > Notification > 1. Affected students will be emailed about this change; > 2. A notice will be put on the Student Campus life page; > 3. A notice will be put on the YYY home page; > 4. A notice will be put on the computer logon screens; Geoff Kuenning geoff@private http://www.cs.hmc.edu/~geoff/ The "M" in XML stands for *markup*. If you don't have anything outside the angle brackets, you probably shouldn't be using XML. ------------------------------ Date: Sat, 30 Oct 2010 21:49:05 +0200 From: "BROWN Nick" <Nick.BROWN_at_private> Subject: Risks of listening to cries for help The BBC web site reports (http://www.bbc.co.uk/news/technology-11654139) that a UK company has "produced software which it said can analyse the pitch, tone and intonation of noises [captured by public CCTV cameras] and work out if they pose a threat". A company spokesman commented: "A certain number of false positives are beneficial so long as you have the security bandwidth to cope with them because you'd rather know about things that you think were an incident than just miss things you failed to be alerted to." It's not made clear in the article whether the firm in question is familiar with Bayes' theorem, or has considered the risk of false positives in jurisdictions where an armed response is likely (or false negatives, in cases where people are being assaulted but calling for help in the wrong tone of voice). ------------------------------ Date: Sun, 7 Nov 2010 20:33:10 -0500 From: <e-p_at_private> Subject: Remote starter risk A woman died and and her husband was hospitalized after someone in the house accidentally pressed the "remote-start" button for her car in their garage in Raleigh VA. http://www.wral.com/news/news_briefs/story/8586538/ ------------------------------ Date: Wed, 03 Nov 2010 12:54:32 -0700 From: Gene Wirchenko <genew_at_private> Subject: Cellphone's Missing Dot Kills Two People, Puts Three More in Jail The life of 20-year-old Emine, and her 24-year-old husband Ramazan Calcoban [with a Turkish equivalent of a cedilla under each c] was pretty much the normal life of any couple in a separation process. After deciding to split up, the two kept having bitter arguments over the cellphone, sending text messages to each other until one day Ramazan wrote [or at least intended to write] "you change the topic every time you run out of arguments." The lack of a single dot over a letter [i] -- product of a faulty localization of the cellphone's typing system --caused a chain of events that ended in a violent blood bath. (Warning: offensive language ahead.) http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail The opening picture and caption is horridly insensitive as well. It is a fixed image. [The confusion resulted from the absence of a Turkish character (the "closed i"), which is missing in many Turkish cell phones. The exact misinterpretation was dramatic, and is noted in the cited article. It clearly resulted in serious offense being mistakenly taken by Emine's family, and it proved fatal. PGN] ------------------------------ Date: Fri, 15 Oct 2010 07:27:46 -0700 From: Gene Wirchenko <genew_at_private> Subject: Texting Stinks? We all know that walking and texting is a tough combination -- but a Staten Island teen learned the hard way when she fell into an uncovered sewer manhole while trying to send a message. Now, the family of Alexa Longueira, 15, intends to sue. The girl suffered a fright and some scrapes on her arms back after she dropped into the hole on Victory Boulevard. http://www.nbcnewyork.com/news/local-beat/Teen-Drops-Into-Sewer-While-Walking-Texting.html ------------------------------ Date: Thu, 28 Oct 2010 19:18:46 -0600 (MDT) From: una_at_private (Una) Subject: Re: Medical Errors (RISKS-26.19) Surgical "wrong site" errors are an old problem. Prior to knee surgery 20 years ago a nurse handed me a marker and asked me to draw an X on the spot. I drew a very large, bold serif X fit for a pirate treasure map. Just to be safe, I wrote "no!" all over the other knee. Most patients choose general anesthesia but I chose a spinal block. I will never forget how the surgical team all laughed when they saw my knees. And there is this: http://www.sciencedaily.com/releases/2008/10/081021185211.htm ------------------------------ Date: Sun, 3 Oct 2010 09:20:36 -0400 From: Jerry Leichter <leichter_at_private> Subject: Re: Risks of not following standards (RISKS-26.15) Gene Wirchenko forwarded an article from InfoWorld about the problems a Duke University experiment caused by sending BGP advertisements with a valid but unrecognized attribute, triggering a bug in Cisco router code that caused a "partial Internet blackout". I used to work at a company that did network monitoring software. We mainly used SNMP to query devices for their state. We'd regularly run into bugs in SNMP implementations. Some affect only us - e.g., returning ill-formed packets, or properly-formed packets with garbage data. But others did varying degrees of damage, from routers that implemented some queries so inefficiently that if you made them, the routers would become unusable due to the resource requirements of trying to answer you, all the way up to legitimate requests that would cause routers to reset or crash. In many cases, when we investigated we'd find that the bugs were known and had long been fixed by the vendors - but the customer was still running old, unpatched code. Some customers would patch; others viewed this as a "it's working, we're not touching it" situation. Division of responsibility between the group that was monitoring the network and the group that "owned" the devices also factored into this. The device "owners" blamed our software for crashing their devices! We ended up having to avoid some analyses because of the hazards of the queries they required. These routers were typically embedded in enterprise networks, not out on "the greater Internet" - but that's a fluid boundary, since some of them were internal to providers of Internet interconnect services. You as a user couldn't see those devices - but your data flowed through them nonetheless. There's been little published work on the vulnerabilities of Internet infrastructure protocols *as actually implemented on real devices*. I'm sure there are plenty of vulnerabilities to be found. BGP, the particular protocol in question here, is known to have instabilities, and has been implicated in various accidental (or perhaps not?) misconfigurations that have caused wide-spread, problems in recent years. The mentioned article ends with the scary quote: "The days of academics playing with a live network are kind of gone now...." This is a recipe for stagnation - and for hiding, not fixing, significant problems. ------------------------------ Date: Thu, 29 May 2008 07:53:46 -0900 From: RISKS-request_at_private Subject: Abridged info on RISKS (comp.risks) The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. The mailman Web interface can be used directly to subscribe and unsubscribe: http://lists.csl.sri.com/mailman/listinfo/risks Alternatively, to subscribe or unsubscribe via e-mail to mailman your FROM: address, send a message to risks-request_at_private containing only the one-word text subscribe or unsubscribe. You may also specify a different receiving address: subscribe address= ... . You may short-circuit that process by sending directly to either risks-subscribe_at_private or risks-unsubscribe_at_private depending on which action is to be taken. Subscription and unsubscription requests require that you reply to a confirmation message sent to the subscribing mail address. Instructions are included in the confirmation message. Each issue of RISKS that you receive contains information on how to post, unsubscribe, etc. => The complete INFO file (submissions, default disclaimers, archive sites, copyright policy, etc.) is online. <http://www.CSL.sri.com/risksinfo.html> The full info file may appear now and then in RISKS issues. *** Contributors are assumed to have read the full info file for guidelines. => .UK users should contact <Lindsay.Marshall_at_private>. => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => SUBMISSIONS: to risks_at_private with meaningful SUBJECT: line. *** NOTE: Including the string "notsp" at the beginning or end of the subject *** line will be very helpful in separating real contributions from spam. *** This attention-string may change, so watch this space now and then. => ARCHIVES: ftp://ftp.sri.com/risks for current volume or ftp://ftp.sri.com/VL/risks for previous VoLume <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue. Lindsay has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r <http://the.wiretapped.net/security/info/textfiles/risks-digest/> . ==> PGN's comprehensive historical Illustrative Risks summary of one liners: <http://www.csl.sri.com/illustrative.html> for browsing, <http://www.csl.sri.com/illustrative.pdf> or .ps for printing ==> Special Offer to Join ACM for readers of the ACM RISKS Forum: <http://www.acm.org/joinacm1> ------------------------------ End of RISKS-FORUM Digest 26.20 ************************Received on Wed Nov 10 2010 - 11:29:43 PST
This archive was generated by hypermail 2.2.0 : Wed Nov 10 2010 - 13:38:15 PST