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 30

Monday 26 March 2001


Electronic tax filing problems blamed on 'user error'
Cyber surfers caught by fishing nets
Tin Tin
RISKS of rodent teeth
Gregory Soo
Identity Theft -- a personal experience
name withheld
Re: California Drivers License as ID for banks
John McCalpin
Re: "Internet Voting is no 'Magic Ballot'"
Douglas W. Jones
Verisign certificates problem
Roy Sinclair
When security is based on trust
Michael Sinz
Re: Aasta train crash ... safety-critical error
Tor-Einar Jarnbjo
Dave Aronson
IEEE *Software* Special Issue on Building Software Securely
Anup Ghosh
Info on RISKS (comp.risks)

Electronic tax filing problems blamed on 'user error'

<"Peter G. Neumann" <>>
Fri, 23 Mar 2001 16:18:47 PST

Thousands of electronically filed tax forms are being rejected by the IRS.
Apparently that new software may be to blame.  The new system requires a
five-digit PIN (which is used as ``an electronic signature''!!!).  Taxpayers
are also required to provide the adjusted gross income and total tax from
the previous year's filing.  As a result, Intuit and H&R Block are both
reporting 20% rejection rates on electronic returns, blamed on ``user
confusion''.  The IRS expects 42 million electronic returns this year -- 70%
of all returns.  [Source: an UNDATED item at somewhen earlier in
March 2001; PGN-ed.]
  [Typo in March date fixed in archive copy.
  Added note: The 70% figure seems BOGUS.  PGN]

Cyber surfers caught by fishing nets

<Tin Tin <>>
Thu, 22 Mar 2001 15:20:56 -0800

>From :

Cyber surfers caught by fishing nets, AFP, 22 Mar 2001

China's Internet links with the US are threatened by the anchor nets used by
the country's fishing industry.  *The Shanghai Daily* reported on 21 Mar
2001 that fishing equipment had snagged underwater cables off the coast of
Shanghai three times in the past two months, causing havoc for millions of
Net surfers. And officials fear the problem could worsen, the paper said.
China's main fishing season has just begun and industry officials say they
lack sufficient legal power to stop further damage, the report added.

The problem centres on a type of fishing net developed in South Korea that
uses anchors sunk into the seabed.  Strong tides can drag the anchors --
which are sunk lower into the seabed than Internet cables, for distances of
up to 8km -- severing communications links.

Anchor nets are due to be phased out by 2006, but China's Ministry of the
Information Industry and the Ministry of Agriculture, which regulate the
Internet and fishing industry, are still working on an interim solution.
For the next three months, however, authorities in Shanghai can do little
but increase patrol boats in the cable areas to warn fishermen away, and
industry officials warn that may not be sufficient to prevent a severe
breakdown in communications.

The first serious break occurred on 9 Feb 2001 about 370km off China's
coast, severing the main Internet link between China and the US.  Although
communications were partially restored during a repair process that
stretched over two weeks, 22.5 million customers, including many in
Shanghai, suffered slow service, the paper reported.  On 9 Mar, the
Internet backbone linking Taiwan and Shanghai was cut by a fishing net about
120km south of the city, affecting four million users.

When that split was finally repaired on 19 Mar, authorities found another
break in the undersea cable that will disrupt Internet services for a
further two weeks.  Each break costs about six million UN ($1.4 million) to
repair, in addition to unknown business losses resulting from the Internet

RISKS of rodent teeth (Re: Soo, RISKS-21.27)

<"Gregory Soo hotmail" <>>
Sat, 24 Mar 2001 18:08:55 -0500

The saga continues strangely: a rodent chewed through cable that had been
exposed while Canadian National Railway workers were repairing the cut
caused by the would-be copper thieves (noted in RISKS-21.27).  This
disrupted service to about 300,000 customers in Ontario's Niagara region,
including Sprint Canada and AT&T.

[Source: Animal takes byte out of Rogers, Steve Erwin, The Canadian Press,
24 Mar 2001]

Identity Theft -- a personal experience (from IP)

<[Identity withheld]>
Mon, 26 Mar 2001 13:53:40 -0500

  [Contributed by an unidentified individual to Dave Farber's IP list,
   For IP archives see: .  PGN]

