The RISKS Digest
Volume 24 Issue 32

Wednesday, 14th June 2006

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


Hospitals have dramatically reduced unnecessary deaths
Unverified air traffic data
David Magda
Report on security risks of applying CALEA to VoIP
Susan Landau
TIAA Breaches Whistleblower
Al Macintyre
Cybersecurity plan of the Federal government: what a screw-up
Fred Cohen
IRS Laptop Lost With Data on 291 People
Christopher Lee via Monty Solomon
Windows XP update may be classified as "spyware"
Lauren Weinstein
How MS spyware could be used by hackers to disable systems
DoE Discloses Data Theft
Ari Ollikainen via Dave Farber
UnSalted Credit Cards
Mark Ennis
Lottery scam spam — unclear on the concept
Drew Dean
Dental X-Rays go Digital---same old problems
Howard Israel
Silver Bullet: Dan Geer
Gary McGraw
REVIEW: "Software Security: Building Security In", Gary McGraw
Rob Slade
Info on RISKS (comp.risks)

Hospitals have dramatically reduced unnecessary deaths

<"Peter G. Neumann" <>>
Wed, 14 Jun 2006 12:25:59 PDT

  [Do you recall "Hospital operates on wrong patient?" (lead item in
  RISKS-24.11)?  This is the other side of the coin.  TNX to Lauren
  Weinstein for sending this one to me.  PGN]

Hospitals Cut Lethal Errors Rate, Mike Stobbe, AP item,*Newsday*, 14 Jun 2006,0,6425411.story?coll=sns-ap-nationworld-headlines

A campaign to reduce lethal errors and unnecessary deaths in U.S. hospitals
has saved an estimated 122,300 lives in the last 18 months.  About 3,100
hospitals participated in the project, sharing mortality data and carrying
out study-tested procedures that prevent infections and mistakes.  Experts
say the cooperative effort was unusual for a competitive industry that
traditionally doesn't like to publicly focus on patient-killing problems.
Medical mistakes were the focus of a widely noted 1999 national report that
estimated 44,000 to 98,000 Americans die each year as a result of errors and
low-quality care.

Perhaps the best known of the six changes was to deploy rapid response teams
for emergency care of patients whose vital signs suddenly deteriorate. ...
Another urged checks and rechecks of patient medications to protect against
drug errors. A third focused on preventing surgical site infections by
following certain guidelines, including giving patients antibiotics before
their operations.

Unverified air traffic data

<David Magda <>>
Thu, 8 Jun 2006 19:19:39 -0400

Dick Smith [1] is warning [2] that the new ADS-B air traffic system [3] uses
unverified data to plot what (supposedly real) aircraft are doing:

> But Mr Smith, who is campaigning against the scheme and has raised safety
> and security concerns about the design, said the system had no way of
> verifying whether a plane was where it claimed to be or if it existed at
> all.
> He said the FAA was looking at ways of encrypting signals or setting up
> multiple ground stations at each location to allow the traffic controllers
> to determine whether a signal came from a moving aircraft.

The main advantage of the system is that radar (which is expensive to buy
and run) is not needed since aircraft broadcast their (supposed) position,
and that data can be received using less expensive equipment. Aircraft
determine their position by GPS.

I'm sure the disadvantages of an unauthenticated positioning system don't
have to be spelled out.


Report on security risks of applying CALEA to VoIP

<Susan Landau <>>
Tue, 13 Jun 2006 15:29:56 -0400

Below you'll find an executive summary of "Security Implications of Applying
the Communications Assistance for Law Enforcement Act to Voice over IP."
The full report is at .

Security Implications of Applying the Communications Assistance to Law
Enforcement Act to Voice over IP

  Steven Bellovin, Columbia University
  Matt Blaze,  University of Pennsylvania
  Ernest Brickell, Intel Corporation
  Clinton Brooks, NSA (retired)
  Vinton Cerf, Google
  Whitfield Diffie, Sun Microsystems
  Susan Landau, Sun Microsystems
  Jon Peterson, NeuStar
  John Treichler, Applied Signal Technology

Executive Summary

For many people, Voice over Internet Protocol (VoIP) looks like a nimble way
of using a computer to make phone calls.  Download the software, pick an
identifier and then wherever there is an Internet connection, you can make a
phone call.  From this perspective, it makes perfect sense that anything
that can be done with a telephone, including the graceful accommodation of
wiretapping, should be able to be done readily with VoIP as well.

