Home page logo
/

risks logo RISKS Forum mailing list archives

Risks Digest 27.20
From: RISKS List Owner <risko () csl sri com>
Date: Mon, 18 Mar 2013 11:50:10 PDT

RISKS-LIST: Risks-Forum Digest  Monday 18 March 2013  Volume 27 : 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/27.20.html>
The current issue can be found at
  <http://www.csl.sri.com/users/risko/risks.txt>

  Contents:
Election screw-ups in Kenyan election (PGN)
Hacking the Papal Election (Bruce Schneier)
Replacing car keys with smartphone apps (Arthur T.)
Hyundai car controller failure? (PGN)
When being a "self starter" isn't a good thing (Jeremy Epstein)
Hiding Secret Messages in E-mail Jokes (Lauren Weinstein)
Fake silicone fingers strike again (Charles C. Mann)
The Internet is a surveillance state (Bruce Schneier)
More bad news for RC4 crypto (Lauren Weinstein)
"Researchers resurrect and improve CRIME attack against SSL" (Gene Wirchenko)
Warning About the Thrift Savings Plan iPhone App (Gabe Goldberg)
"Attorney General's testimony on Aaron Swartz raises more questions than
   answers" (Ted Samson via Gene Wirchenko)
Defense Companies Cash in on Gov't Hyped 'Cyber-Security' Threat
  (Lauren Weinstein)
Microsoft: Botched firmware update set off Outlook.com outage (Tim Greene
  via Jim Reisert)
Bloomberg: Hacker Attacks Top Latest U.S. List of Global Threats
  (Gabe Goldberg)
"Mobile to the rescue when an airplane trip goes awry" (Galen Gruman via
  Gene Wirchenko)
The end of Google Reader: Have I got news for you (G.F. via Dewayne Hendricks)
Google offers help to attacked /"hacked"/ sites (Lauren Weinstein)
Re: Boeing 787s to create half a terabyte of data per flight (Bob Frankston,
  Steve Loughran)
Re: How SSD power faults scramble your data (Dimitri Maziuk)
Harvard apologizes after secret e-mail search (Lauren Weinstein)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Tue, 12 Mar 2013 11:19:50 PDT
From: "Peter G. Neumann" <neumann () csl sri com>
Subject: Election screw-ups in Kenyan election

  [Gathered from a collection of sources.  PGN]

Electronic voting is failing the developing world while the US and
Europe abandon it.
<http://qz.com/61209/e-voting-is-failing-the-developing-world-while-the-us-and-europe-abandon-it/>

It was supposed to be the most modern election in Africa.  Kenyan
authorities, hoping to avoid the chaos of the 2007 election decided that
this time the country would use a tamper-proof, state-of-the-art electronic
voting system
<http://www.nytimes.com/2007/12/31/world/africa/31kenya.html?pagewanted=all>,
where voter IDs would be checked on hand-held devices and results
transmitted to Nairobi through text messages.
<http://www.standardmedia.co.ke/?articleID=2000077696&pageNo=1>

But everything that could go wrong did.
<http://latitude.blogs.nytimes.com/2013/03/07/in-kenyas-high-tech-election-almost-everything-that-could-have-gone-wrong-did/>
The biometric identification kits to scan people's thumbs broke down; a
server meant to take in results from 33,400 voting centers sent via SMS
became overloaded; and some election operators forgot the passwords and PIN
numbers for the software. Polling centers went back to hand counting ballots
and results were delayed almost a week, until March 9 when Uhuru Kenyatta's
win was announced. And every day before that people feared a repeat of 2007
when results were delayed and violence erupted, killing 1,200 people.
<http://qz.com/61192/the-real-victor-in-kenyan-elections-is-the-economy/>

... Vote information was being uploaded to a central server, which didn't
have enough disk space allocated (to the appropriate filesystem partition).
This meant that attempts to upload vote information failed, and many poll
sites were unable to upload vote data electronically.
http://iebctechkenya.tumblr.com/post/44928868808/a-clear-definition-of-the-iebc-tech-failure

  [This failure mode seems particularly outrageous if it was a lack of
  anticipating the number of voters, although perhaps the operational
  interface was misleading or defaulted improperly.  In any event, this
  should easily have been avoidable.  PGN]

