[RISKS] Risks Digest 26.10

From: RISKS List Owner <risko_at_private>
Date: Sat, 10 Jul 2010 12:06:42 PDT
RISKS-LIST: Risks-Forum Digest  Saturday 10 July 2010  Volume 26 : Issue 10

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
The current issue can be found at

Con-Ed Nerve Center Fights to Keep Lights On (Gabe Goldberg)
Cal payroll data system cannot be changed to cut all employees' pay
Loophole May Have Aided Theft of Classified Data (Gabe Goldberg)
What Does Microsoft Know About You? (Lee Pender via Monty Solomon)
NY bank IT tech pleads guilty to data theft, fraud (Robert McMillan via
  Monty Solomon)
To Stop Cheats, Colleges Learn Their Trickery (Trip Gabriel via Monty Solomon)
Healthcare data risks (PGN)
Bank fishes phishing (Diomidis Spinellis)
Apple Acknowledges Flaw in iPhone Signal Meter (Miguel Helft via Monty Solomon)
Re: Previous user's data on my "new" GPS device (Thomas Russ)
Re: Software auto-updaters (Merlyn Kline, Paul Schreiber)
REVIEW: "SSL and TLS: Theory and Practice", Rolf Oppliger (Rob Slade)
Re: Jumping the Walrus: When Risk Management Goes Bad (Richard I. Cook)
Abridged info on RISKS (comp.risks)


Date: Thu, 08 Jul 2010 14:33:51 -0400
From: Gabe Goldberg <gabe_at_private>
Subject: Con-Ed Nerve Center Fights to Keep Lights On

It's not demonstrating a risk here, but how secure is that Carrier protocol?
Has a third-party evaluated it? Can it do anything besides telling
thermostats to cycle every half hour? Can it be misused?

Con-Ed Nerve Center Fights to Keep Lights On

"In times of unusually high demand for electricity, Con Ed tells Carrier,
the maker of heating and cooling systems, to send a radio signal that causes
those thermostats to cycle on and off every 30 minutes. Doing so shaved
about 25 megawatts off the peak demand this week, Con Ed officials said."

or http://tinyurl.com/2e8s69p


Date: Sun, 4 Jul 2010 02:08:25 -0700 (PDT)
From: spinoza1111 <spinoza1111_at_private>
Subject: Cal payroll data system cannot be changed to cut all employees' pay


Absolutely pathetic. One reason America is in decline: major computer
systems such as California's payroll were designed for computers like the
one I first worked on in 1971: it had 8000 "bytes" of RAM.