The FCC has issued an order for all ``interconnected'' and all broadband
access VoIP services to comply with Communications Assistance for Law
Enforcement Act (CALEA) --- without specific regulations on what compliance
would mean.  The FBI has suggested that CALEA should apply to all forms of
VoIP, regardless of the technology involved in the VoIP implementation.

Intercept against a VoIP call made from a fixed location with a fixed IP
address directly to a big Internet provider's access router is equivalent to
wiretapping a normal phone call, and classical PSTN-style CALEA concepts can
be applied directly. In fact, these intercept capabilities can be exactly
the same in the VoIP case if the ISP properly secures its infrastructure and
wiretap control process as the PSTN's central offices are assumed to do.

However, the network architectures of the Internet and the Public Switched
Telephone Network (PSTN) are substantially different, and these differences
lead to security risks in applying the CALEA to VoIP.  VoIP, like most
Internet communications, are communications for a mobile environment.  The
feasibility of applying CALEA to more decentralized VoIP services is quite
problematic.  Neither the manageability of such a wiretapping regime nor
whether it can be made secure against subversion seem clear.  The real
danger is that a CALEA-type regimen is likely to introduce serious
vulnerabilities through its ``architected security breach.''

Potential problems include the difficulty of determining where the traffic
is coming from (the VoIP provider enables the connection but may not provide
the services for the actual conversation), the difficulty of ensuring safe
transport of the signals to the law-enforcement facility, the risk of
introducing new vulnerabilities into Internet communications, and the
difficulty of ensuring proper minimization.  VOIP implementations vary
substantially across the Internet making it impossible to implement CALEA
uniformly.  Mobility and the ease of creating new identities on the Internet
exacerbate the problem.

Building a comprehensive VoIP intercept capability into the Internet appears
to require the cooperation of a very large portion of the routing
infrastructure, and the fact that packets are carrying voice is largely
irrelevant.  Indeed, most of the provisions of the wiretap law do not
distinguish among different types of electronic communications.  Currently
the FBI is focused on applying CALEA's design mandates to VoIP, but there is
nothing in wiretapping law that would argue against the extension of
intercept design mandates to all types of Internet communications.  Indeed,
the changes necessary to meet CALEA requirements for VoIP would likely have
to be implemented in a way that covered all forms of Internet communication.

In order to extend authorized interception much beyond the easy scenario, it
is necessary either to eliminate the flexibility that Internet
communications allow, or else introduce serious security risks to domestic
VoIP implementations.  The former would have significant negative effects on
U.S. ability to innovate, while the latter is simply dangerous.  The current
FBI and FCC direction on CALEA applied to VoIP carries great risks.

TIAA Breaches Whistleblower

<Al Macintyre <>>
Sat, 10 Jun 2006 21:49:41 -0500

IT Manager seeks redress for firing, claiming SARBOX Whistleblower protection,1759,1969518,00.asp

US Supreme Court lowers Whistleblower protection for employees reporting
fraud or criminal misconduct to the proper authorities, but employees have
more protection if they go straight to the news media,%20%25Y

This is a familiar and disturbing picture.  Personnel find security problems
with employer systems, report them, nothing happens.  Computer staff exhaust
what can be done in-house to get the security problems resolved, but
leadership resistance is too strong.

A year later there is a serious security breach.  Top Managers claim nothing
much at risk, but ask computer staff to help the feds find out exactly what
was breached, which turns out to be practically everything.  Computer staff
gets fired.

What makes this worse is the news that the Feds apparently support the
coverup, when the whistleblowers appeal the employer punitive action.

Had computer staff lied to investigators, claiming no problem, like
management had wanted, they would still have their jobs.

Thus computer workers have to balance behavior that will help career
integrity vs. what is in the best interests of protecting customers and

However, there are lots of news stories of whistleblowers who successfully
prevail, so we should wait and see what happens in this case.

Cybersecurity plan of the Federal government: what a screw-up

<Fred Cohen <>>
Thu, 8 Jun 2006 06:01:35 -0700

