[28091] in RISKS Forum
Risks Digest 28.91
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Fri Aug 21 17:41:26 2015
From: RISKS List Owner <risko@csl.sri.com>
Date: Fri, 21 Aug 2015 14:41:21 PDT
To: risks@mit.edu
RISKS-LIST: Risks-Forum Digest Friday 21 August 2015 Volume 28 : Issue 91
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/28.91.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Ashley Madison needs Smarter Cheating??? (PGN on Jennifer Weiner)
Dealing with the Devastation from the Ashley Madison Hack (Josh Barro
and Justin Wolfers)
ATM security risk: nonfinalization (Alister Wm Macintyre)
Consumers are Cutting the Cord to Gain Choices and Pay Less (NYT)
UK orders Google to `forget' 9 news articles about RTBF (Consumerist)
Re: Could Hackers Take Down a City? (Peter Ladkin)
Re: gmail policy on BCCs, related to Mass. pot dispensary (Robert L. Wilson)
Re: Intel to customers: We listen to you... All The Time! (Baker, Slonim,
Baker, Maziuk, Baker)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Fri, 21 Aug 2015 9:56:38 PDT
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: Ashley Madison needs Smarter Cheating??? (PGN on Jennifer Weiner)
The Ashley Madison Hack Shows We're Too Dumb to Cheat
Jennifer Weiner, *The New York Times* op-ed, 21 August 2015
[We covet smart appliances, smart pebbles (in space), smart robots, but
what about smart people? Jennifer Weiner's wonderful NYT op-ed this
morning is absolutely delightful. In response to the surprisingly large
number of government employees outed by the AshMadHack, Jennifer proposes
a new category along the lines created by Fran Lebowitz, who once created
useful categories for people she believed were committing crimes against
the rest of us.
Here is her suggested new category:]
``You are a government employee and you were too stupid to create a new
email account when you registered on a website for cheaters.''
Here are some savory snippets from her op-ed piece:
``According to *The Washington Post*, the capital has the highest rate of
membership for the site of any American city. A number of those caught up
in the hack work at the Department of Justice and - #irony - the National
Security Agency.''
``Maybe it shouldn't come as a surprise that D.C. is full of cheaters, but
why, oh why, did it have to be full of stupid cheaters, cheaters too lazy
and incurious to go to Gmail.com before they cheated? We're talking
minimal effort here, people. Five minutes, a couple of security questions,
a password that isn't PASSWORD, and you're mywifehasnoidea@comcast.net, or
phil@wehaveanarrangement.com, and France isn't laughing at us anymore.
``If you're going to cheat, cheat smart.''
[The ACM Risks Forum does not endorse the last line, but smirks a little at
the irony and satire of the op-ed. It is just one more reminder that our
computer systems are inadequately trustworthy and that many users are
unjustly trusting. PGN]
------------------------------
Date: Thu, 20 Aug 2015 22:05:48 -0700
From: Henry Baker <hbaker1@pipeline.com>
Subject: Dealing with the Devastation from the Ashley Madison Hack
(Josh Barro and Justin Wolfers)
FYI -- So the Ashley Madison hack is the "Cyber Pearl Harbor" that
Adm. Michael Rogers has been incessantly warning us about? What is our
Cyber Commander's plan for retaliating against this hack which will live in
infamy? Perhaps Gen. Petraeus has a better retaliation strategy?
The economic devastation from the Ashley Madison hack will likely exceed
that from the Tianjin explosion.
"5 million marriages at risk"
"So we have around 800,000 extra divorces [as a result of the Ashley
Madison hack]"
"The Ashley Madison hack might mean that more kids grow up without married
parents."
"all the divorcing couples out there looking for studio apartments will
drive up rents and make it harder for millennials to move out of their
parents' basements adding another aspect of economic drag."
"The big costs here are real, it's just that most of them aren't measured
in our economic statistics."
http://www.nytimes.com/2015/08/20/upshot/an-ashley-madison-recession-or-an-ashley-madison-stimulus.html
Wages of Sin: An Ashley Madison Recession? Or an Ashley Madison Stimulus?
Josh Barro and Justin Wolfers, *The New York Times*, 20 Aug 2015
The revelation of who opened accounts on the Ashley Madison site for
adulterers got the attention of curiosity seekers and suspicious spouses.
Josh Barro and Justin Wolfers had a different impulse. They wondered
whether a surge in marital trouble resulting from the Ashley Madison hack
could hurt the economy -- or even, surprisingly, make it grow faster.
[The rest of this article is a delightful back-and-forth between Josh and
Justin, omitted here. PGN]
------------------------------
Date: Thu, 20 Aug 2015 20:49:56 -0500
From: Alister Wm Macintyre <macwheel99@wowway.com>
Subject: ATM security risk: nonfinalization
Companies are frequently making upgrades to their technology, not always for
the better.
My Bank's ATM used to be one transaction per instance of stick in plastic &
PIN#. Now, at end of transaction it asks if we want another transaction,
click on the YES or NO. Many customers have apparently not noticed this
feature, because about the time when I arrive at the ATM, it is showing the
final screen, from the prior customer. I always select No, but I wonder if
some other customers are not as honest as me. The ATM security camera
footage may figure it out, but the prior customer could be inconvenienced
until then.
A person does not need to even be a customer of the ATM network, to make a
killing. Many drive through ATM screens can be seen from a distance, and
the normal start screen is pretty obviously distinct from the more
transactions one.
I plan to suggest they need some kind of sensor to detect that a prior
customer has left the station, so that it can assume a No, before next
customer arrives.
[A nasty example of this risk mode involved election fraud cases in
Kentucky (R 25 76, correction in R 26 77) where the "change vote" ability
was misrepresented, and voters who did not properly finalize their votes
(which required more than clicking on the "vote" icon that merely meant
"review") allowed voting officials to change the intended votes. PGN]
------------------------------
Date: Fri, 21 Aug 2015 10:28:26 -0400
From: Monty Solomon <monty@roscom.com>
Subject: Consumers are Cutting the Cord to Gain Choices and Pay Less (NYT)
http://www.nytimes.com/2015/08/21/opinion/consumers-are-cutting-the-cord-to-gain-choices-and-pay-less.html
Congress and the FCC can help consumers have more broadband options as they
choose online services over cable TV.
------------------------------
Date: Fri, 21 Aug 2015 17:05:30 -0400
From: "David Farber" <farber@gmail.com>
Subject: UK orders Google to `forget' 9 news articles about RTBF
(Consumerist)
Orwell's MinTruth would love this *Consumerist* item. Dave [PGN-ed]
http://consumerist.com/2015/08/21/u-k-orders-google-to-forget-9-news-articles-about-the-right-to-be-forgotten/
Although Europeans in 28 countries have the option to ask Google to remove
Internet search results about themselves under certain conditions, Google is
pushing back against a new Right To Be Forgotten request one that seeks to
remove nine news articles about the right to be forgotten itself from its
Internet search results.
The United Kingdom's Information Commissioner's Office has ordered Google to
scrub the articles in question from the Internet, because they mention a man
who previously made a successful RTBF request.
See, the RTBF rule in the European Union says Google and other search
engines have to remove links to outdated or inaccurate information about a
person if they request they do so. That keeps defamatory statements, arrest
records for minor crimes and other information a person might like to keep
hidden in their present from coming back to haunt them whenever their name
is searched on the Internet.
Though Google complied and took down links related to a man's conviction for
a minor crime committed 10 years ago, ICO says news articles since then
about Google doing so have mentioned the man's name and details about that
conviction.
Google declined the request, ICO says, arguing that the articles concern one
of its decisions to delist a search result and that they were an essential
part of a recent news story relating to a matter of significant public
importance.
But ICO deputy commissioner David Smith wrote in a statement that the same
RTBF rules apply here, just as they did when Google agreed to take down the
other web results for the man. ``Google was right, in its original
decision, to accept that search results relating to the complainant's
historic conviction were no longer relevant and were having a negative
impact on privacy. It is wrong of them to now refuse to remove newer links
that reveal the same details and have the same negative impact.''
Are those RTBF stories about individual requests in the public interest?
Yes, ICO says, but they shouldn't show up on a Google search for that
person's name, as that completely defeats the purpose of having the other
mentions removed in the first place.
Commissioner Smith: ``Let's be clear, we understand that links being removed
as a result of this court ruling is something that newspapers want to write
about. And we understand that people need to be able to find these stories
through search engines like Google. But that does not need them to be
revealed when searching on the original complainant's name.''
In July, a complaint filed here in the U.S. with the Federal Trade
Commission by advocacy group Consumer Watchdog argues not just that Google
should be honoring RTBF requests stateside, but that the company's refusal
to do so is a violation of federal law.
------------------------------
Date: Fri, 21 Aug 2015 09:35:12 +0200
From: Peter Bernard Ladkin <ladkin@rvs.uni-bielefeld.de>
Subject: Re: Could Hackers Take Down a City? (Macintyre, RISKS-28.90)
> Some pipeline explosions have been due to mistakes in the control rooms of
> the pipeline companies. Can they be hacked to cause such an accident on
> purpose?
The answer seems to be that it has happened, according to Thomas Reed, a
former USAF secretary and former member of the USG NSC. See
http://www.telegraph.co.uk/news/worldnews/northamerica/usa/1455559/CIA-plot-led-to-huge-blast-in-Siberian-gas-pipeline.html
Peter Bernard Ladkin, University of Bielefeld and Causalis Limited
www.rvs.uni-bielefeld.de www.causalis.com
------------------------------
Date: Fri, 21 Aug 2015 14:51:06 -0500
From: "Robert L. Wilson" <wilson@math.wisc.edu>
Subject: Re: gmail policy on BCCs, related to Mass. pot dispensary (Levine)
I would not be surprised if many comp.risks readers, like myself, stay
away from things like Google groups on general principles! It has been
an issue for me: there is someone involved with a hobby I enjoy (amateur
radio) who wants to be able to send a set of us email using exactly that
mechanism. I explained what I thought about almost all such social media
and their risks and she has been willing to send me email separately.
But I think this is another problem with that proposed solution that is
worse than the time it takes to set up a group.
------------------------------
Date: Thu, 20 Aug 2015 15:50:33 -0700
From: Henry Baker <hbaker1@pipeline.com>
Subject: Re: Intel to customers: We listen to you... All The Time! (Slonim)
[I can't tell whether this reply is tongue-in-cheek or not, so I'll answer
it seriously.]
Yes, it's true that the SW -- e.g., Win10 -- (presumably) controls this HW
audio spying feature.
However, Intel's audio spying capability provides an additional *attack
surface* for hackers/govts/spouses/competitors to exploit.
There appears to be no way to disable this "feature" permanently, so one is
forevermore at risk of being bugged by his/her own cellphone/computer due to
"misconfiguration" and/or hacking.
Now it's entirely possible that there are many other electronic components
already in a computer/cellphone that can be used as microphones -- in
particular, the motion sensors have already been hacked to do exactly that.
But an audio capability with enough fidelity to enable speech understanding
is also good enough to cause an enormous amount of privacy trouble.
------------------------------
Date: Fri, 21 Aug 2015 05:32:18 +0300
From: Edwin Slonim <eslonim@minols.com>
Subject: Re: Intel to customers: We listen to you... All The Time! (Baker)
There is no microphone in the Intel processor. No new attack surface. Just
an improvement in wake up from sleep.
Previously, waking up the processor or putting it back to sleep took many
tens of milliseconds, so if it was woken up every time a voice sound was
heard it would not get back to sleep before the next phoneme.
It's not even audio specific. You are critical of an application someone at
MS dreamed up.
------------------------------
Date: Thu, 20 Aug 2015 21:20:18 -0700
From: Henry Baker <hbaker1@pipeline.com>
Subject: Re: Intel to customers: We listen to you... All The Time! (Slonim)
You'll have to excuse me, but I consider the ability of a "sleeping"
computer to recognize & interpret speech as a new attack surface -- right up
there with various TV settop boxes constantly listening to their customers'
bedrooms.
If it's all the same to Intel, I'd like to let my sleeping computers lie.
You have just confirmed that Intel's "feature" is even creepier than the
article indicated. Intel apparently has a "tin ear" when it comes to their
customers' privacy.
------------------------------
Date: Fri, 21 Aug 2015 09:20:10 -0500
Subject: Re: Intel to customers: We listen to you... All The Time!
From: Dimitri Maziuk <dmaziuk@bmrb.wisc.edu>
On a serious note, I can think of several problems with putting a microphone
on a CPU, but in terms of privacy and security implications: it would be no
different from a smartphone. We already have those.
------------------------------
Date: Fri, 21 Aug 2015 06:54:02 -0700
From: Henry Baker <hbaker1@pipeline.com>
Subject: Re: Intel to customers: We listen to you... All The Time! (Maziuk)
The joke Dimitri refers to is good enough to spell out (!) in full:
https://www.springer.com/cda/content/document/cda_downloaddocument/9781893115729-c1.pdf
"A great example appeared in a 1999 issue of Computing [6]. A
representative of a company with a voice recognition product prepared to
demonstrate their product and asked the crowd gathered to see the
demonstration to be quiet. Someone in the back of the room shouted,
``Format C Colon Return!'' Someone else shouted, ``Yes, Return!'' The
software worked perfectly, reformatting the primary disk on the
demonstration unit, requiring that the machine finish its format and have
all of its software and data reinstalled."
------------------------------
Date: Mon, 17 Nov 2014 11:11:11 -0800
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://mls.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 28.91
************************