See also
http://www.npr.org/blogs/alltechconsidered/2013/03/09/173905754/how-kenyas-high-tech-voting-nearly-lost-the-election

------------------------------

Date: Fri, 15 Mar 2013 01:45:15 -0500
From: Bruce Schneier <schneier () SCHNEIER COM>
Subject: Hacking the Papal Election

Bruce Schneier, Chief Security Technology Officer BT, CRYPTO-GRAM, 15 Mar 2013
schneier () schneier com  http://www.schneier.com

Hacking the Papal Election

As the College of Cardinals prepares to elect a new pope, security people
like me wonder about the process. How does it work, and just how hard would
it be to hack the vote?

The rules for papal elections are steeped in tradition. John Paul II last
codified them in 1996, and Benedict XVI left the rules largely
untouched. The "Universi Dominici Gregis on the Vacancy of the Apostolic See
and the Election of the Roman Pontiff" is surprisingly detailed.

Every cardinal younger than 80 is eligible to vote. We expect 117 to be
voting. The election takes place in the Sistine Chapel, directed by the
church chamberlain. The ballot is entirely paper-based, and all ballot
counting is done by hand. Votes are secret, but everything else is open.

First, there's the "pre-scrutiny" phase.

"At least two or three" paper ballots are given to each cardinal, presumably
so that a cardinal has extras in case he makes a mistake.  Then nine
election officials are randomly selected from the cardinals: three
"scrutineers" who count the votes; three "revisers" who verify the results
of the scrutineers; and three "infirmarii" who collect the votes from those
too sick to be in the chapel. Different sets of officials are chosen
randomly for each ballot.

Each cardinal, including the nine officials, writes his selection for pope
on a rectangular ballot paper "as far as possible in handwriting that cannot
be identified as his." He then folds the paper lengthwise and holds it aloft
for everyone to see.

When everyone has written his vote, the "scrutiny" phase of the election
begins. The cardinals proceed to the altar one by one. On the altar is a
large chalice with a paten -- the shallow metal plate used to hold communion
wafers during Mass -- resting on top of it. Each cardinal places his folded
ballot on the paten. Then he picks up the paten and slides his ballot into
the chalice.

If a cardinal cannot walk to the altar, one of the scrutineers -- in full
view of everyone -- does this for him.

If any cardinals are too sick to be in the chapel, the scrutineers give the
infirmarii a locked empty box with a slot, and the three infirmarii together
collect those votes. If a cardinal is too sick to write, he asks one of the
infirmarii to do it for him. The box is opened, and the ballots are placed
onto the paten and into the chalice, one at a time.

When all the ballots are in the chalice, the first scrutineer shakes it
several times to mix them. Then the third scrutineer transfers the ballots,
one by one, from one chalice to another, counting them in the process. If
the total number of ballots is not correct, the ballots are burned and
everyone votes again.

To count the votes, each ballot is opened, and the vote is read by each
scrutineer in turn, the third one aloud. Each scrutineer writes the vote on
a tally sheet. This is all done in full view of the cardinals.

The total number of votes cast for each person is written on a separate
sheet of paper. Ballots with more than one name (overvotes) are void, and I
assume the same is true for ballots with no name written on them
(undervotes). Illegible or ambiguous ballots are much more likely, and I
presume they are discarded as well.

Then there's the "post-scrutiny" phase. The scrutineers tally the votes and
determine whether there's a winner. We're not done yet, though.

The revisers verify the entire process: ballots, tallies, everything.  And
then the ballots are burned. That's where the smoke comes from: white if a
pope has been elected, black if not -- the black smoke is created by adding
water or a special chemical to the ballots.

Being elected pope requires a two-thirds plus one vote majority. This is
where Pope Benedict made a change. Traditionally a two-thirds majority had
been required for election. Pope John Paul II changed the rules so that
after roughly 12 days of fruitless votes, a simple majority was enough to
elect a pope. Benedict reversed this rule.

How hard would this be to hack?

First, the system is entirely manual, making it immune to the sorts of
technological attacks that make modern voting systems so risky.

Second, the small group of voters -- all of whom know each other -- makes it
impossible for an outsider to affect the voting in any way. The chapel is
cleared and locked before voting. No one is going to dress up as a cardinal
and sneak into the Sistine Chapel. In short, the voter verification process
is about as good as you're ever going to find.