I just read the new plan for funding information security at the Federal
level and it was pathetic. The most notable element of it is the fact that
they claim to align between several different things but in fact they don't
align at all. The things they identify as worth doing are the very things
that don't need to be done and the things they identify as not worth doing
are the things we most desperately need. But fear not - they won't put any
real money behind anything worthwhile in any case. The plan - if fully
implemented - would not even stop the large-scale theft of identity
information of all the people getting clearances or all the folks in the
military.  So we won't be getting much in the way of help from the federal
government in advancing the field for the next few years at least.

Fred Cohen & Associates; Security Posture; University of New Haven; ASP Press,,,, 1-925-454-0171

IRS Laptop Lost With Data on 291 People

<Monty Solomon <>>
Sun, 11 Jun 2006 21:13:33 -0400

An Internal Revenue Service employee lost an agency laptop early last month
that contained sensitive personal information on 291 workers and job
applicants, a spokesman said yesterday.

The IRS's Terry L. Lemons said the employee checked the laptop as luggage
aboard a commercial flight while traveling to a job fair and never saw it
again. The computer contained unencrypted names, birth dates, Social
Security numbers and fingerprints of the employees and applicants, Lemons
said. Slightly more than 100 of the people affected were IRS employees, he
said. No tax return information was in the laptop, he said.  "The data was
not encrypted, but it was protected by a double-password system," Lemons
said. "To get in to this personal data on there, you would have to have two
separate passwords."  Lemons said the Treasury Department's inspector
general for tax administration is investigating the loss. The IRS is
notifying affected individuals and advising them on steps to guard against
identity theft. Lemons declined to name the airline or the employee, or to
say whether the worker was disciplined, citing the ongoing investigation.
...  [Source: Christopher Lee, *The Washington Post*, 8 Jun2006, A04; PGN-ed]

Windows XP update may be classified as "spyware" (from Farber's IP)

<Lauren Weinstein>
June 6, 2006 1:15:05 AM EDT

There have been some murmurs about this in other forums, but since I've now
independently verified I figured I'd better report here.

A recent Microsoft update to Windows XP, which modifies the tool that
verifies the "validity" of XP installations to ensure that they are not
illicit, may itself be considered to be spyware under commonly accepted

The new version of the "Microsoft Genuine Advantage" tool reportedly will
repeatedly nag users of systems it declares to be invalid, and will then
apparently deny such users various "non-critical" updates.  Apparently
various parties have already found ways to bypass this tool, though the
effects of this on later updating capabilities remain to be seen.

However, I've noted a much more serious issue on local XP systems, all of
which are legit and pass the MS validity tests with flying colors.  It
appears that even on such systems, the MS tool will now attempt to contact
Microsoft over the Internet *every time you boot*.  At least, I'm seeing
these contacts on every boot after the tool update so far, and I've allowed
them to proceed to completion each time.  Perhaps it stops after some number
of boots, but there's no indication of such a limit so far.  The connections
occur even if you do not have Windows "automatic update" enabled.  ...

How MS spyware could be used by hackers to disable systems

Mon, 12 Jun 2006 12:11:53 -0700 (PDT)

An anonymous Slashdot user gives virus writers a worrying idea: "A virus
could use one of the 'Product-Key Changer' scripts ... to install a pirated
product key on every infected computer (wiping all traces of the original
key). This would render millions of genuine installations indistinguishable
from pirated installations. What a mess for Microsoft! They would have to
immediately 'kill forever' the WGA helper, and maybe even remove the WGA
check on Windows Update. Such a virus would be a hard lesson to learn for
the writers of all kinds of automated 'genuine' checks."

DoE Discloses Data Theft (via Dave Farber's IP)

<Ari Ollikainen <>>
June 10, 2006 1:37:31 PM EDT

Foot dragging on an incident which occurred in September 2005...
  [and was not reported until 8 June 2006.  PGN]

Energy Dept. Discloses Data Theft
Victims, Top Officials Were Not Told About 2005 Hacking

A hacker stole a file containing the names and Social Security numbers of
1,500 people working for the Energy Department's nuclear weapons agency.
[Source: Associated Press item, *The Washington Post*, 10 Jun 2006, A04]

UnSalted Credit Cards

<Mark Ennis <>>
Tue, 13 Jun 2006 15:14:25 +0100 (BST)

The credit card companies publish what is colloquially known as as the PCI
standard.  For the standard itself, see:

This covers various aspects of security for organisations that are involved
in the processing of credit cards.

I'm surprised to see however that where they suggest that cardholder data is

  Render sensitive cardholder data unreadable anywhere it is stored
  (including data on portable media, backup media, in logs, and data
  received from or stored by wireless networks) by using any of the
  following approaches.

  -One-way hashes (hashed indexes), such as SHA-1
  -Index tokens and PADs, with the PADs being securely stored
  -Strong cryptography, such as Triple-DES 128-bit or AES 256-bit with
   associated key management processes and procedures.

They omit to mention that one-way hashes of cardholder data are of little
use without applying a salt. They should - as has been documented here
before many programmers see no problem in wrapping a bare md5 function
around a sensitive value.

For instance - as is well known 16 digit credit card numbers start with a 6
digit bank code and end with a checksum. A reverse hash dictionary for all
unsalted MD5 codes for one bank code only needs to cover 16-6-1=9 digits of
possibilities - or one thousand million entries. This could be done for a
storage cost of:

 9 digit number = 4 bytes
 MD5 checksum = 16 bytes number
 Total = 20 bytes * 1,000,000,000 possibilites = 20Gb

As a result its completely feasible a program that asks for unsalted MD5 or
SHA-1 Hash of a credit card number and the 6 digit bank code could generate
the original credit card number after waiting for that bank code's 20gb
dictionary to be generated.

Mark Ennis, NetCommute Ltd. <>  00-353-1-8569539

Lottery scam spam — unclear on the concept

<Drew Dean <ddean@CS.Princeton.EDU>>
Wed, 7 Jun 2006 08:51:16 -0700

In my Inbox:


I'm sure they'd like me to give them 1 million Euros, but I think not.  With
my permission, they'll even enter me into a drawing for -5 Million Euros!
Wow, my lucky day! :-)

Dental X-Rays go Digital---same old problems

Wed, 07 Jun 2006 18:25:28 +0000

Personal experience, with my dentist yesterday evening.

It was a typical visit, except now my dentist is using a new digital x-ray
machine (from Kodak) that runs on a standard PC (probably this system:

The process to take the X-Ray is relatively the same as the old analog
method. Noticeable differences: 1) the X-Ray machine is physically smaller,
2) there is no film, but in its place is a reusable digital sensor with a
trailing wire leading out of the patients mouth. 3) images are rendered
immediately on a screen, so the tech can determine if the shot taken is OK
or needs to be re-taken. 4) the images are very clear and noticeably sharper
then the analog X-Rays (to my untrained eye).

