Home page logo
/

risks logo RISKS Forum mailing list archives

Risks Digest 26.20
From: RISKS List Owner <risko () csl sri com>
Date: Wed, 10 Nov 2010 11:29:43 PST

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 () csl sri com>
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 () csl sri com>
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 () mindspring com>
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 () vortex com>
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 () sonic net>
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 () ocis net>
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 () kamens us>
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 () gmail com>
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 () roscom com>
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 () dotat at>
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 () pipeline com>
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 () gmail com>
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 () cs hmc edu>
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 () cs hmc edu   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 () coe int>
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 () nc rr com>
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 () ocis net>
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 () ocis net>
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 () att net (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 () lrw com>
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 () csl sri com
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 () csl sri com
 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 () csl sri com or risks-unsubscribe () csl sri com
 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 () newcastle ac uk>.
=> SPAM challenge-responses will not be honored.  Instead, use an alternative
 address from which you NEVER send mail!
=> SUBMISSIONS: to risks () CSL sri com 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
************************


  By Date           By Thread  

Current thread:
  • Risks Digest 26.20 RISKS List Owner (Nov 10)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault