The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 21 Issue 88

Tuesday 22 January 2002

Contents

Bulgarian parliament against weight loss
Jonathan Larmour
Pope loves Internet, but wants "anti-depravity regulation"
Declan McCullagh
Unshredders
PGN
Newspaper archives
Roger Needham
Virginia county recalls student laptops
NewsScan
Software uncovers e-mail untruths
NewsScan
Georgia Tech anti-cheating software
Walter Roberson
Anthrax mail irradiation can affect electronic devices in postal mail
Thomas Dzubin
Health insurer computer changes delay payments...
Don Mackie
Excel cut-and-pasting behaviour
Geoffrey Brent
Lotus Notes silently losing data
Erling Kristiansen
Woman says telephone makes unsolicited calls
Carl Fink
Answering machine provides door entry code
Benjamin Elijah Griffin
Microsoft using predictable passwords for Passport?
Rodger Donaldson
Re: Other blunders
Brett
Re: Kaiser Permanente exposes medical record numbers
George C. Kaplan
Re: Bogus dates for McAfee virus alerts
David Blakey
Re: AOL's spam filters
Jay Levitt
Call for Participation Open Source Software Development Workshop
Cliff Jones
Info on RISKS (comp.risks)

Bulgarian parliament against weight loss

<Jonathan Larmour <jlarmour@redhat.com>>
Tue, 22 Jan 2002 21:46:47 +0000

According to the (UK) Daily Telegraph, the Bulgarian parliament has a system
of electronic voting, whereby Members vote with cards using a machine
attached to their seats.

Unfortunately, the designers didn't anticipate that more enterprising MPs
would swap seats and also slip a voting card into absent neighbouring
colleague's machines!

I would have thought the (surely obvious) solution to this problem would
have been personalised cards. But instead the parliament is introducing
weighing scales set into the seat so that the votes will not be counted
unless the weight of whoever is sitting there matches that of the MP whose
seat it is.

The risks of the initial design are obvious. There appears to have been
absolutely no consideration of security or checking whatsoever. The risks of
the "solution" are more interesting, including the possibility of preventing
someone voting in the afternoon by making sure they have a large lunch!


Pope loves Internet, but wants "anti-depravity regulation"

<Declan McCullagh <declan@well.com>>
Tue, 22 Jan 2002 14:11:58 -0800 (PST)

Pope John Paul says that the Internet caters to the best and worst of human
nature and needs regulation to stop depravity flooding cyberspace.  He
warned that while it offered access to immense knowledge, the Internet did
not necessarily provide wisdom and could easily be perverted to demean human
dignity.  ``Despite its enormous potential for good, some of the degrading
and damaging ways the Internet can be used are already obvious to all.
Public authorities surely have a responsibility to guarantee that this
marvelous instrument serves the common good and does not become a source of
harm.''  Although the Pope does not have an e-mail address, the Vatican has
an active Web site (www.vatican.va) and the Church is reportedly searching
for a patron saint of Internet users.
  [Source: Pope Says Internet 'Wonderful' but Needs Regulating, by Crispian
  Balmer 22 Jan 2002, via Reuters; PGN-ed after DM's snipping]
  http://dailynews.yahoo.com/htx/nm/20020122/wr/pope_internet_dc_1.html


Unshredders

<"Peter G. Neumann" <neumann@csl.sri.com>>
Tue, 22 Jan 2002 9:27:13 PST

The recent Enron/Anderson shredding frenzies suggest that it is time for
UNSHREDDING software tools to come out of the closet.  It is certainly
feasible to restore a boxful of shreds, particularly for ordinary
course-grain linear shredders.  The effort for cross-cut shredders would be
significantly more difficult, but still possible -- although probably less
acceptable in court.  Anything with some natural language or graphical
context is likely to be recoverable, using digram, trigram, etc., statistics
for the likely linguistic base(s) and other context.  However, in general,
it is probably easier to start out with backup tapes and incompletely
deleted disks.  Easiest of all would be to install scanners and transmitters
(or local storage) in the shredder mechanisms, because that would capture
precisely the interesting materials deemed worth shredding.

  There once was a swindler named Fred
  Whose enterprise went in the red.
  The lawmen he dreaded,
  So papers were shredded,
  And off to the races he fled.


Newspaper archives

<"Roger Needham" <needham@microsoft.com>>
Tue, 22 Jan 2002 07:52:55 -0800

It is a principle in many jurisdictions that a jury should not know about
prior charges or convictions of the accused.  In a Scottish court a man was
accused of a particularly revolting crime, he having been acquitted of a
similar offence on a technicality a number of years ago.  The judge ruled
that the editor of a newspaper was in contempt of court by leaving reports
of the earlier trial on line in his archive, because he had made it too easy
for jurors to find out what they were not meant to know.  The judge
apparently believed that the greater ease of access of the on line archive
as compared to a paper archive was a difference not of degree but of kind.

Roger Needham


Virginia county recalls student laptops

<"NewsScan" <newsscan@newsscan.com>>
Mon, 21 Jan 2002 09:07:30 -0700

Henrico County, Va. school officials are recalling all 11,000 laptop
computers that it distributed to its high school students in order to
retrofit them with security software that will prevent students from using
the devices for accessing pornography or changing their grades -- abuses
that reportedly have occurred since the machines were handed out last fall.
Game and music downloading capabilities will also be eliminated or heavily
restricted and instant messaging will be limited to home use. Teachers have
complained that in-class use of entertainment file-sharing and messaging are
disruptive. (AP/*Wall Street Journal*, 20 Jan 2002; NewsScan Daily, 21 Jan
2002) http://interactive.wsj.com/articles/SB1011563803808773240.htm


Software uncovers e-mail untruths

<"NewsScan" <newsscan@newsscan.com>>
Mon, 21 Jan 2002 09:07:30 -0700

SAS Institute has developed software that it says can sift through e-mails
and other electronic text to discern falsehoods. "The patterns in people's
language change when they are uncertain or lying," says Peter Dorrington,
business solutions manager at SAS. "We can compare basic patterns in words
and grammatical structures versus benchmarks to detect likely lies." For
instance, over-use of the word "or" and too many adjectives can be
giveaways, according to Aldert Vrij's book, "Detecting Lies and Deceit."
SAS says its software can also be used to detect inaccuracies in resumes and
job applications.  (*Financial Times*, 20 Jan 2002; NewsScan Daily, 21 Jan
2002)  http://news.ft.com/news/industries/internet&e-commerce

  [Risks?  What risks?  PGN]


Georgia Tech anti-cheating software

<Walter Roberson <roberson@ibd.nrc.ca>>
Sun, 20 Jan 2002 16:18:14 -0600 (CST)

http://fyi.cnn.com/2002/fyi/teachers.ednews/01/17/cheating.software.ap/index.html

A recent CNN article describes a computer program that Georgia Tech
has employed to detect cheating in its "Introduction to Computing"
and "Object Oriented Programming" programming courses. 186 possible
violations were found (over ~1700 enrolled students.)

I found this paragraph particularly interesting:

  But for the most part, the degree of similarity that this program is
  looking for -- the commas are in the same place, the semicolons are in the
  same place, the spacing is the same, they've made the same mistakes -- the
  only explanation, and what most students will eventually concede, is they
  actually did it," Eislet says.

It seems to me that placement of commas, semicolons and spacing would tend
to be the same for the more experienced programmers who have adopted coding
standards -- or for anyone who runs their program through a "code
beautifier". (Unless perhaps Eislet was referring to the -comments- rather
than the code!)

I gather from my readings and discussions with teachers of introductory
programming classes, that, year after year, beginning programmers tend to
make the same -kind- of mistakes. Gross syntactic mistakes are rejected by
compilers, and modern compilers that would be used in teaching environments
usually remark on error markers such as using assignment instead of
comparison in an "if" statement; or use of a variable before it is
initialized. This filtering that takes place in the compiler would tend to
concentrate the errors more and more into common problem areas such as
incorrect handling of boundary conditions, and failure to test return codes
on I/O operations and library calls, so coding errors are -not- likely to be
uniformly randomly distributed.

I would also note that every submitted program is being compared to every
other submitted program for the same class, as "cheating" is pair-wise, not
something that is in reference to an absolute standard.  Any-time you have
pairwise interactions, the number of pairs goes up as the square of the
number of samples. If the marker variables are discrete and are limited in
range, then one encounters "the birthday paradox", wherein it takes an
unexpectedly small number of samples in order to find -some- pairwise match.
My calculation is that the probability of an accidental match would have to
be less than 1 in 721292 in order for there to be less than a 50% chance
that the program will deem at least two innocent students in a class of 1000
to have copied from each other.

Considering that Eislet is quoted as saying that for a match, "the only
explanation" is that the students cheated, I would have to question whether
the program authors undertook a proper statistical analysis.


Anthrax mail irradiation can affect electronic devices in postal mail

<Thomas Dzubin <dzubint@vcn.bc.ca>>
Tue, 8 Jan 2002 09:05:18 -0800 (PST)

Story at: http://uk.news.yahoo.com/020108/80/cnoy6.html

"Compact flash memory cards used to store data on many name-brand digital
cameras and handheld computers face not just data loss but become entirely
inoperable when subjected to electron beam irradiation, the CompactFlash
Association said on Tuesday"

(I just checked the CompactFlash Association web site at
www.compactflash.org and didn't see any related news-release about
this, so I don't know how much research has gone into this assertion or
if this is a potential birth of a new "urban legend")

It does bring up an interesting technology related risk

I think most (North-American) people make the following two assumptions:
1. postal service will generally deliver anything small & non-dangerous.
 and
2. postal service doesn't alter contents of things it delivers.

When you add "technology" to either of these in isolation, there is no
problem.  However the technology-related risk here is that when you
add "technology" (irradiation & flash cards) to BOTH of these
assumptions, the result can be unexpected and damaging.

Thomas Dzubin  Network Analyst & PDP-11 enthusiast
Vancouver, Saskatoon, or Calgary  CANADA


Health insurer computer changes delay payments...

<Don Mackie <donald@iconz.co.nz>>
Sun, 20 Jan 02 11:19:06 +1300

Southern Cross Healthcare, New Zealand's largest health insurer, bought out
Aetna locally. At the time, acquisition of Aetna's patient and practitioner
database was one of the Southern Cross's goals. Since before Christmas
Southern Cross has run into increasing delays in paying claims.  This has
caused cash flow difficulties for some private hospitals.  Southern Cross
published ads saying it was all due to difficulties with their new computer
system. More recent articles tell us the predictable story - that the
transition to a different system has, once again, been poorly handled.

  http://www.stuff.co.nz/inl/index/0,1008,1073278a11,FF.html
  http://www.stuff.co.nz/inl/index/0,1008,1073362a1896,FF.html


Excel cut-and-pasting behaviour

<Geoffrey Brent <g.brent@student.unsw.edu.au>>
Fri, 18 Jan 2002 14:52:51 +1100

Some time back, I was doing work that involved a lot of cut-and-pasting data
between Excel files. Open source file, select cells, Ctrl-C, select
destination file, Ctrl-V, repeat for dozens of source files.

I got tired of having lots of source files open at once, so I changed this
slightly: open source file, select cells, Ctrl-C, close source file, select
destination file, Ctrl-V, repeat.

At first this looked like it was accomplishing exactly the same thing, with
exactly the same numbers appearing in the target cells, but when I tried
further processing of the data (examining differences between adjacent
cells) it became obvious that something was wrong - the results were much
too 'grainy'.

Eventually I discovered the cause of the problem. When pasting from an open
file, Excel correctly pastes the full contents of the selected cells. But if
the source file is closed before pasting, it does not paste the full
contents - only the *displayed* contents. The result of this is to
automatically round pasted data at the display precision (so with a
precision of two decimal places, a value of 1.59835 would be pasted as
1.59835 from an open file, but as 1.60 if the file was closed before
pasting.)  And because the rounding precision here _is_ the display
precision, the pasted data looks correct until you change the precision to
examine it...

Fortunately, the display precision I was using was low enough to make for
very large errors, so it was obvious that there was a problem. At a slightly
higher precision, I could quite easily have ended up with significant but
non-obvious errors.

The risk here: one operation with two modes of behaviour that _look_
identical, but aren't.

Geoffrey Brent


Lotus Notes silently losing data

<Erling Kristiansen <ekristia@xs4all.nl>>
Fri, 11 Jan 2002 21:19:14 +0100

I have experienced several, apparently unrelated, incidents where Lotus
Notes is quietly losing data.

* I printed a mail message before I sent it. Some of the cc: addresses were
quietly and permanently removed. (Did anybody say buffer overflow recently?
Maybe it is more like buffer truncation, but certainly member of the same
family)

* Trying to reply to a mail I received, I discovered that 3 out of the about
10 cc: addresses in the incoming message had been truncated, rendering them
invalid. No addresses were lost completely, but the amount of truncation
that occurred suggests that a short address might be "truncated into
extinction" if it is in the right place in the list of addresses. I checked
the original RFC-822 header that is accessible.  It was correct.

By the way, correcting the addresses in place and re-sending had a very
strange effect: The corrected addresses, and only those, were turned into an
X.400-like address with a number of attributes pointing to my local
environment. I had to remove and re-type the "sick" addresses to have them
accepted.

* I copied and pasted about 100 addresses from a spreadsheet into the bcc:
field of a mail. Everything looked OK, the pasted addresses appeared neatly
in the address window, I could scroll through them, etc.  But the message
was only sent to the first address. No warning of any kind appeared that a
good hundred addresses had been discarded. I only discovered the error
because I had asked for delivery notification, and got very few. Had I not
discovered this, only a handful of people would have been invited to a
presentation. (there were a few other addressees that had not been pasted in
- those worked OK even though some were entered AFTER the skipped
addresses).

* Notes allows you to format messages, with facilities more or less
equivalent to an HTML editor. If a message is sent outside the Notes domain,
ALL formatting is removed, even things like indentation and paragraph
numbers. So a nicely formatted message may become rather unreadable, even
ambiguous (indentation may imply a lot about the meaning of a text). No
warning is given that formatting information is being removed.

The RISK of all this is that Notes accepts instructions to do something,
does not complain about the input, and then goes ahead and does something
else than what could reasonably be expected. You can obviously check for any
of these events, but they are rare enough, and different enough, that you
don't really know when to expect a problem, and what to look for in order to
make sure everything went as expected.

Erling Kristiansen


Woman says telephone makes unsolicited calls

<Carl Fink <carl@fink.to>>
Fri, 18 Jan 2002 13:17:49 -0500

According to the *Detroit News*, Becky Sivek doesn't even have long distance
service.  Nevertheless, "thousands" of long distance calls all over the USA
are being made.  The calls disconnect as soon as someone picks up.  Some
people are getting this same call dozens of times a day.

Although Sivek isn't making the calls, and they don't appear on her bill,
caller ID shows her number, meaning that she's now getting many angry and/or
threatening calls from people demanding she stop harassing them.

Phone phreaks, maybe?

  http://www.detnews.com/2002/metro/0201/18/d06d-393292.htm

Carl Fink, I-Con's Science and Technology Programming  http://www.iconsf.org/


Answering machine provides door entry code

<Benjamin Elijah Griffin <eli@panix.com>>
Mon, 21 Jan 2002 14:32:33 -0500 (EST)

On a recent Sunday, walking past an office building in my area a woman asked
me for help getting into the building. She explained she had an appointment
with a tenant in the building but couldn't get in. She had dialed the
company's extension on an outside phone and gotten a recorded message to
'enter #2000 to come in, if you have an appointment'. The phone used '##' to
hang up calls, and it was the number of #s required that caused the problem
for the woman, but I find it baffling that an answering machine is
considered acceptable weekend security.


Microsoft using predictable passwords for Passport?

<Rodger Donaldson <rodgerd@diaspora.gen.nz>>
Sun, 20 Jan 2002 09:03:01 +1300

An organisation I am familiar with has a Microsoft support contract for the
Microsoft components of their infrastructure; in order to access Microsoft's
on-line resources, a Passport account is required.  Microsoft has allocated
the company a Passport account, with a numeric login whose password is set
to the surname of their primary contact in the company.

The risk?  This is a totally predictable scheme.  It would be trivial to
scan the numeric Passport logins looking for passwords set to common
surnames.

Rodger Donaldson <rodgerd@diaspora.gen.nz>


Re: Other blunders (La Fetra, RISKS-21.86)

<brett@benders.net>
Thu, 10 Jan 2002 14:03:29 -0600

In RISKS-21.86, Skip La Fetra ('Other blunders on "secure" Web sites')
claims that request parameters contained in a URL are not protected
(encrypted) when the request is sent via a HTTPS GET.

This is a misunderstanding regarding the actual risk of using the GET method
instead of the POST method. The traffic in an HTTPS session is always
encrypted, whether the GET or POST method is used. However, use of the GET
method encodes the parameters (including e.g. credit card numbers) into the
request URL.  This exposes such info in your browser history and in the site
logs of the web server (rendering it vulnerable to the electronic equivalent
of 'dumpster diving') -- the info is not, however, transmitted in cleartext.


Re: Kaiser Permanente exposes medical record numbers

<"George C. Kaplan" <gckaplan@ack.berkeley.edu>>
Thu, 10 Jan 2002 13:48:35 -0800

j debert <jdebert@garlic.com> writes in RISKS 21.86

> Kaiser Permanente has a Web site for members at http://www.kponline.org/ .
>
> The first page here is the signon page, where one enters a medical record
> number and their region to enter the site.
>
> A statement concerning online security ... indicates in the first
> paragraph that the medical record number will be sent via SSL:
> ...
> However no SSL connection is possible. Every attempt to obtain a secure
> connection gets redirected to the non-secure page.

It's not *quite* this bad.  True, if you try to go to
https:/www.kponline.org, you invariably get redirected back to the
unprotected page.  However, the ACTION part of the sign-on form points
to https://kponline.kp.org/signon/signonmember, which is SSL-protected.
All further interaction with the Kaiser site after signing on appears
to be through SSL via kponline.kp.org.

But they make the same mistake mentioned by Skip La Fetra earlier in the
same RISKS digest: the medical record number is transmitted in the URL.  So
Kaiser's claim is incorrect; the medical record number is not protected by
SSL.

Once you've registered, you need a PIN to sign-on, and that *is* sent via
SSL, so the PIN and the rest of your session apper to be reasonably well
protected.  But in order to *get* a PIN, the only "authentication" data
required (besides the record number) is your full name.

I guess if you're a Kaiser member you should register on this site before
someone else does it for you.

George C. Kaplan, Communication & Network Services
University of California at Berkeley  1-510-643-0496 gckaplan@ack.berkeley.edu


Re: Bogus dates for McAfee virus alerts (Colburn, RISKS-21.85)

<David Blakey <djb@poboxes.com>>
Tue, 08 Jan 2002 11:33:43 +1300

This is familiar to Web designers, and should be known by someone like McAfee.

First, many people have JavaScript turned off.  If the script is not going
to be completed, then the designer should have more sense than to write out
the "This page current as of ".  This should be included in the script as
well, so that people with JavaScript turned off will not see anything at all.

Second,  the JavaScript date may be presented by a source that is
unreliable - such as the client's system date - or unsupported - such as
"date modified" in some browsers.

The site seems to lack a good "sniffer" to find out (1) if JavaScript is on
and (2) if the "date modified" function is supported.  There is little risk
presented by this site, but one wonders if the people who designed it have
since moved on to emergency services or air traffic or defence sites.


Re: AOL's spam filters (Burstein, RISKS-21.85)

<"Jay Levitt" <jay@jay.fm>>
Sat, 19 Jan 2002 21:59:26 -0500

> Also note that a "bounce" message would take this whole saga out of the
> "risks" venue (or at least move it to the margin).

Would that that were true, but bouncing spam merely introduces new risks.
I was intimately involved in AOL's mail system for most of the past decade,
and our motto was It's Not That Simple.

AOL hasn't always had spam filters.  Years ago, we would see huge numbers
of bounce messages generated for spam runs, since spammers often send to e-
mail addresses that are no longer valid.  One spammer actually sued us for
delivering his bounces back to him - he said we were trying to overload his
small mail server!  (Apparently the huge volume crashed it.)  And once
spammers started forging return addresses, these bounces began causing no
end of trouble for the poor site that found itself receiving millions of
undeliverable e-mail reports from AOL.  Additionally, we had to make sure
that these huge queues of bounce e-mails didn't interfere with the delivery
of legitimate communications, or even bounces of legitimate communications.
Far from taking minutes to deliver, these bounce queues can quickly back up
to infinity without constant babysitting.

With SMTP, if you can detect that a message is undeliverable early enough
in the process, you can simply refuse it, rather than bounce it back.  But
that presumes that the machine sending to you is the originator of the
message.  Spammers often relay their e-mail off unsuspecting third-party
mail servers that are configured to accept mail from anywhere and deliver
it to anywhere. (This was the default configuration of all mail servers
until just a few years ago; remember, the Internet began as a cooperative
effort.)  If you refuse mail from a third-party relay, THEY then have to
deliver the bounce messages, which again can crash or hobble their systems.

Of course, if you simply turn off spam filters on a system as target-rich
as AOL, you're left with a fairly useless mail system - we've often
estimated that 30-50% of all the incoming messages are spam.

I've since left AOL, but I know that the folks there were doing everything
they could to detect spam as early in the transaction as possible, and
refusing it rather than bouncing it whenever they could.

The real risk is taking a protocol designed to cooperatively exchange
messages within a small community, and using it for worldwide, mission-
critical communications, sometimes from hostile senders.  The rest is
imperfect band-aids.


Call for Participation Open Source Software Development Workshop

<Cliff Jones <cliff.jones@ncl.ac.uk>>
Sun, 20 Jan 2002 17:29:17 +0000

WORKSHOP ON OPEN SOURCE SOFTWARE DEVELOPMENT, 25-26 FEBRUARY 2002
                 Newcastle upon Tyne, UK
     http://www.dirc.org.uk/events/ossdw/main.html

The focus of the Open Source Software Development workshop is on
dependability and open-source software development. Dependability is a
deliberately broad term which, among others, covers reliability, security,
safety and availability.

We have put together an exciting programme and would welcome further
participation from the community. Participation would be particularly
welcomed from any of those engaged in, or affected by, the design,
development or operation of open source software. An important objective of
this workshop is a greatly improved understanding of the complete
organisational and cultural context of complex systems of which computers
are a part. To this end, we especially encourage participation from
interdisciplinary researchers and practitioners, since we believe that such
research is crucial for progress towards the safe deployment of new
technologies.

Those interested in participating in this event should send an e-mail
stating their interest to Cristina.Gacek@ncl.ac.uk, preferably by 15th
February 2002.

  Cristina Gacek, Centre for Software Reliability (Bedson Building)
  Department of Computing Science, University of Newcastle upon Tyne
  NE1 7RU  -  United Kingdom    Telephone: (44 191) 222 5153
  FAX: (44 191) 222 8788  cristina.gacek@ncl.ac.uk

Please report problems with the web pages to the maintainer

Top