Now the not so fun part.  After the tech completes the set of 6 pictures,
the dentist comes in to review. A few clicks and pop ups appear, a few too
quick clicks, and poof, the images are accidentally deleted and not
retrievable.  The tech admitted afterward that she usually does a save
before the dentist comes in. OK, lets do it again. Take a second set of
images. The tech does the save, but an hour glass comes up and the PC
freezes. The images are mostly still visible on the screen, except there are
a couple of pop-ups that are blocking one of the images of my teeth and they
can not be moved. The dentist comes in to review the images, but can not
access the application, since it is not functioning. The obvious thing to do
is a CTL-ALT-DEL to see what is going on. The CPU is idle, but the app is
"not responding". The dentist claims that this is the first problem he has
had in the few months he has been using the system. Since most of the images
are actually still viewable, he does his assessment, then starts to end the
hung processes.

Eventually a "Send Error Report" window appears giving the user the option
to send in an error report to the software maker, which he elects not to
send.  He reboots, then brings up the application, and then tries to access
my patient record and see if the X-Ray images were actually saved, but the
app gives him an error. My guess is that a file corruption occurred.

Of Note: The PC is Internet enabled, via dial-up access. I believe it is
used to transmit data for insurance processing (as confirmed via link
below).  Aside from the obvious application issues described above, I
started to wonder about HIPAA issues and how well my data/info is protected
by this PC linked to the Internet.  Also, thinking about what backup systems
are in use, etc.  Another thought--how easy would it be to manipulate the
digital images to sabotage a forensics investigation (another great use of
PhotoShop!)?  Delete the images to prevent the positive ID of a body, or
better yet, cause a body to be incorrectly identified (e.g., fake ones
death).  Do these images have digital signatures?  (Doubt it!)

While I didn't dig into it deeply, its just a matter of time before ...
Here is a  link to an online article (WSJ reprint?):    It highlights some pros/cons of going digital.

Howard Israel, CEO, Secure Systems Consulting, LLC  1-732-613-9464