A cardinal can't stuff ballots when he votes. The complicated
paten-and-chalice ritual ensures that each cardinal votes once -- his ballot
is visible -- and also keeps his hand out of the chalice holding the other
votes. Not that they haven't thought about this: The cardinals are in "choir
dress" during the voting, which has translucent lace sleeves under a short
red cape, making sleight-of-hand tricks much harder. Additionally, the total
would be wrong.

The rules anticipate this in another way: "If during the opening of the
ballots the scrutineers should discover two ballots folded in such a way
that they appear to have been completed by one elector, if these ballots
bear the same name, they are counted as one vote; if however they bear two
different names, neither vote will be valid; however, in neither of the two
cases is the voting session annulled." This surprises me, as if it seems
more likely to happen by accident and result in two cardinals' votes not
being counted.

Ballots from previous votes are burned, which makes it harder to use one to
stuff the ballot box. But there's one wrinkle: "If however a second vote is
to take place immediately, the ballots from the first vote will be burned
only at the end, together with those from the second vote." I assume that's
done so there's only one plume of smoke for the two elections, but it would
be more secure to burn each set of ballots before the next round of voting.

The scrutineers are in the best position to modify votes, but it's
difficult. The counting is conducted in public, and there are multiple
people checking every step. It'd be possible for the first scrutineer, if he
were good at sleight of hand, to swap one ballot paper for another before
recording it. Or for the third scrutineer to swap ballots during the
counting process. Making the ballots large would make these attacks
harder. So would controlling the blank ballots better, and only distributing
one to each cardinal per vote. Presumably cardinals change their mind more
often during the voting process, so distributing extra blank ballots makes
sense.

There's so much checking and rechecking that it's just not possible for a
scrutineer to misrecord the votes. And since they're chosen randomly for
each ballot, the probability of a cabal being selected is extremely
low. More interesting would be to try to attack the system of selecting
scrutineers, which isn't well-defined in the document. Influencing the
selection of scrutineers and revisers seems a necessary first step toward
influencing the election.

If there's a weak step, it's the counting of the ballots.

There's no real reason to do a precount, and it gives the scrutineer doing
the transfer a chance to swap legitimate ballots with others he previously
stuffed up his sleeve. Shaking the chalice to randomize the ballots is
smart, but putting the ballots in a wire cage and spinning it around would
be more secure -- albeit less reverent.

I would also add some kind of white-glove treatment to prevent a scrutineer
from hiding a pencil lead or pen tip under his fingernails.  Although the
requirement to write out the candidate's name in full provides some
resistance against this sort of attack.

Probably the biggest risk is complacency. What might seem beautiful in its
tradition and ritual during the first ballot could easily become cumbersome
and annoying after the twentieth ballot, and there will be a temptation to
cut corners to save time. If the Cardinals do that, the election process
becomes more vulnerable.

A 1996 change in the process lets the cardinals go back and forth from the
chapel to their dorm rooms, instead of being locked in the chapel the whole
time, as was done previously. This makes the process slightly less secure
but a lot more comfortable.

Of course, one of the infirmarii could do what he wanted when transcribing
the vote of an infirm cardinal. There's no way to prevent that. If the
infirm cardinal were concerned about that but not privacy, he could ask all
three infirmarii to witness the ballot.

There are also enormous social -- religious, actually -- disincentives to
hacking the vote. The election takes place in a chapel and at an altar. The
cardinals swear an oath as they are casting their ballot -- further
discouragement. The chalice and paten are the implements used to celebrate
the Eucharist, the holiest act of the Catholic Church. And the scrutineers
are explicitly exhorted not to form any sort of cabal or make any plans to
sway the election, under pain of excommunication.

The other major security risk in the process is eavesdropping from the
outside world. The election is supposed to be a completely closed process,
with nothing communicated to the world except a winner. In today's high-tech
world, this is very difficult. The rules explicitly state that the chapel is
to be checked for recording and transmission devices "with the help of
trustworthy individuals of proven technical ability." That was a lot easier
in 2005 than it will be in 2013.

What are the lessons here?

First, open systems conducted within a known group make voting fraud much
harder. Every step of the election process is observed by everyone, and
everyone knows everyone, which makes it harder for someone to get away with
anything.