The following happened to a colleague. About a year ago he signed up for a
membership at a video rental store.  The form had a place for social
security number and he made the mistake of filling it in.  About three
months later there was a message on his answerer from a bank with which he
did not have an account asking about an overdraft. Upon calling he
discovered that there was an account in his name with his ss number but with
a different address. On calling and writing to the various credit bureaus,
he discovered that there had been numerous queries about his
creditworthiness. He then contacted each of these and discovered that there
had been many credit cards issued in his name as well as a variety of
wireless phone accounts. He called each of these in turn and got letters
from the credit bureaus but could not be sure that the matter had ended.

The accounts/credit cards were in states other than his but police in those
communities were not responsive to complaints.  Fortunately, a friend worked
in a state attorney general office and he made a call to a local official in
the area where the perpetrators seemed to be based.  In addition, quite by
accident a local house was raided for drugs.  Fortunately, one of the police
in the raid remembered my colleague's name so when they discovered a
collection of driver's licenses from a variety of states, as well as credit
cards and other account info, in my colleague's name, he was able to put it
all together.  There were also cards and licenses for others.  The
perpetrators pled and got some jail time...  probably more because of the
drugs than the identity thefts and fraud.

All of this involved an incredible number of hours and associated
aggravation to track down and fix the problem.  And resolving it quickly
depended on having a well placed connection and a good deal of luck.

The lesson is that we are all vulnerable. Just a ss number is enough to get
a fraud going.  AND There is no privacy wrt ss numbers. For example, at many
universities the ss number is the same as the student ID...and appears on
class rosters sent to departments and faculty.

Re: California Drivers License as ID for banks (Cornell, RISKS-21.29)

<John McCalpin <>>
Fri, 23 Mar 2001 15:22:06 -0600

There is nothing new about this scam -- the new law just allows the bank to
disclaim financial responsibility for the loss.

I was hit by this exact scam in Texas in 1979. After some telephone calls,
the bank covered the loss and I never heard about it again.  I am not
surprised that the banking industry would make an effort to get legal
protection so they could share the pain.

For those inclined to law-breaking, this scam seems like a really easy
way to steal money....

John D. McCalpin, Ph.D. 
Senior Scientist           IBM POWER Microprocessor Development

Re: "Internet Voting is no 'Magic Ballot'"

<"Douglas W. Jones" <>>
Wed, 21 Mar 2001 15:31:22 -0600

First, I wish people would stop talking about Internet voting as if it was a
completely different animal.  It isn't.  Traditional absentee voting and
vote by mail are also done from the home, raising problems of difficult
voter authentication and insecure ballot transmission.  Direct recording
voting machines and precinct-count mark-sense and punched-card ballot
systems also use computers and many now offer transmission of totals over
public telecommunications systems (frequently phone and radio).  We should
address these risks across the board!  The way things are going, I'm afraid
we'll end up quite properly stamping out the threat of immediate Internet
voting while leaving the significant flaws of these other voting systems
largely un-addressed!

We should treat Internet voting as direct recording absentee voting using
electronic communication of ballots and vote totals, and we should address
the threats it raises by fixing the laws regarding absentee voting, direct
recording voting systems and use of electronic communication in elections!
Yes, the Internet does introduce some new problems, but these other problems
are far, far broader!

Second, I have been involved with certification testing of DRE machines, and
I've found that it is extremely difficult!  With mark-sense and punched card
systems, you prepare a test deck or a test ballot stack, and then run those
ballots through the system, checking to see that the totals reflect your
test.  You can hand-count your test deck and arrange all the votes to come
up in easy to recognize patterns in the final total.

In contract, with DRE systems, you have to stand there in front of the
machine doing a repetitive and mind-numbing exercise, entering ballot after
ballot into the machine.  After a few ballots, your mind begins to wander.
After a few tens of ballots, your fingers are sore from pushing buttons or
tapping the screen, and by the end of your test, you've made so many
mistakes that the numbers are meaningless.

A voter casts only one ballot, and for the voter, the voting experience is a
peak moment.  I've concluded that DRE machines are extremely difficult to
test because of this!  Hundreds of volunteers (or paid experimental
subjects) might be able to run a good test, but even then, they'd be
required to vote from a sheet of paper instructing them what candidates to
select in order to follow the test plan.  Alternatively, the hundreds of
voters could be closely observed (perhaps by discretely hidden video
cameras), in order to observe how they vote and then compare this to the
election result.