Silver Bullet: Dan Geer

<"Gary McGraw" <>>
Mon, 12 Jun 2006 13:35:29 -0400

The second edition of the Silver Bullet Security Podcast with Gary McGraw
(hey, that's me) went up just a few seconds ago:

The first show (with Avi Rubin) proved to be pretty popular.  Hope you all
like this one too!  Feedback welcome through the website.

Marcus Ranum is on deck and Dana Epp is on the list.  Who else do you want
to hear from in Silver Bullet?


REVIEW: "Software Security: Building Security In", Gary McGraw

<Rob Slade <>>
Mon, 12 Jun 2006 11:54:22 -0800

BKSWSBSI.RVW   20060518

"Software Security: Building Security In", Gary McGraw, 2006,
0-321-35670-5, U$49.99/C$66.99
%A   Gary McGraw
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
%D   2006
%G   0-321-35670-5
%I   Addison-Wesley Publishing Co.
%O   U$49.99/C$66.99 416-447-5101 800-822-6339
%O   Audience a+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P   408 p. + CD-ROM
%T   "Software Security: Building Security In"

The preface states that the audience for the book is comprised of developers
(particularly those interested in secure software), security professionals
(in places), managers (in places), and academics (there are a couple of
chapters that indicate where further research might be useful).  McGraw also
introduces the major components of the book.  His "thee pillars" are not the
usual confidentiality, integrity and availability, but risk management,
"touchpoints," and knowledge.  The touchpoints are code analysis, risk
analysis, penetration (vulnerability) testing, security tests, abuse cases,
security requirements, and security operations.

Part one outlines the basics of software security.  Chapter one informs us
that problems exist in software, and notes the differences between bugs (due
to careless implementation) and flaws (due to poor design).  McGraw also
suggests his three pillars as a means of addressing the difficulty.  Using
an example software project, chapter two takes us through a risk management
framework in some detail.

Part two examines the touchpoints.  Chapter three introduces them in a
diagram related to the steps in the software development process (they are
numbered, although in a seemingly random pattern which turns out to be the
suggested order of effectiveness).  (The latter half of the chapter seems to
be more of a sermon on software security.)  Source code review tools (for
finding bugs) are described in chapter four.  Chapter five starts off with
traditional risk analysis definitions and then extends the concept with
details of the application of the process to software design.  (Sidebars on
software tools for program risk analysis, and other related items, are
dropped in seemingly at random.  The information is valuable, but the
reading flow is somewhat disjointed.)  Penetration testing of software
sounds like a good idea, but chapter six doesn't really define what the
topic involves.  (The sidebar on tools is a case in point: the tools are
listed and recommended, but the descriptions don't say what they actually
do.)  Risk-based security testing seems, by the end of chapter seven, to be
a special case of spanning tree analysis, but along the way a number of the
other touchpoints seem to overlap with it.  "Abuse cases" is the application
of known common vulnerabilities and attacks (perpetrated on systems similar
to yours), and analysis of means of protection while still in the design
phase.  Chapter eight provides a handy list of such attacks (if you are
building a Web application).  "Security operations," in chapter nine,
appears to be a discussion of how software developers and security
professionals should relate to each other.  (Touchpoint six, "security
requirements," is not covered.)

Part three covers additional topics.  Chapter ten outlines advice for a
software security program in a large company.  "Knowledge for software
security," in chapter eleven, is mostly an overview of material already
covered, but does include some additional tools.  Chapter twelve is a
taxonomy of coding errors, which should be valuable both for those working
on analysis of their own program security, and also researchers in the

One fairly consistent weakness is that the book seems to assume that all
software applications are network-based, and that all software problems
result from malicious attacks.  While Web-based applications are definitely
of great importance, and also subject to a larger range of difficulties,
this does limit the application of some of the material of the text in
regard to standalone programs where the major concern is integrity of data,
prevention of errors, and reliability of operation.

The writing and structure could use some work: in many situations it is not
easy to follow the thread of McGraw's argument.  However, there is no
denying the value of having all these ideas about software security brought
together in one volume.  There is a great deal of useful and interesting
material here, and, with commitment from the reader, much that will be
helpful in building more robust and reliable software.

copyright Robert M. Slade, 2006   BKSWSBSI.RVW   20060518

Please report problems with the web pages to the maintainer