Second, small and simple elections are easier to secure. This kind of
process works to elect a pope or a club president, but quickly becomes
unwieldy for a large-scale election. The only way manual systems could work
for a larger group would be through a pyramid-like mechanism, with small
groups reporting their manually obtained results up the chain to more
central tabulating authorities.

And third: When an election process is left to develop over the course of a
couple of thousand years, you end up with something surprisingly good.

This essay previously appeared on CNN.com, and is an update of an essay I
wrote for the previous papal election in 2005.
http://www.cnn.com/2013/02/20/opinion/schneier-papal-election-secure

My previous essay:
http://www.schneier.com/blog/archives/2005/04/hacking_the_pap_1.html

John Paul II's rules:
http://www.vatican.va/holy_father/john_paul_ii/apost_constitutions/documents/hf_jp-ii_apc_22021996_universi-dominici-gregis_en.html
or http://tinyurl.com/3ldzm

Benedict XVI's rules:
http://www.vatican.va/holy_father/benedict_xvi/motu_proprio/documents/hf_ben-xvi_motu-proprio_20070611_de-electione_fr.html
or http://tinyurl.com/cgza3qz

Rule changes:
http://www.washingtonpost.com/blogs/wonkblog/wp/2013/02/11/the-political-science-of-papal-elections/
or http://tinyurl.com/cp484a8
http://news.bbc.co.uk/2/hi/europe/6242466.stm

------------------------------

Date: Tue, 12 Mar 2013 17:59:30 -0500
From: "Arthur T." <risks201303.10.atsjbt () xoxy net>
Subject: Replacing car keys with smartphone apps

"Traditional car keys will likely become obsolete and be replaced by
technologies offering even greater security and convenience," John Nielsen,
AAA director of automotive engineering and repair told the *L.A. Times*.
"Motorists will need to adapt with the technology to avoid the hassle and
expense of smart key replacements."
http://consumerist.com/2013/03/12/would-you-be-okay-ditching-metal-keys-in-favor-of-a-smartphone-app-to-start-your-car/

Does he really believe that software gives greater security than hardware?
As for convenience, are you going to have to give your smartphone to the
parking lot valet? Or, will you instead give him a (probably permanent) app
to use your car?

------------------------------

Date: Fri, 15 Mar 2013 16:12:47 PDT
From: "Peter G. Neumann" <neumann () csl sri com>
Subject: Hyundai car controller failure?

  [Thanks to Kent Peterson.  PGN]

... allegedly causes high speed chase/crash:

http://www.autoblog.com/2013/02/22/hyundai-elantras-alleged-unintended-acceleration-sends-teen-po/#continued

------------------------------

Date: Wed, 13 Mar 2013 09:33:34 -0400S
From: Jeremy Epstein <jeremy.j.epstein () gmail com>
Subject: When being a "self starter" isn't a good thing

In management 101, I learned that being a "self starter" is a good thing.
But when it comes to cars, that's not so.

Subaru is recalling 50,000 cars there's a problem with the remote-control
self starter -- if you drop the keys in the wrong way, they can start the car
without the owner noticing.  Obviously if the car is inside a closed garage
and the owner doesn't notice it, that would be a Bad Thing.

Not really a software problem as far as I can tell from the brief
description.  And there's no indication that (by itself) this indicates the
ability for an attacker to remotely start a car.  It more points to the core
point of the RISKS forum: computerized technology can be a risk in its own
right, even when everything works as intended (i.e., only an authorized key
fob can be used to remotely start a car).

http://money.cnn.com/2013/03/07/news/companies/subaru-recall/index.html?hpt=hp_t2

------------------------------

Date: Tue, 12 Mar 2013 11:19:43 -0700
From: Lauren Weinstein <lauren () vortex com>
Subject: Hiding Secret Messages in E-mail Jokes

http://j.mp/YYafUr  (*Science Daily* via NNSquad)

  "Desoky suggests that instead of using a humdrum text document and
  modifying it in a codified way to embed a secret message, correspondents
  could use a joke to hide their true meaning. As such, he has developed an
  Automatic Joke Generation Based Steganography Methodology (Jokestega) that
  takes advantage of recent software that can automatically write pun-type
  jokes using large dictionary databases."