The FEC's "voluntary" standards suggest a button-pushing robot to perform
such tests, but for accurate testing, this would need a functioning vision
system so it reacts to the feedback provided by the machine.

In sum, I've concluded that the accuracy of DRE machines is extremely
hard to assess -- so much so that I don't see any reason to trust the
assessments that have been made, whether they're positive or negative!

Douglas W. Jones <>

Verisign certificates problem

<"Sinclair, Roy" <RCSinclair@CESSNA.TEXTRON.COM>>
Fri, 23 Mar 2001 09:30:54 -0600

  Via both Mike Hogsett and Dave Stringer-Calvert.  TNX. PGN]

Some information regarding Verisign Certificates that has come out of this
fiasco is quite disturbing but has been under reported and may have been
missed by many in the security business.

Pay close attention to this paragraph from the Frequently Asked Questions
part of

"The update is needed because of a characteristic of VeriSign code-signing
certificates. Every certificate issuer periodically generates a Certificate
Revocation List (CRL), which lists all the certificates that should be
considered invalid. A field in every certificate should indicate the CRL
Distribution Point (CDP) - the location from which the CRL can be obtained.
The problem is that VeriSign code-signing certificates leave the CDP
information blank. As a result, even though VeriSign has added these two
certificates to its current CRL, it's not possible for systems to
automatically download and check it. "
The first question I have after seeing that is how many of the rest of the
500,000 certificates that Verisign says they have issued also do not have
this CRL Distribution Point field properly filled in.  In the lack of any
information to the contrary I would hazard to guess that it's probably that
none of the 500,000 certificates issued by Verisign have supplied the
information that should be in this field.  If this is truly the case then we
have yet another problem of much wider scope than the improper issuance of
two certificates, there are a great number of valid certificates which could
be stolen or misused and even if Verisign were to add them to their CRL the
certificates themselves don't point to the CRL so they won't be properly
Two things need to be done, one is that software which checks certificates
must be changed to warn users that certificates lacking a CRL are much more
suspect and Verisign needs to re-place all certificates that currently lack
this critical information with new certificates that have this field
properly filled in.
Additional questions that come to mind is how many other certifying agencies
have also failed to fill in the information in this field and what
percentage of the certificates being used today are unverifiable?

When security is based on trust

<Michael Sinz <>>
Thu, 22 Mar 2001 15:30:32 -0500

So, lets see - Microsoft says that ActiveX is secure as long as the software
(ActiveX thing) is not from an "evil" source.  To prevent bad software from
being used, they use digital signatures to identify the person or company
who made the software such that you could either trust them or know who to
go after when it does something bad.  The OS and system infrastructure does
not try to enforce anything other than to check these certificates and warn
you based on your settings as to if you want to run unsigned software or any
software signed by company "X" or a number of other possible combinations of

There is no built in security beyond that point.  Once you say "Yes, run it"
you are opening up your system to complete control by the ActiveX control.

Ok, in a perfect world, with no one wishing to do harm or rob you blind,
such a mechanism would work just fine.  The Internet is not such a world.

And now, to put this into even brighter "this is not the right way to do
things" light, Microsoft says that you can not even trust that software that
says it is from Microsoft really is from Microsoft unless you first check
the dates on the digital signature and remember that if it is Jan 29 or 30,
2001, that it is most likely not really Microsoft and you should not accept

What do people do now?  If you accept anything from Microsoft, it is too
late.  If you ask for confirmation before running, what are the chances you
would even think to look at the dates once you see "Microsoft" as the
signing party?

All of this really goes to show that security must be done at the start and
not just "added in" by saying "make sure you trust the author".  Even if you
trust the author, there could be bugs.  And, as this example shows, you can
not even always trust you know who the author is.

Time to think this though some more...,4586,5079987,00.html?chkpt=zdhpnews01

Re: Aasta train crash ... safety-critical error (Setzer, RISKS-21.28)

<Tor-Einar Jarnbjo <>>
Fri, 23 Mar 2001 04:39:34 +0100