The information California needs to change is probably scattered through
"sequential" files such that to find any record, you have to read all the
records before it. And because there was no such thing as data base
technology in the 1950s, the "knowledge" of how to find pieces of data (such
as employee salaries) and interpret their contents (which could be a binary
number, a "binary coded decimal number" or some wack's Own Idea encapsulated
in said wack's code) much less change them, is lost and inside
incomprehensible computer code.

Probably, up to now, you submitted a "change" request to change an
employee's salary, possibly still as a punched card. These change requests
are probably combined or "batched" and then run together once a day or week.

This means you'd have to create a change request for every single employee
to implement Arnold's plan and match every record in a single whopper
run. My guess is that the "change" software, assuming there aren't different
versions for different classes of state employees (a distinct possibility)
is "NP complete", meaning that it is "fast" on modern computers for the
expected number of changes (a couple of orders of magnitude less than the
total file size) but ramps up exponentially for the unexpected case of
"change all employees".

Whereas in developing countries the payroll was automated recently using
best of breed database technology.

Matching two sets of data was rocket science in the 1950s. Today, most
ordinary computer programmers don't know how to do it, but databases
programmed by good programmers do so as fast as possible.

And I really don't want a job cutting state employee pay in sunny California
by reviving my mainframe skills. I will pass this job lead on to some of my
geezer friends.

Remember when you were a hotshot if you could program, and could fund your
California lifestyle with a part time coding job for the state?  Welcome to
the future, hotshot.


Date: Fri, 09 Jul 2010 01:09:30 -0400
From: Gabe Goldberg <gabe_at_private>
Subject: Loophole May Have Aided Theft of Classified Data

The soldier accused of downloading a huge trove of secret data from military
computers in Iraq appears to have exploited a loophole in Defense Department
security to copy thousands of files onto compact discs over a six-month
period. In at least one instance, according to those familiar with the
inquiry, the soldier smuggled highly classified data out of his intelligence
unit on a disc disguised as a music CD by Lady Gaga.



Date: Wed, 30 Jun 2010 23:42:36 -0400
From: Monty Solomon <monty_at_private>
Subject: What Does Microsoft Know About You? (Lee Pender)

We take a look at all the various sources of data Microsoft collects from
customers, how it stores and uses that data, and how its use of it stacks up
against Google and other competitors.

Lee Pender, *Redmond Magazine*, 1 Jul 2010

Just about every software vendor or Web service collects information about
its users. Some do it with more subtlety than others, but the fact is that
there's hardly an application or Web site that doesn't gather some sort of
intelligence about you every time you use it.  Microsoft, of course, is no
exception. From Windows Activation Technologies (WAT) to Bing, Microsoft
stockpiles information on you even when you don't sign up for services such
as Hotmail. But what does Microsoft know about you?

Actually, a more appropriate question might be: What kind of information
about you can Microsoft see? It could see a lot, but there are some things
that the company chooses not to view or store.  For example, the unpopular
WAT, formerly known as Windows Genuine Advantage, is perhaps the least
intrusive of the Microsoft information-gathering tools. Bing and Hotmail get
a little more personal, but experts and IT professionals say that they're
less worried about Microsoft regarding privacy than they are about some
other high-profile vendors.

What Microsoft Knows

Microsoft starts collecting information on you and your system within
minutes of you starting up a brand-new system. We asked Brendon Lynch,
senior director of privacy strategy at Microsoft, to help us compile a
step-by-step explanation of what Microsoft knows and when it knows it.  The
flow begins when you first start your system, log on to Windows and go
through the WAT validation process. ...


Date: Sat, 3 Jul 2010 21:05:38 -0400
From: Monty Solomon <monty_at_private>
Subject: NY bank IT tech pleads guilty to data theft, fraud (Robert McMillan)

Robert McMillan, *Business Week*, 2 Jul 2010

A former IT staffer with the Bank of New York Mellon pleaded guilty Thursday
to stealing sensitive information belonging to 2,000 bank employees and then
using that data to steal more than US$1 million from charities. ...



Date: Wed, 7 Jul 2010 23:02:18 -0400
From: Monty Solomon <monty_at_private>
Subject: To Stop Cheats, Colleges Learn Their Trickery (Trip Gabriel)

Trip Gabriel, *The New York Times*, 5 Jul 2010

The frontier in the battle to defeat student cheating may be here at the
testing center of the University of Central Florida.

* No gum is allowed during an exam: chewing could disguise a student's
speaking into a hands-free cellphone to an accomplice outside.

* The 228 computers that students use are recessed into desk tops so that
anyone trying to photograph the screen - using, say, a pen with a hidden
camera, in order to help a friend who will take the test later - is easy to

* Scratch paper is allowed - but it is stamped with the date and must be
turned in later.

* When a proctor sees something suspicious, he records the student's real-time
work at the computer and directs an overhead camera to zoom in, and both
sets of images are burned onto a CD for evidence. ...


Date: Mon, 5 Jul 2010 14:13:12 PDT
From: "Peter G. Neumann" <neumann_at_private>
Subject: Healthcare data risks

  [Thanks to Deborah Peel, Founder and Chair, Patient Privacy Rights
  (http://www.patientprivacyrights.org) for these items; starkly PGN-ed]

1. Steve Green, *Lawsuit filed over UMC patient records' leak, *Las Vegas
   Sun*, 3 Jul 2010
  University Medical Center in Clark County NV is being sued for leaking
  confidential patient information.  But the hook in the story seems to be
  the way in which patients were informed of the leak: they were offered a
  one-year free subscription to a credit-monitoring system knowledge of
  whose expiration became public,  The *Sun* was also investigating a UMC
  employee who was tipping lawyers off on traffic accident victims.

2. ACLU sues over R.I. Health Information Exchange

  Claiming that not enough has been done to protect the privacy rights of
  patients, the Rhode Island chapter of the American Civil Liberties Union
  (ACLU) filed suit against the R.I. Department of Health (DOH), challenging
  the rules the agency has adopted to implement a centralized database of
  patient healthcare records in the state for its statewide health
  information exchange (HIE).


Date: Sun, 04 Jul 2010 00:19:01 +0300
From: Diomidis Spinellis <dds_at_private>
Subject: Bank fishes phishing

Earlier today I called my bank's helpdesk to obtain an electronic
certificate that was needed to transfer money to another account.  After
they verified my credentials the customer representative asked me:

* Did you respond to that email we sent you asking for your username and

Up to that point I was mechanically answering all their questions, but this
one made me pause.  In this forum we often criticize incompetent banks and
silly security procedures, so my first thought was about the cluelessness of
sending out such emails.  However, a second later I realized that *they*
were fishing, trying to find out if *I* had been the victim of a phishing
attack and replied negatively.  I was surprised by the question's
originality and cleverness, so I asked if they were indeed looking for
victims of phishing attacks and they acknowledged that this was their
intention.  Bravo!

Diomidis Spinellis - http://www.spinellis.gr


Date: Sat, 3 Jul 2010 15:54:07 -0400
From: Monty Solomon <monty_at_private>
Subject: Apple Acknowledges Flaw in iPhone Signal Meter (Miguel Helft)

Miguel Helft, 2 Jul 2010

Apple customers love to complain about the reception on their iPhones.  And
the problem may be worse than it looks.

Apple said on Friday that for years its phones had been exaggerating signal
strength by displaying too many bars - indicating stronger reception than
there ever was. The problem, Apple said, is a bug in the software, which it
promised to fix soon.

Once it does, it seems, customers will be able to see just how bad reception
really is.

The company said it discovered the problem while trying to explain the
mystery of the disappearing bars on its new iPhone 4, a week after some
users began complaining that when they held the phone a certain way, the
bars indicating signal strength dropped off sharply.  But Apple said the
flaw, which it promised to fix shortly, existed with older versions of the
iPhone, too.

For a company that obsesses over every detail of its products, the failure
to detect this longstanding problem earlier is astonishing.

Some customers say they are skeptical of Apple's explanation of the
vanishing bars. "I don't buy it that it is just a simple matter of the meter
not showing the right amount of signal strength," said Bryan Hurst, of
Hackettstown, N.J., who upgraded last week to an iPhone 4 from an iPhone
3GS. Mr. Hurst said he had had more problems with dropped calls with the new
handset than the old one. "It doesn't make any sense," he said.

But Apple disagrees and says there is plenty to like about the iPhone 4. The
much-vaunted antenna - designed specially for the new phone - works just
fine, the company said. In fact, Apple said, the iPhone 4 is the best ever
on several fronts, including wireless reception. ...



Date: Tue, 6 Jul 2010 11:55:59 -0700
From: Thomas Russ <taruss2000_at_private>
Subject: Re: Previous user's data on my "new" GPS device

It seems to me that this is just a high-tech twist on a risk that is
typically already present.  Unless one has taken the precaution of
establishing a separate mailing address for car registration information,
the automobile registration in the glove box of the car will typically
already have your home address on it.  Add in the attached garage and
automatic garage door opener, and the bad guys won't even need to jimmy the

  [Besides, putting in a bogus address does not help if the historical
  record shows your actual coordinates!  PGN]


Date: Mon, 05 Jul 2010 10:53:33 +0100
From: Merlyn Kline <merlyn_at_private>
Subject: Re: Software auto-updaters (Tyson, RISKS-26.09)

> I'd like to see a campaign to change the nature of auto-updaters (such as MS
> Word or Adobe).  [...]

Me too! I see several other problems here:

* The frequency of updates. With only a few common applications (and
  one OS) installed, I sometimes feel there is not ever a time when I'm
  not being nagged for an update.
* The need for reboots. I'm sure that many updates requesting a reboot
  don't (or shouldn't) really need it.
* An interaction between the last two points: many updaters don't
  check for updates until a reboot, which I generally only do if an
  updater has requested it. So one update can lead to another...

It seems to me that at least some of this ought to be in the hands of the
OS. It already needs a secure method of providing updates, which we must
trust. This uses, or could use, sensible protocols to ensure authentic
provenance as well as providing decent UI for update management, including
managing the risks inherent in such updates. If the back end were open to
third parties to add their updates to the stream, this could be all managed
far more effectively. This would still be open to abuse but less so, and
such abuse would be more easily controlled. While it smacks of the single
basket, it is a basket we already must trust.


Date: Mon, 5 Jul 2010 12:45:27 -0400
From: Paul Schreiber <paulschreiber_at_private>
Subject: Re: Software auto-updaters (Tyson, RISKS-26.09)

However, when a bug in the application (or operating system) causes your =
program to crash on launch (or crash during updating), you are left with =
an unusable application.

This happened with World of Warcraft for Mac OS X a few years ago.


Date: Wed, 7 Jul 2010 16:51:22 -0800
From: Rob Slade <rMslade_at_private>
Subject: REVIEW: "SSL and TLS: Theory and Practice", Rolf Oppliger

BKSSLTTP.RVW   20091129

"SSL and TLS: Theory and Practice", Rolf Oppliger, 2009,
%A   Rolf Oppliger rolf.oppliger_at_private
%C   685 Canton St., Norwood, MA   02062
%D   2009
%G   978-1-59693-447-4 1-59693-447-6
%I   Artech House/Horizon
%O   617-769-9750 800-225-9977 artech_at_artech-house.com
%O   http://books.esecurity.ch/ssltls.html
%O  http://www.amazon.com/exec/obidos/ASIN/1596934476/robsladesinterne
%O   http://www.amazon.ca/exec/obidos/ASIN/1596934476/robsladesin03-20
%O   Audience i+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P   257 p.
%T   "SSL and TLS: Theory and Practice"

The preface states that the book is intended to update the existing
literature on SSL (Secure Sockets Layer) and TLS (Transport Layer Security),
and to provide a design level understanding of the protocols.  (Oppliger
does not address issues of implementation or specific products.)  The work
assumes a basic understanding of TCP/IP, the Internet standards process, and
cryptography, although some fundamental cryptographic principles are given.

Chapter one is a basic introduction to security and some related concepts.
The author uses the definition of security architecture from RFC 2828 to
provide a useful starting point and analogy.  The five security services
listed in ISO 7498-2 and X.800 (authentication, access control,
confidentiality, integrity, and nonrepudiation) are clearly defined, and the
resultant specific and pervasive security mechanisms are mentioned.  In
chapter two, Oppliger gives a brief overview of a number of cryptologic
terms and concepts, but some (such as steganography) may not be relevant to
examination of the SSL and TLS protocols.  (There is also a slight conflict:
in chapter one, a secure system is defined as one that is proof against a
specific and defined threat, whereas, in chapter two, this is seen as
conditional security.)  The author's commentary is, as in all his works,
clear and insightful, but the cryptographic theory provided does go well
beyond what is required for this topic.

Chapter three, although entitled "Transport Layer Security," is basically a
history of both SSL and TLS.  SSL is examined in terms of the protocols,
structures, and messages, in chapter four.  There is also a quick analysis
of the structural strength of the specification.  Since TLS is derived from
SSL, the material in chapter five concentrates on the differences between
SSL 3.0 and TLS 1.0, and then looks at algorithmic options for TLS 1.1 and
1.2.  DTLS (Datagram Transport Layer Security), for UDP (User Datagram
Protocol), is described briefly in chapter six, and seems to simply add
sequence numbers to UDP, with some additional provision for security cookie
exchanges.  Chapter seven notes the use of SSL for VPN (virtual private
network) tunneling.  Chapter eight reviews some aspects of public key
certificates, but provides little background for full implementation of PKI
(Public Key Infrastructure).  As a finishing touch, chapter nine notes the
sidejacking attacks, concerns about man- in-the-middle (MITM) attacks (quite
germane, at the moment), and notes that we should move from certificate
based PKI to a trust and privilege management infrastructure (PMI).

In relatively few pages, Oppliger has provided background, introduction, and
technical details of the SSL and TLS variants you are likely to encounter.
The material is clear, well structured, and easily accessible.  He has
definitely enhanced the literature. not only of TLS, but also of security in

copyright Robert M. Slade, 2009    BKSSLTTP.RVW   20091129
rslade_at_private     slade_at_private     rslade_at_private
victoria.tc.ca/techrev/rms.htm blog.isc2.org/isc2_blog/slade/index.html


Date: Sat, 03 Jul 2010 18:16:22 -0500
From: "Richard I. Cook" <ri-cook_at_private>
Subject: Re: Jumping the Walrus: When Risk Management Goes Bad (RISKS-26.09)

This subject examined in detail by Lee Clarke in his book "Mission
Improbable: Using Fantasy Documents to Tame Disaster" -- which details
Exxon's disaster "plan" for spills around Valdez, Alaska. (University Of
Chicago Press, 2001, ISBN-10: 0226109429).