[Obviously true.  Why did the chicken traverse the road?  LW]

  [Because he wasn't *cross*?  Because he saw a steganosaurus?  Because he
  wanted to be victimized by a hidden-run driver?  Because he believed in
  o-pun-source soft-air?  This reminds me of a banquet talk I gave many
  years ago on parameterized polymorphic jokes suitable (or not suitable)
  for diverse occasions.  Unfortunately, the ultimate PUNchline was
  recursively parameterized and perhaps lost forever.  PGN]

------------------------------

Date: Wed, 13 Mar 2013 20:19:25 +0000 (UTC)
From: "Charles C. Mann" <ccmann () comcast net>
Subject: Fake silicone fingers strike again

I love the picture that illustrates this story:

http://motherboard.vice.com/blog/brazilian-doctor-arrested-for-using-silicone-fingers-to-hack-her-hospitals-security-system

Excerpt:

Here's hoping none of you, dear readers, has spent much money recently on
finger-scanning biometric security technology lately. Because it turns out
it's pretty easy to hack.

A news report from the BBC reveals that a 29-year-old Brazilian doctor,
Thaune Nunes Ferreira, working in a small town outside Sao Paulo was
arrested over the weekend for allegedly using prosthetic silicone fingers to
fake the presence of six of her colleagues.

That's right. If you can find a decent fingerprint and a way to manufacture
silicone objects (as some 3D printers can), you probably have what it takes
to break-into anything that requires a finger scan.

Charles C. Mann, P.O. Box 66, Amherst, MA, 01004-0066 www.charlesmann.org

  [Danny Burstein noted that an item on this in Al Jazeera quoted the doctor
  saying this was part of a scam to fool hospital bosses into thinking her
  colleagues had worked more overnight shifts than they actually had.  PGN]
    http://www.aljazeera.com/video/americas/2013/03/201331413348907219.html

------------------------------

Date: Sun, 17 Mar 2013 07:46:12 -0500
From: Bruce Schneier <schneier () schneier com>
Subject: The Internet is a surveillance state (CNN)

March 16 2013
http://www.cnn.com/2013/03/16/opinion/schneier-internet-surveillance/index.html

I'm going to start with three data points.

One: Some of the Chinese military hackers who were implicated in a broad set
of attacks against the U.S. government and corporations were identified
because they accessed Facebook from the same network infrastructure they
used to carry out their attacks.

Two: Hector Monsegur, one of the leaders of the LulzSac hacker movement, was
identified and arrested last year by the FBI. Although he practiced good
computer security and used an anonymous relay service to protect his
identity, he slipped up.

And three: Paula Broadwell,who had an affair with CIA director David
Petraeus, similarly took extensive precautions to hide her identity. She
never logged in to her anonymous e-mail service from her home network.
Instead, she used hotel and other public networks when she e-mailed him.
The FBI correlated hotel registration data from several different hotels --
and hers was the common name.

The Internet is a surveillance state. Whether we admit it to ourselves or
not, and whether we like it or not, we're being tracked all the time.
Google tracks us, both on its pages and on other pages it has access to.
Facebook does the same; it even tracks non-Facebook users. Apple tracks us
on our iPhones and iPads. One reporter used a tool called Collusion to track
who was tracking him; 105 companies tracked his Internet use during one
36-hour period.

Increasingly, what we do on the Internet is being combined with other data
about us. Unmasking Broadwell's identity involved correlating her Internet
activity with her hotel stays. Everything we do now involves computers, and
computers produce data as a natural by-product. Everything is now being
saved and correlated, and many big-data companies make money by building up
intimate profiles of our lives from a variety of sources.

Facebook, for example, correlates your online behavior with your purchasing
habits offline. And there's more. There's location data from your cell
phone, there's a record of your movements from closed-circuit TVs. ...

------------------------------

Date: Thu, 14 Mar 2013 12:52:45 -0700
From: Lauren Weinstein <lauren () vortex com>
Subject: More bad news for RC4 crypto

http://j.mp/XAqsm7  (Forbes via NNSquad)

  "A bunch of us have been sitting in the background scratching our heads,
  knowing that RC4 is weak in all kinds of ways," says Kenny Paterson, a
  professor at Royal Holloway, University of London who worked with
  Bernstein along with three other researchers to develop the new
  techniques. "But no one has been able to put it all together to break TLS
  in this kind of setting. Our work shows one way to do that."