As Anton Setzer is speculating about certain things which obviously are
discussed only in the Norwegian part of the report, I think I will be able
to clarify a few points and bring some details not mentioned by him.

Actually, the train-controlling system warned only about a malfunction of
the set of points at the northern exit of Rustad station, caused by the
northbound train forcing it open when driving out of the station.  The
warning was issued as a static text line with 16mm (0.6") high red letters
at the bottom of the monitor. There was no sound signal or flashing
light/text to get the train controller's attention. The warning was issued
at 13:09:28 and as he was currently occupied with another train line
displayed on another monitor, he didn't notice the situation before some
time between 13:10:54 and 13:11:58. The report states, that the train
controller can not be held responsible for overseeing the warning for 90-150

The mobile-phone numbers had been reported by both train drivers to the
train-controlling central, but the train controller on duty earlier the same
day hadn't written down the numbers where he was supposed to. It was also a
relatively new situation that the phone numbers had to be reported to the
train controlling central. Up until a few months before the accident, the
railway company had been using a UPT service (like British 0700-numbers)
making it possible to call a train using a (fictive) number like 0700 123
<train number>. As this service had been canceled by the operator Telenor,
all train drivers had to call the train controlling central and report their
train number and the corresponding mobile phone number.

The report states that it is highly unlikely that the exit signal for the
northbound train was green, but it might have happened, that either the red
signal disappeared (no signal showing) or that it switched to green for 3-5
seconds. The reason for this is, that the security system in NSB87 which is
supposed to make it impossible for the train controller to issue a green
signal on both sides of a track segment operates independent of the main
system and may actually take a few seconds to "discover" the failure and
then do something about it. The older NSI63 signalling system operates with
mechanical safety relais which should make it physically impossible, that a
green signal is shown on both sides of a track segment. But, there are no
commands logged from the train controller where he tries to issue a green
signal to the northbound train, and there is no reason to assume that the
exit signal switched to green and was corrected by the security system.

The northbound train started according to the train's "black box" 13:07:17
and passed exit signal according to the train control central log
13:07:58. Time enough for the train driver to notice that the signal had
switched back to red.

To clarify the situation a little bit:

The accident happened between Rustad station (on the south side) and Rena
station (on the north side). The two trains were supposed to cross at Rustad
station, but it is discussed in the report if it is likely to believe that
the train driver of the northbound train had reason to believe that the
crossing had been moved to Rena station. The southbound train was already
delayed and the northbound train would also have been delayed if it was
supposed to wait for the southbound train at Rustad.  But, the train
controller had decided to let the trains cross at Rustad as planned, since a
crossing at Rena would have caused further delay to the southbound train and
also would have caused a connecting train from Hamar to Oslo to be
delayed. It is also thoroughly discussed and concluded that neither the
driver nor the conductor of the northbound train could have been aware that
the southbound train was delayed by about 10 minutes.

But, as the report states, the train driver of the northbound train seemed
to suppose that the crossing was moved to Rena for the following reasons:

* When stopping at Rustad, he did not drive far enough into the station area
to let a crossing train drive through the station. Because he stopped the
train so far south, the main track behind him had not yet been "cleared" and
the south exit signal of the crossing track showed red.

* The train log shows sign of the train driver being "in a hurry". He held a
higher speed than normal when approaching the station, and the train
normally only stops at the station "on demand". It is clear that noone left
the train at Rustad station, and the train driver might have been prepared
to drive through without stopping if it had not been for a passenger waiting
for the train at the station.

* The train left Rustad 13:07:17 after a halt of only 15-20 seconds,
although it according to the time table is not supposed to leave until
13:10. The train driver was known to be a very correct person and his
watch was found after the accident still going, only 12 seconds off
correct time.

>- It might be that a train drives over a red light while running. In the
>  situation in question however, the local train was waiting at a station,
>  and when waiting in front of a red light, it is unlikely to drive over it.

That is also what the report concludes. It might happen that a train driver
oversees a red signal from a running train, but it is extremely unlikely
that a train driver on purpose starts from a station and passes a red signal
on purpose when he is certain, that the track in front of him is not
clear. The possibility of the train driver committing suicide is discussed
in the report, but the conclusion is that his emotional imbalance would have
caused noticeable changes in his behaviour and driving pattern. His
conversation with the train controller had been recorded and both this and
the train log have been evaluated by a psychologist.

The southbound train left Rena about 45 seconds before the northbound train
left Rustad. I don't think the report mention anything about a relation
between the two times.

>From this I conclude that the following scenario might have happened [...]

This should not happen. Normal procedure when leaving a station is the

* The train driver notifies the conductor about the green exit signal.  The
green exit signal is only a sign that the train is allowed to leave the
station and is not to be considered as a "leave now" order from the train
controller. If the track is free, the exit signal is green already when the
train enters the station.

* The conductor is after he has been notified by the train driver that the
exit light is green responsible to be sure that all passengers have left and
entered the train and that the departure time has been reached before
signalling the train driver to leave.

This makes it reasonable to believe that both the train driver and also the
conductor agreed on leaving almost 3 minutes before the time table.  The
report does not find any reason why that should have happened.

The report ruled out [various concluding] possibilities [suggested by
Setzer], with a high degree of probability.

Tor-Einar Jarnbjo

  [PGN removed or abridged most of the interstitiated text from Anton.]

Re: Aasta train crash ... safety-critical error (Setzer, RISKS-21.28)

<Dave Aronson <>>
Wed, 21 Mar 2001 12:18:11 GMT

Were it in the USA, I'd also suspect the driver may have been using drugs
and alcohol.  All in all, though, the only RISK worse than having a human
make such decisions is not having a human make such decisions.  (With
apologies to Oscar Wilde.)

Dave Aronson, Sysop of AirNSun free public Fidonet BBS @ +1-703-319-0714

IEEE *Software* Special Issue on Building Software Securely

<Anup Ghosh <>>
Fri, 23 Mar 2001 16:38:00 -0500

  [Here is something that should be of vital interest to RISKS readers
  and writers alike.  PGN]

Call for Articles and Reviewers for an IEEE *Software Magazine* Special Issue
  "Software Security: Building Systems Securely from the Ground Up"

Publication: January/February 2002, Submission deadline: 1 July 2001

Fragile and insecure software continues to be a major threat to a society
increasingly reliant on complex software systems. The premise of this
special issue is that most security breaches in practice are made possible
by software flaws. We believe engineering secure and robust software systems
can break the penetrate-and-patch cycle of software releases all too common
today. A constructive exchange on this topic among software practitioners
and researchers is the focus of this special issue.

Specifically, our goal is to encourage a deeper, more fully integrated
understanding of how security concerns should influence all aspects of
software design, implementation, testing, and support. A notorious example
is the buffer overflow problem. Known for decades and very troublesome in
networked systems, it continues to be introduced into new software at an
alarming rate, due in part to software development habits that trace back to
isolated systems where such flaws had few security implications.

An important aspect of this discussion is how to balance security with the
many other characteristics of a good software system. Finally, software
designers in a networked world cannot pretend to be working in isolation.
People are a critical part of the full software security equation, and
software that makes unrealistic or unreasonable security-related demands on
users (for example, requiring them to memorize too many passwords that
change too often) will inevitably fail to keep its data secure. Articles
that address the issues of how to design software that works with and
directly supports the need for such social engineering issues are also

Topics of interest include:

- Case studies that help quantify common security risks
- Security implications of programming languages and development tools
- Techniques for balancing security with other design goals
- Extracting security requirements from software projects
- Design for security
- Developing secure applications
- Aspect-oriented programming for security
- Analyzing programs for vulnerabilities
- Testing for vulnerabilities
- Secure configuration and maintenance
- Developing trusted environments for running untrusted mobile code
- Secure mobile code programming paradigms
- Analyzing unknown software for malicious logic
- Intrusion-tolerant software architectures
- Software application-based intrusion detection
- Models and techniques for quantifying tradeoffs in adding security
  concerns during development

[... 5,400-word limit, caveats, etc.  PGN]

Guest Editors:

Anup K. Ghosh
Director of Security Research, Cigital
phone +1 703 404-9293 <>

Chuck Howell
Chief Engineer, Joint and Defense-Wide Systems Division, MITRE Corp.
phone +1 703 883-7615 <>

James Whittaker
Associate Professor of Computer Science, Florida Institute of Technology
phone +1 321-674-7638 <>

Please report problems with the web pages to the maintainer