It is no surprise that companies develop fantasy documents for disaster
management. What is surprising is that regulators and agencies continue to
accept these documents as written.


Date: Thu, 29 May 2008 07:53:46 -0900
From: RISKS-request_at_private
Subject: Abridged info on RISKS (comp.risks)

 The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
 if possible and convenient for you.   The mailman Web interface can
 be used directly to subscribe and unsubscribe:
 Alternatively, to subscribe or unsubscribe via e-mail to mailman
 your FROM: address, send a message to
 containing only the one-word text subscribe or unsubscribe.  You may
 also specify a different receiving address: subscribe address= ... .
 You may short-circuit that process by sending directly to either
   risks-subscribe_at_private or risks-unsubscribe_at_private
 depending on which action is to be taken.

 Subscription and unsubscription requests require that you reply to a
 confirmation message sent to the subscribing mail address.  Instructions
 are included in the confirmation message.  Each issue of RISKS that you
 receive contains information on how to post, unsubscribe, etc.

=> The complete INFO file (submissions, default disclaimers, archive sites,
 copyright policy, etc.) is online.
 The full info file may appear now and then in RISKS issues.
 *** Contributors are assumed to have read the full info file for guidelines.

=> .UK users should contact <Lindsay.Marshall_at_private>.
=> SPAM challenge-responses will not be honored.  Instead, use an alternative
 address from which you NEVER send mail!
=> SUBMISSIONS: to risks_at_private with meaningful SUBJECT: line.
 *** NOTE: Including the string "notsp" at the beginning or end of the subject
 *** line will be very helpful in separating real contributions from spam.
 *** This attention-string may change, so watch this space now and then.
=> ARCHIVES: ftp://ftp.sri.com/risks for current volume
     or ftp://ftp.sri.com/VL/risks for previous VoLume
 <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive
 http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.
   Lindsay has also added to the Newcastle catless site a palmtop version
   of the most recent RISKS issue and a WAP version that works for many but
   not all telephones: http://catless.ncl.ac.uk/w/r
 <http://the.wiretapped.net/security/info/textfiles/risks-digest/> .
==> PGN's comprehensive historical Illustrative Risks summary of one liners:
    <http://www.csl.sri.com/illustrative.html> for browsing,
    <http://www.csl.sri.com/illustrative.pdf> or .ps for printing
==> Special Offer to Join ACM for readers of the ACM RISKS Forum:


End of RISKS-FORUM Digest 26.10
Received on Sat Jul 10 2010 - 12:06:42 PDT

This archive was generated by hypermail 2.2.0 : Sat Jul 10 2010 - 13:13:38 PDT