Of course, if someone really wants your stuff that badly, they're probably
gonna try get you to download a keylogger.  But still, let's face it, RC4 is
way, way past its prime.

------------------------------

Date: Fri, 15 Mar 2013 10:30:01 -0700
From: Gene Wirchenko <genew () telus net>
Subject: "Researchers resurrect and improve CRIME attack against SSL"

http://www.infoworld.com/d/security/researchers-resurrect-and-improve-crime-attack-against-ssl-214532
InfoWorld Home / Security / News
March 14, 2013
Researchers resurrect and improve CRIME attack against SSL
New techniques bypass existing mitigations and allow attackers to
extract sensitive information from users' encrypted Web traffic
By Lucian Constantin | IDG News Service

------------------------------

Date: Tue, 12 Mar 2013 16:24:07 -0400
From: Gabe Goldberg <gabe () gabegold com>
Subject: Warning About the Thrift Savings Plan iPhone App

Date:         Tue, 12 Mar 2013 14:26:05 -0500
From:         USA.gov Team <subscriptions () subscriptions usa gov>
Subject:      Warning About the Thrift Savings Plan (TSP) iPhone App

  [I have removed some of the ugliest URLs I have ever seen from Gabe's
  posting. I think the stripped version conveys the message adequately.  PGN]

A free iPhone app called TSP Funds is currently being offered through the
Apple store. It asks Thrift Savings Plan (TSP) participants for their
account log in information.

This is not an official TSP app and the TSP does not recommend using this
app to access your TSP account. *Providing your information could result in
a security risk to your account.*

If you would like to access your TSP account, please log in directly at
TSP.gov [...]

------------------------------

Date: Tue, 12 Mar 2013 09:46:19 -0700
From: Gene Wirchenko <genew () telus net>
Subject: "Attorney General's testimony on Aaron Swartz raises more
  questions than answers" (Ted Samson)

Ted Samson, InfoWorld, 8 Mar 2013
U.S. Attorney General Eric Holder and Sen. John Cornyn butt heads
over whether prosecutors 'bullied' hacktivist (Reuters/Noah Berger)
http://www.infoworld.com/t/hacking/attorney-generals-testimony-aaron-swartz-raises-more-questions-answers-214141

selected text:

Cyber criminals seem to face disproportionately aggressive prosecution and
sentencing -- while major financial institutions that had a role in creating
the financial crisis remain, by the attorney general's own admission,
untouchable.

Holder's testimony prompted Cornyn to ask one of the key questions of the
entire case: "Does it strike you as odd that the government would indict
someone for crimes that would carry penalties of up to 35 years in prison
and million dollar fines and then offer him a three- or four-month prison
sentence?"

Why the ton of bricks?

------------------------------

Date: Fri, 15 Mar 2013 08:48:24 -0700
From: Lauren Weinstein <lauren () vortex com>
Subject: Defense Companies Cash in on Gov't Hyped 'Cyber-Security' Threat

  Bloomberg News reports that within the past two weeks security contractors
  Lockheed Martin and Raytheon have signed an agreement under the Department
  of Homeland Security's Enhanced Cybersecurity Services program providing
  new revenue streams and, more notably, unparalleled access to personal
  information classified as "U.S.  government data."  (Common Dreams via
  NNSquad)
    http://j.mp/XO75DX

------------------------------

Date: Thu, 14 Mar 2013 12:51:15 -0400
From: Jim Reisert AD1C <jjreisert () alum mit edu>
Subject: Microsoft: Botched firmware update set off Outlook.com outage
  (Tim Greene)

Tim Greene, Network World, 14 Mar 2013
Series of events forced a manual recovery, slowing the recovery, Microsoft says

The Outlook.com partial outage lasting 16 hours on Tuesday and Wednesday
morning was caused by a firmware update gone awry that triggered a
temperature spike in a Microsoft data center, resulting in automatic
safeguards that made a large number of servers inaccessible.

Because of the unspecified safeguards, downed servers couldn't fail over on
their own so restoration work had to be done manually, slowing down the
process, according to a blog post by Microsoft Outlook.com Vice President
Arthur de Haan.

