Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: RISKS List Owner (riskocsl.sri.com)
Date: Sat Sep 01 2001 - 16:47:58 CDT
RISKS-LIST: Risks-Forum Digest Saturday 1 September 2001 Volume 21 : Issue 64
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/21.64.html>
and by anonymous ftp at ftp.sri.com, cd risks .
Temelin nuclear plant software problem (Pete Mellor)
Blame the victim: vandalized Web sites may be liable for damages (NewsScan)
More risks when driving (Martin Cohen)
Risks of "pre-owned" computers (Nick Brown)
Microsoft Reader e-books broken (David Farber)
AOL silently dropping mail (Simon Waters)
eBay fails to protect email addresses of users (Vassilis Prevelakis)
Re: Avoiding prosecution of the DMCA (A J Stiles)
Risks and madness on the BT Cellnet site (Mike Perry)
Not such an equal opportunity (Bill Lamb)
Re: Code Red 9? Code Crimson (Bob Frankston)
Risks of outsourced check verification (Peter Simpson)
Can't hold room, but can bill (Sandy Antunes)
Caller ID vs. ANI confusion, again (William Kucharski)
Re: Mixing advertising and credit-card activation (John Clarke)
REVIEW: "Information Security Management Handbook", Tipton/Krause (Rob Slade)
Abridged info on RISKS (comp.risks)
Date: Mon, 27 Aug 2001 15:04:35 +0100 (BST)
From: Pete Mellor <pmcsr.city.ac.uk>
Subject: Temelin nuclear plant software problem
The following is one item from the regular news digest produced
by the students of Charles University, Prague:-
CAROLINA No 429, 24 Aug 2001
FROM THE EVENTS OF THE PAST TWO WEEKS (August 9 - August 22)
Temelin up Again, down Again
The Temelin nuclear power plant was activated again 12 Aug 2001 after three
months of repairs to a vibrating turbine (see Carolina 428). The relaunch of
Temelin provoked hostile reactions from some Austrian politicians and
anti-nuclear and environment activists.
News leaked 15 Aug about new vibrations in the turbine, which caused an
18-hour shutdown. However, plant officials claimed the shutdown was used to
"balance a rotary part in the turbine." The reactor 19 Aug was automatically
switched off due to a software error in a steam-delivery regulator.
Temelin opponents claimed this shutdown was the 23rd since the beginning of
operating tests. According to Temelin management, the shutdowns are a
normal part of the testing procedure and are not related to nuclear safety
problems. Temelin CEO Frantisek Hezoucky said Temelin is exceptional only in
one respect: it is the very first nuclear power plant where its testing is
broadcast live to the public.
STUDENTS' E-MAIL NEWS FROM THE CZECH REPUBLIC
Charles University in Prague, Faculty of Social Sciences
Smetanovo nabr. 6, 110 01 Prague 1, Czech Republic
e-mail: CAROLINAmbox.fsv.cuni.cz ISSN 121-5040
tel: (+4202) 22112252, fax: (+4202) 22112219
Date: Mon, 27 Aug 2001 11:00:13 -0700
From: "NewsScan" <newsscannewsscan.com>
Subject: Blame the victim: vandalized Web sites may be liable for damages
Some legal scholars are suggesting that a Web site vandalized by hacker
attacks may itself be legally liable if its customers suffer damages and if
the site was negligent in maintaining security. Law professor Margaret Jane
Radin of Stanford University predicts: "A court is going to say it is
negligent of you not to implement preventative measures if they are
reasonably effective and affordable." No reported court decisions have dealt
with the issue, but Radin says that lawsuits in the near future are highly
likely to be lodged against companies and network providers targeted by
"denial of service" attacks. [*The New York Times*, 24 Aug 2001; NewsScan
Daily, 27 August 2001
Date: Sat, 18 Aug 2001 01:31:48 GMT
From: Martin Cohen <mjcohenmediaone.net>
Subject: More risks when driving
*The New York Times* e-mail version contained an ad offering to teach you a
language while you are driving. Imaging trying to learn an irregular verb
while negotiating difficult traffic.
[You might drive right through a subjunction. Incidentally, someone was
jogging toward me this morning when his cell phone rang. At least he had
the good sense to stop running. PGN]
Date: Sat, 1 Sep 2001 13:55:20 +0200
From: BROWN Nick <Nick.BROWNcoe.int>
Subject: Risks of "pre-owned" computers
The BBC reports that "confidential files containing the identities of
alleged paedophiles and their victims were found on a second-hand computer
bought from Bristol University".
Not a new RISK, but the first time I've seen this particular combination.
Does *your* local social welfare department, public hospital, or police
station have a statutory duty (in the interest of the taxpayers) to sell,
rather than destroy, old equipment ? And if so, is there a mandatory
procedure for securely erasing the hard disk first ?
Nick Brown, Strasbourg, France.
Date: Fri, 31 Aug 2001 23:51:19 -0400
From: David Farber <davefarber.net>
Subject: Microsoft Reader e-books broken
An anonymous programmer has found a way to decrypt Microsoft Reader
e-books on Windows PCs, but has not released it.
[Source: Breaking Microsoft's e-Book Code, By Wade Roush, Technology Review,
30 Aug 2001, http://www.technologyreview.com/web/roush/roush083001.asp;
PGN-ed; Dave has been predicting this, but then all lame protection seems
to be easily broken, relying on the DMCA for protection. Dave's archives
are at http://www.interesting-people.org/ . PGN]
Date: Sat, 25 Aug 2001 23:49:09 +0100
From: Simon Waters <Simonwretched.demon.co.uk>
Subject: AOL silently dropping mail
I received reports from an AOL user of e-mail's not getting through.
Checking log files show that AOL's mail server had received all the messages
Queries to AOL's postmaster account received no response.
Web pages run by AOL users suggest the cause of this is that I may have
triggered a "suspicious relaying" trap with the AOL server.
Assuming this is the case it is interesting that AOL choose to drop the mail
silently, when all the information required to make such a decision is
available to the mail transport agent before the body of the mail is
sent. Thus AOL could choose to refuse the mail politely, using less
bandwidth, and informing the sender of a problem, but prefer to waste
bandwidth and delete the e-mail silently.
The Risk? Assuming AOL cares enough about their subscribers e-mail not to
delete it without notifying sender or recipient, or answer questions on the
topic. The only way I can see to mitigate the risk is to switch to another
Moderated discussion of teleworking at news:uk.business.telework
Date: Sun, 26 Aug 2001 18:01:09 -0400 (EDT)
From: Vassilis Prevelakis <vassilipdsl.cis.upenn.edu>
Subject: eBay fails to protect email addresses of users
Normally eBay will not disclose the email addresses of its users. When you
wish to send email to an eBay user, eBay provides a proxy service accepting
the email and then forwarding it to the recipient.
However, if the mailhost for the recipient is down or unavailable, the
sender will get a warning email saying that the original message could not
be delivered but the system will go on trying, WITH THE E-MAIL ADDRESS OF
Another example of not thinking things through.
Vassilis Prevelakis, Distributed Systems Laboratory, Univ. of Pennsylvania
Philadelphia, PA 19104-6389 +1 215 898 0375 vassilipdsl.cis.upenn.edu
Date: Sun, 26 Aug 2001 11:59:03 +0100
From: "A J Stiles" <ajs2adyx.co.uk>
Subject: Re: Avoiding prosecution of the DMCA (Re: Petrou, RISKS-21.62)
But you are forgetting the law of Dual Criminality. A person can only be
extradited from one country to another if what the person did was recognised
as a criminal offence in the country where they did it. Since pointing out
a security vulnerability is not a criminal offence in most countries,
extradition can be refused. (Otherwise anyone who drinks alcohol could be
extradited to any muslim country and executed!)
Of course, the USA could act illegally (as it has done on many occasions
in the past). That would technically be an act of war .....
A J Stiles <ajs2adyx.co.uk> http://pages.zoom.co.uk/~nineladies/
Date: Fri, 24 Aug 2001 18:39:42 +0100
From: "Mike Perry" <PERRYMuk.ibm.com>
Subject: Risks and madness on the BT Cellnet site
I've just registered with the BT Cellnet site in order to be able to view
my mobile phone bill online. I had to choose some authentication items,
and I quote here from the website:
For security purposes our on-line services are password protected -- in
order to use them you need to register by providing a username, password,
a memorable item, and a password hint.
Your Username and Password must be unique to yourself. Try to use
something memorable - you will need to use these every time you logon.
Your Password will expire every 90 days and you will be required to choose
a new one. You will be automatically prompted to change your password
whenever you logon after the 90 day period has expired. To make your
password easier to remember you can use the same password but add a
different number each time a change is needed. For example password1,
password2, password3 and so on.
Looks like a well-known risk is not as widely-known as we might hope.
But wait -- it now leaves the realm of "bad", and enters the "mad":
The Password Hint is a word or phrase that you can choose to remind you of
your password should you forget it. For example if your password is your
pet's name then the password hint could be 'pet's name'.
The Memorable Item is something that you will need to supply whenever you
need to see your Password Hint. Again try use something that is linked to,
and therefore will remind you of, your password and password hint.
The usual way that Web sites provide for forgotten passwords is to set up a
challenge-response, where the user gives a question that should be asked if
they forget their password, and the answer they will give to prove who they
are. So you can pick things which you are (fairly) sure wouldn't be known
by a miscreant, such as "what's the serial number on the back of your
watch?" or "what was the name of your first girl/boyfriend?". This has
always seemed to me to be a secure enough system where you don't fear
network snooping etc.
But how am I expected to remember "something that is linked to, and
therefore will remind you of, your password and password hint" in order to
help me when I've forgotten my password?
I know - maybe I'll write it down......
Mike Perry, IBM UK Webserver Group
Date: Fri, 17 Aug 2001 17:22:30 -0500
From: Bill Lamb <blamwmlc.net>
Subject: Not such an equal opportunity
I recently attempted to apply online for a position with Tarrant County
College in Fort Worth, Texas.
The first screen in the Web form was for Affirmative Action purposes and
required such items as full name, address and Social Security number.
Fortunately, I noticed there was no indication the connection had been
secured: no warning from my browser and no "locked" icon in the browser
window. I quit the site and e-mailed the school's HR department to report
the problem and ask for a "snail mail" address to which to send my resume.
Later that day I received a response from an HR employee stating the school
accepts applications _only_ via the online forms, but they are indeed
secure. Alternatively, I was welcome to visit the school's library to apply
online using one of their machines if I still felt uncomfortable in doing so
over the Internet.
I again e-mailed, restating the problem with their supposedly secure
connection, and noting that since I lived more than a hundred miles away I
wasn't likely to visit the campus simply to fill out a form.
Two days later I received a reply stating a "supervisor" would contact me
shortly. That was five days ago. No supervisor yet.
The risks of such a Web connection that may or may not be secure are
obvious. But the hidden - and greater - risk here lies in the institution's
apparent blind slavery to this new technology. While no doubt making their
jobs easier, the policy of only accepting applications online closes off
employment opportunities to an untold number of people simply because they
may not have access to the Internet or live within bus, car or walking
distance of the campus.
Not such an Equal Opportunity Employer, after all, though I know that wasn't
Bill Lamb blamwmlc.net www.wmlc.net
Date: Sat, 25 Aug 2001 19:07:02 -0400
From: "Bob Frankston" <rmf2gRisksbobf.Frankston.com>
Subject: Re: Code Red 9? Code Crimson (McDonald, RISKS-21.62)
By this reasoning, one shouldn't buy software from companies that write
software in languages that don't make buffer-length checking the norm such
as C and it's variants including C++. Languages such as Java, C# and PL/1
don't suffer this unless programmers get too clever and try to squeeze out
that extra nanosecond that an indirection may entail. Remember that a
computron saved means hours wasted!
[Yes, I know this is a more complicated topic, but a vow of poverty isn't
the answer to all problems -- not that I like being put in the position of
Date: Tue, 14 Aug 2001 07:32:12 -0400
Subject: Risks of outsourced check verification
I recently tried to pay for some clothing with a personal check at a large,
national clothing store. I was asked for a driver's license, which I
produced, and the sale went through normally.
I then went to a different department, and, again, tried to pay for more
clothing with a check. Produced my license. The clerk told me the
"transaction had been declined". I asked why, and she handed me a cash
register receipt with a code number and an 800 number. I asked her if I
could use her phone to call the number (hoping to straighten out whatever
the problem was) and was told they could not use it to call outside numbers.
When I got home, I called the number. It was a third party check approval
service. The person on the other end of the line asked for my ID (license)
number. She then told me that the transaction had been declined because of
"unusual check-writing activity". I asked her exactly what that meant. She
told me that they had just approved my check number 202 and then tried to
use check number 221. The first clerk had transposed two digits while
manually entering the check number.
So, my second check was declined. Of course, this "wasn't their fault", and
"wasn't the first clerk's fault, either...people make mistakes". My comment
that this mistake could easily have been cleared up if I had been allowed to
know why the check had been declined fell on deaf and uncaring ears.
I liked it better when the manager was called and scribbled his initials on
Date: Fri, 17 Aug 2001 16:03:58 -0400
From: Sandy Antunes <sandyrpg.net>
Subject: Can't hold room, but can bill
I had a reservation (via phone) with the Hyatt for a trade show.
Later I cancelled the credit card used to reserve it, so I called
the Hyatt to give them a new card number.
Problem 1: I couldn't find the confirmation number they'd given me.
Problem 2: They couldn't find a reservation for me, and insisted I did
not have one. And the hotel was booked for the entire trade show.
Solution (mine): Booked at another hotel.
... time passes ...
I get a statement from the _cancelled_ credit card, listing a charge by
the Hyatt for 1 day's stay. Oh oh. I call the Hyatt. The clerk is
easily able to call up my record using the credit card number and
verify that yes, I had a reservation and yes, I hadn't called to cancel
it so I had to pay for 1 night.
Oh, and they'd mistyped my name. Which to me explained why they'd 'lost'
my reservation in the first place. He got manager approval to refund the
credit charge because it lacked a "Cancellation Number", and it'll be at
least one billing cycle before it goes through.
So they couldn't find my information when I wanted to stay, but could find
it to bill.
Risks? Reservation clerks not believing customer, inconsistent procedures
and lookups, inaccurate data entry still being accepted by credit card
company, cancelled card not rejecting charges, probably others.
Sandy Antunes <aantunesscience.gmu.edu>
Date: Sat, 18 Aug 2001 01:50:02 -0600
From: "William Kucharski" <kucharskmac.com>
Subject: Caller ID vs. ANI confusion, again
In Risks-21.57, Mike Tuffs writes about his credit-card company getting his
phone number despite his having Caller ID blocked.
Once again, there are two distinct and COMPLETELY SEPARATE systems that
deliver calling phone numbers information to recipients. The system used for
toll-free numbers (which the author undoubtedly used to call his credit card
company) as well as for long-distance call billing and for 911 services is
ANI CANNOT be blocked, at least not without making a significant (and likely
questionably legal) effort to thwart the telephone system.
I suspect the answer about ignoring the "ignore" bit is just a script they
give the customer service people, or the agent was just making it up.
The bottom line is that your calling number is delivered to the recipient of
any toll-free call you make, whether in real time or via a billing statement,
REGARDLESS of whether you have Caller ID blocked or not.
William Kucharski <kucharskmac.com>
[Noted by quite a few readers, including the following. TNX. PGN]
Date: Fri, 17 Aug 2001 16:44:13 -0400
From: "John Clarke" <jclarkenortelnetworks.com>
Subject: Re: Mixing advertising and credit-card activation
An interesting story, and possibly an urban legend, about ANI. When
computerized call centers were becoming the norm, a major credit-card
company decided to use ANI to help the operators handle customer calls in a
more friendly manner. When a customer called from their home number, the
computers would automatically match the number to the account holders name,
even before the operator had picked up the call. The operator would then,
upon hearing the callers voice, respond with <Mr., Ms.> Account Name, how
can I help you?
Callers were so disturbed by the fact that the operator knew who they were
before they had identified themselves that the credit-card company
eventually told the operators to stop using this technique. They still know
who you are (or are likely to be), but withhold the info and allow you to
provide it before they use it. Customers are much happier with this method.
When you call an 800 number and reach a call center, your file has likely
already appeared on the agent's computer screen, whether they let you know
that or not.
Date: Mon, 27 Aug 2001 12:08:32 -0800
From: Rob Slade <rsladesprint.ca>
Subject: REVIEW: "Information Security Management Handbook", Tipton/Krause
"Information Security Management Handbook", Harold F. Tipton/Micki
Krause, 2000, 0-8493-9829-0/0-8493-0800-3, U$155.00
%E Harold F. Tipton haltipix.netcom.com
%E Micki Krause Micki.Krauseisc2.org
%C 2000 Corporate Blvd. NW, Boca Raton, FL 33431
%G 0-8493-9829-0, 0-8493-0800-3
%I Auerbach Publications
%O U$155.00 800-272-7737 auerbachwgl.com slintoncrcpress.com
%O available separately 0-8493-9829-0 $95.00 0-8493-0800-3 $59.95
%P 2 vol., 711 p. + 626 p.
%T "Information Security Management Handbook, Fourth Edition"
As an overview for the CISSP (Certified Information System Security
Professional) CBK (Common Body of Knowledge), this work covers a vast range
of topics. The CBK, and the book, is divided into ten domains, covering
access control systems, telecommunications, security management, systems
development, cryptography, security architecture, operations security,
business continuity, law and ethics, and physical security. The text
provides some excellent articles, some of which are general but detailed
overviews, and others that address particular problems or new technologies.
However, even with fifty nine articles and over thirteen hundred pages there
are gaps, some surprisingly basic.
The quality of the articles can vary widely. The first essay, on
biometrics, provides an admirable review of the subject, as well as some
solid, practical, and useful detail information. The next paper is a rather
odd treatment of single sign-on, addressing the concepts well, but in a
disjointed manner that makes reading or studying difficult. Following those
comes a paper ostensibly dealing with securing connections to external
networks. It collates some generic and vague descriptions of a variety of
topics, none of which are particularly informative or reliable. (A two-page
section on computer viruses contains numerous glaring and significant
errors. Personally, I continue to find it appalling that general security
texts deal so poorly with this topic.)
Other areas covered are firewalls (terse), perimeter security for the
Internet (again, but this time with excellent technical information on
TCP/IP specifics), extranets (doctrinaire), firewall management (very useful
for planning), the OSI (Open Systems Interconnections) network layer
security model (questionable utility), the OSI transport layer security
model (not much better), application layer security (interesting but
undetailed), communications and security protocols (broad overview, concise
but fills in some common gaps), security awareness training (reasonable
points for success), security architecture (brief but basic), IPsec (good
overview), risk analysis (thorough but perhaps a trifle pedantic), trade
secret protection (an interesting twist), information security for
healthcare (a tad verbose and US-centric), security for object-oriented
databases (listing proposals), fundamentals of cryptography (very clear
explanations of the math involved), key management (great review of
principles, and amusing anecdotes from history of the *wrong* ways to manage
keys), Kerberos (extensive coverage of both details and concepts), PKI
(Public Key Infrastructure, a quick guide to the basics), microcomputer and
LAN security (good concepts, overly optimistic, oddities in details),
trapping intruders (quick concepts), Java security (quick basics), business
continuity planning (a new process), restoration after disaster (general
review), computer crime investigation (good coverage of many aspects),
Internet ethics (emphasis on privacy), jurisdictional issues
(miscellaneous), intrusion detection (concepts and evaluation points),
single sign-on (opinion this time), authentication services (concepts and
amusing overview), email security (concept review), ATM (Asynchronous
Transfer Mode) security (without really discussing security), remote access
(background fundamentals), sniffers (concepts and details), enclaves
(firewalls within), IPsec (good details), penetration testing (very basic
policies), policy (some good points but quite random), the security business
case (opinion), PeopleSoft security (as for any major database), World Wide
Web application security (reiteration of general security planning with a
few Web specifics), common system design flaws (an important set), data
warehouses (standard system development advice with limited security
relevance), PKI (simplistic), introduction to encryption (a good one), new
models for cryptography application (useful for planning), cryptanalysis
(decent review of terminology), message authentication (detailed), UNIX
security (concepts and tools), hacker tools (not very detailed), malicious
code (theoretical and incomplete), business impact assessment (after Y2K),
computer crime investigation (document everything), computer incident
response teams (CIRTs, vague), intrusion detection (vague and repetitious),
and operational forensics (retain evidence and data).
Observant readers will have noted a fair amount of duplication in that list.
In fact, the reiteration of content is worse than appears here, since many
topics rely on others, and certain basic ideas (Kerberos operations, the
Diffie-Hellman public key system, and risk management, for three examples)
recur in a variety of other discussions, with differing levels of detail.
As in any work this size a number of outright bizarre mistakes have
occurred, like the table showing the file structure of an authentication
database, which has been swapped with the structural diagram of a completely
different authentication system.
This is the closest thing there is to a textbook for the CISSP exam. It is
fairly easy to see which sections have been reproduced in the ISC(2)
(International Information System Security Certification Consortium) course
(in some cases complete down to specific errors). Intriguingly, there are
sections of the course that previously were covered by the third edition,
and which do not appear in any significant form in this work. (An example
is the discussion of the standard formal security models, such as Bell-La
Padula and Clark-Wilson.)
It should be noted that there is a significant difference in character
between the two volumes. The first volume deals with topics that are closer
to the heart of security, and the essays are generally more valuable to the
practitioner. Volume two contains papers over a wider range of subjects,
many of which (with the notable exception of the pieces on cryptography)
have little or no relevance to security beyond fundamental concerns that are
well covered elsewhere. Book one will be useful to the CISSP candidate and
any specialty security worker: book two may be of interest to a narrower
group of senior security executives and theorists, and, ironically, a wider
audience of those interested in newer technologies in general.
The quantity of good information that is contained in the work is
definitely worth the price, but there could easily be a wholesale
pruning of deadwood.
Date: 12 Feb 2001 (LAST-MODIFIED)
Subject: Abridged info on RISKS (comp.risks)
The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you. Alternatively, via majordomo,
send e-mail requests to <risks-requestcsl.sri.com> with one-line body
subscribe [OR unsubscribe]
which requires your ANSWERing confirmation to majordomoCSL.sri.com .
[If E-mail address differs from FROM: subscribe "other-address <xy>" ;
this requires PGN's intervention -- but hinders spamming subscriptions, etc.]
Lower-case only in address may get around a confirmation match glitch.
INFO [for unabridged version of RISKS information]
There seems to be an occasional glitch in the confirmation process, in which
case send mail to RISKS with a suitable SUBJECT and we'll do it manually.
.MIL users should contact <risks-requestpica.army.mil> (Dennis Rears).
.UK users should contact <Lindsay.Marshallnewcastle.ac.uk>.
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
The full info file will appear now and then in future issues. *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to risksCSL.sri.com with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
[volume-summary issues are in risks-*.00]
[back volumes have their own subdirectories, e.g., "cd 20" for volume 20]
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue].
Lindsay Marshall 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
==> 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
End of RISKS-FORUM Digest 21.64