http://www.networkworld.com/news/2013/031413-microsoft-outlook-outage-267705.html

------------------------------

Date: Tue, 12 Mar 2013 10:48:49 -0400
From: Gabe Goldberg <gabe () gabegold com>
Subject: Bloomberg: Hacker Attacks Top Latest U.S. List of Global Threats

Hostile hackers or an `isolated state' may succeed in breaching U.S.
computer networks and disrupting power grids and other vital services in the
next two years, the top U.S. intelligence official told Congress today.
[Source: Bloomberg, 12 Mar 2013: http://bloom.bg/ZFai8Q .  PGN]

------------------------------

Date: Tue, 12 Mar 2013 10:32:49 -0700
From: Gene Wirchenko <genew () telus net>
Subject: "Mobile to the rescue when an airplane trip goes awry"

Galen Gruman, InfoWorld, 12 Mar 2013
An iPhone and iPad help our intrepid traveler survive flight delays,
flight cancelations, and unexpected overnight stays
http://www.infoworld.com/d/mobile-technology/mobile-the-rescue-when-airplane-trip-goes-awry-214103

The article also mentions problems with systems because his flight had not
be officially canceled.  This made dealing with his problem that much more
difficult.

------------------------------

Date: Sunday, March 17, 2013
From: Dewayne Hendricks
Subject: The end of Google Reader: Have I got news for you (G.F.)

G.F., Seattle, 17 Mar 2013
<http://www.economist.com/blogs/babbage/2013/03/end-google-reader>

Spring cleaning has a lot to commend it. But when Google announced that it
is binning its Reader, which aggregates information from websites' news
feeds, tech types around the world erupted in righteous fury. Many websites
which have come to depend on the service to power their news feeds now fret
that Google's decision will cost them millions of readers=97and with that
lots of advertising revenue. Users, meanwhile, worry about impending
newslessness.

Google launched Reader in 2005. By offering it to users for free, it
undercut, and ultimately eliminated, all substantial competitors in the
news-aggregation business. The few that remained began requiring a Google
Reader account and used the search giant's service to handle synchronisation
of feeds among a user's mobile and desktop devices. At the time, the servers
and storage required might have cost millions of dollars a year, posing a
high barrier to entry.

Google Reader relies on news-syndication technology collectively called
"RSS", even though there are in fact four rival formats (three types of RSS
and one called Atom). In the late 1990s "push" news services used dedicated
servers to collect information from news websites and push updates to
specialised software on users' computers. This overtaxed the early Internet,
as hundreds or thousands of people on a single network or Internet service
provider would each receive a separate hunk of data with every update. Push
was quickly banned and more or less died in 1999.

RSS gets round this problem by letting users to pick what news they want to
get. A user subscribes to an RSS feed by adding it to a list in so-called
newsreader software, which includes mobile and desktop programs and web apps
like Google Reader. Publishers automatically update syndication files (often
in all four popular formats) on their websites whenever they create or
update an item of content. Software on a user's computer "polls" to see if
changes were made, pulls the RSS file, compares it against the previously
retrieved copy, and highlights any changes. (Since the feeding website has
no information about the subscriber, unsubscribing too is hassle-free; when
a user removes the feed from his list, the website can no longer pester
him.)

Google (and other aggregators of the day) made the process more efficient
for publishers by reducing the number of requests for the RSS file. If a
million Reader users subscribed to *The New York Times* main feed, Google
only had to make a single query to retrieve the file. Google Reader users
would receive the changed *Times* stories the next time they logged into
Google's site or refreshed stories in software that relied on Reader for
updates. This shifted the burden of a million queries from *The Times* to
Google, and made Google the nexus for updates. (Google also solved a host of
technical problems ensuring that Reader offered a smooth experience.) ...

------------------------------

Date: Tue, 12 Mar 2013 11:12:34 -0700
From: Lauren Weinstein <lauren () vortex com>
Subject: Google offers help to attacked ("hacked") sites

http://j.mp/YY99rR  (Google Webmaster Central via NNSquad)

  "We certainly hope you never have to use our new Help for hacked sites
  informational series. It's a dozen articles and over an hour of videos
  dedicated to helping webmasters in the unfortunate event that their site
  is compromised."

------------------------------

Date: Mon, 11 Mar 2013 20:39:38 -0400
From: "Bob Frankston" <bob2-39 () bobf frankston com>
Subject: Re: Boeing 787s to create half a terabyte of data per flight
  (RISKS-27.19)

I'm not sure what the worry is since we are collecting much of this already.

The more interesting point is that this is no longer a large amount of data
so why does the IT guy think it is a lot? It costs under $20 retail and a
small fraction of that wholesale to store forever.

For society it does raise the risk of never forgetting but that's a separate
issue.

------------------------------

Date: Tue, 12 Mar 2013 09:23:05 +0000
From: Steve Loughran <steve.loughran () gmail com>
Subject: Re: Boeing 787s to create half a terabyte of data per flight

In Risks 27.19, Dag-Erling Smorgrav considers the fact that the Boeing 787s
will generate 0.5TB of data per flight, and asks "what could possibly go
wrong"?

First: what could be gained? That data can record subtle details in engine
operation that has never been created before, help correlate degradaton in
behaviour with past part history. If one part fails, the data of all similar
parts can be examined to identify which other parts have a similar history,
and may be susceptible.

For example, the " NASA-ONERA Collaboration on Human Factors in Aviation
Accidents and Incidents" work is combining datasets from the aircraft,
external datasources -- including the recent history of pilot workloads --
to determine correlating factors in Go-Arounds during landing":
http://naca.larc.nasa.gov/search.jsp?R=20120012534&qs=N%3D4294966753%2B4294724598.
Maybe this could even go some way to avoiding the default "blame the pilots"
policy that surfaces in crashes today.

The data then, could be invaluable. What is needed is keeping that data
secure and with effective provenance. You don't need an Internet connection
to keep the data; at 0.5 TB/flight you don't want to be uploading it off the
airplane anyway, not unless "your flight is delayed until the upload
completes" is to become the new cause of delays (which becomes another
factor for NASA-ONERA to worry about). Swapping out an SSD disk is far
simpler -- though that adds tracking and provenance of the SSDs to the
problem.

------------------------------

Date: Tue, 12 Mar 2013 09:28:18 -0500
From: Dimitri Maziuk <dmaziuk () bmrb wisc edu>
Subject: Re: How SSD power faults scramble your data (Kuenning, RISKS-27.19)

My impression, catchy titles aside, is that they fail just like HDDs with
huge write caches -- if those caches cached more or less random chunks of
random files, and not necessarily the files that were written to
recently. The unpleasant thought is having that kind of failure in a
journaling setup that stores the journal on SSD for performance. Chunks of
data you'd lose from HDD's write cache won't match the chunks of the journal
lost on the SSD. The result is a filesystem scrambled beyond repair.

It is largely theoretical, yes, but unfortunately Murphy's Law is not.

------------------------------

Date: Tue, 12 Mar 2013 09:32:40 -0700
From: Lauren Weinstein <lauren () vortex com>
Subject: Harvard apologizes after secret e-mail search

http://j.mp/10Is1iw  (CNN via NNSquad)

  "On Monday, the school apologized for the way it handled a secret search
  of the e-mail accounts of resident deans. It conducted the search in an
  effort to find who leaked information about the scandal to the media last
  year."

------------------------------

Date: Sun, 7 Oct 2012 20:20:16 -0900
From: RISKS-request () csl sri com
Subject: Abridged info on RISKS (comp.risks)

 The ACM RISKS Forum is a MODERATED digest. Its Usenet manifestation is
 comp.risks, the feed for which is donated by panix.com as of June 2011.
=> 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>
 *** Contributors are assumed to have read the full info file for guidelines.

=> .UK users may 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 takes you to Lindsay Marshall's searchable archive at
 newcastle: 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
  is no longer maintained up-to-date except for recent election problems.
 *** NOTE: If a cited URL fails, we do not try to update them.  Try
  browsing on the keywords in the subject line or cited article leads.
==> Special Offer to Join ACM for readers of the ACM RISKS Forum:
    <http://www.acm.org/joinacm1>

------------------------------

End of RISKS-FORUM Digest 27.20
************************


  By Date           By Thread  

Current thread:
  • Risks Digest 27.20 RISKS List Owner (Mar 18)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]