Subject: RISKS DIGEST 13.29

Subject: RISKS DIGEST 13.29
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest Wednesday 18 March 1992 Volume 13 : Issue 29

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents:
Risks of success vs risks of failures elsewhere -- Magellan turnoff? (PGN)
Shocking news: computer models sometimes inaccurate (Jeffrey Mogul)
New RISK at Railroad Crossing Gates (Alan Marcum)
Microsoft Word 5.0 install risk (W.M. Buckley)
It has easy written all over it -- printing envelopes (Brian Kantor)
Airport door magstrip security (Mark Seecof)
ITSEC V1.2 - Observations by German GI Task Force ... (Kai Rannenberg)
FOLLOWUP: NASA hacker sentenced (Bear Giles)
Wiretapping and ISDN (Frank Heath, I.Wakeman via Olivier M.J. Crepin-Leblond)
Bugging ISDN (Torsten Lif via John Gilmore)

The RISKS Forum is moderated. Contributions should be relevant, sound, in
good taste, objective, coherent, concise, and nonrepetitious. Diversity is
welcome. CONTRIBUTIONS to [email protected], with relevant, substantive
"Subject:" line. Others may be ignored! Contributions will not be ACKed.
The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS,
especially .UUCP folks. REQUESTS please to [email protected].
Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 13, j always TWO digits). Vol i
summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1".
<CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

----------------------------------------------------------------------

Date: Tue, 17 Mar 92 9:53:49 PST
From: "Peter G. Neumann" <[email protected]>
Subject: Risks of success vs risks of failures elsewhere -- Magellan turnoff?

The lead item in this week's Talk of the Town (New Yorker, 16 Mar 1992,
pp.31-32) is a letter reporting on NASA's plan to abandon the Magellan
spacecraft (which is scientifically an enormous success and which is continuing
to produce remarkable results, far beyond original expectations), in order to
save a few million dollars. The letter makes a very compelling case for the
incremental benefits of keeping the mission going, and concludes thusly:

Given the cost of building Magellan and getting it to Venus -- about half
a billion dollars -- most of the NASA scientists think that to turn it off
prematurely is penny-wise and pound-foolish. It is the loss of a kingdom --
more than that, of a planet -- for want of a nail.

------------------------------

Date: 18 Mar 1992 1542-PST (Wednesday)
From: [email protected] (Jeffrey Mogul)
Subject: Shocking news: computer models sometimes inaccurate

E-470 hits new detour
(Mary George, Denver Post Environment Writer, Denver Post, 13 Mar 1992, Page 2B

The E-470 Public Highway Authority clocked another delay in its race to the new
Denver Airport yesterday when the company that wants to finish the $1 billion
tollway revealed it's having computer troubles.

A computer model, which seeks to forecast traffic and toll revenues, isn't yet
accurate enough to satisfy state transportation officials considering a $100
million loan for the highway, or financiers who would help bankroll 31 miles of
four-lane construction, said Ed Gorman, chief executive officer of Morrison
Knudsen, the company seeking to build the road.

The revenue forecasts and financial plans now have been delayed since February.
The delay is costing the company about $250,000 a month.

[The rest of the article is about high finance, except for this last
sentence:]

About 3,275 drivers used the existing E-470 segment daily last month, not
enough to pay for tollway operations.

[What I found interesting about this story was that the company was thwarted
not because its model didn't produce the result that the financial backers
wanted, but because they didn't trust the result. (At least, that's the
implication of the article; perhaps the model was declared "inaccurate"
simply because it doesn't forecast enough revenue.) Are public officials
and financiers finally realizing that just because a computer model says
something doesn't mean that it is so? -Jeff Mogul]

[P.S.: By the way, if they charged each of those 3275 drivers $2 each day,
it would take 418 years to pay back the $1 billion construction cost
(excluding several quintillion dollars of interest expense). JM]

------------------------------

Date: Wed, 11 Mar 92 09:46:02 PST
From: [email protected] (Alan M. Marcum - TS)
Subject: New RISK at Railroad Crossing Gates

This morning, while on my way to deliver my 19 month old son to the babysitter,
the railroad crossing gate closed. It opened shortly after that, with no train
having passed.

Now, this sounds like a completely benign failure mode, yes? Not if you have a
19 month old who LOVES trains in the car! Joshua sure got upset when no train
followed the gate's closing...

Alan M. Marcum, NeXT Technical Support [email protected]

------------------------------

Date: Tue, 17 Mar 92 11:37:47 PST
From: [email protected]
Subject: Microsoft Word 5.0 install risk

An increasing number of software manufacturers are encountering problems with
viral infections of their products. It is interesting that in an environment
where manufacturers and users are becoming more cautious, that the installation
procedure for Microsoft Word 5.0 includes directions to remove any virus
protection from your system before proceeding with the installation.

W.M. Buckley - Applications Systems Division - LLNL
(510)423-4581 [email protected]

------------------------------

Date: Wed, 18 Mar 92 07:20:58 -0800
From: [email protected] (Brian Kantor)
Subject: It has easy written all over it -- printing envelopes

On page 23 of the latest [April 1992] issue of Scientific American is a
two-page spread from Microsoft touting their "Word for Windows" product,
including a tag pointing out how easy it is to print envelopes: "Easy. We mean
REAL easy. There's an envelope command right on the screen that addresses and
prints automatically."

And indeed, the envelope shown resting on top of the sample letter in
the photo is nicely addressed, with the printing all lined up and centered.

But the address on the letter and the envelope differ - some of the digits in
the Zip Code got scrambled between the address on the letter and the address on
the envelope.

[And neither Zip Code is proper for San Diego, which is the city shown in the
address. One is in Los Angeles, and I think the other is much further north.]

What's the Risk? Financial. If you're going to advertise a feature, you
should at least make it look like it works. One can't help but wonder how much
such an error affects sales.
- Brian

------------------------------

Date: Tue, 17 Mar 92 13:28:13 -0800
From: Mark Seecof <[email protected]>
Subject: airport door magstrip security

In RISKS 13.28 Brian Randell reported a series of bank ATM robberies
involving forged magstripe cards.

On page B3 of the 17 March '92 Los Angeles Times an article by Hugo Martin
headlined "Security Upgraded At Airport" reports that Burbank airport (one of
L.A.'s smaller airports) will install an $83,000 electronic locking system to
meet FAA requirements for more stringent control of access to non-public areas.
The system will replace current key and combination locks. Airport employees
will get badges with magstripes. Doors will be unlocked by a computer when
authorized personnel swipe their cards through readers adjacent to the doors.
The system will allow for giving or revoking authorization on short notice, and
for conditioning authorization on time of day (or week, etc). "The new system
also records each employee's use of a door, allowing airport officials to
determine which employees were present in a secured area at a given time."

Risks? The usual from (IMHO) insufficiently thought-out systems. The system
will not, in fact, provide a good record of which people were in a secured area
at a given time, because the doors aren't being changed and people can pass
through them without authorization or recordation when they're opened by other
people. Also, it's easy to duplicate the magstripes on the cards. A photo
with the story suggests that a combination (passcode) could be required along
with the card (it shows a card reader with a keypad) but the story doesn't
mention if this is done.

Mark Seecof Publishing Systems Department, Los Angeles Times

------------------------------

Date: Thu, 19 Mar 1992 01:54:42 +0100
From: Kai Rannenberg <[email protected]>
Subject: ITSEC V1.2 - Observations by German GI Task Force ...

Statement of Observations concerning the
Information Technology Security Evaluation Criteria (ITSEC) V1.2

The Information Technology Security Evaluation Criteria (ITSEC) are the result
of an initiative driven by the Commission of the European Communities. Their
current version 1.2 from June 1991 is the basis for the evaluation of secure IT
systems in the EC member countries for at least until 1993.

Although the ITSEC are quite advanced compared to the TCSEC (Orange Book) and
there have been discussions on V1.0 and V1.1, a lot of several critical points
remained in V1.2, especially aspects of possible functionalities and assurance
methods.

Therefore the Data Protection and Data Security Task Force of the German
Society for Informatics (GI) decided to issue and publish a "Statement of
observations concerning the ITSEC V1.2". Observations, criticism and proposals
concentrate on the following issues:

(1) Title and Scope of ITSEC
(2) Functionality
(3) Assurance - Effectiveness
(4) Assurance - Correctness
(5) Post-Evaluation Problems
(6) Development and Discussion of the ITSEC

The full text has been posted to alt.security, misc.security and comp.security.

Kai Rannenberg Technische Universitaet Berlin Informatics Department
Sekretariat FR 5-10, Franklinstr. 28/29, D-W-1000 Berlin 10, Germany
[email protected] Phone: (+49 30) 314-73499 Fax: (+49 30) 314-24891

[It is also available for anonymous FTP from CRVAX.SRI.COM
with RISKS-13.ITSEC as its file name. Important for security-
minded folks. The ITSEC is good stuff. PGN]

------------------------------

Date: Tue, 17 Mar 1992 13:05:09 -0700
From: Bear Giles <[email protected]>
Subject: FOLLOWUP: NASA hacker sentenced
Organization: National Oceanic & Atmospheric Adminstration / Boulder Labs

From the 17 March 1992 _Rocky Mountain News_:

Hacker ordered to get mental help (Reuter)

A computer hacker who pleaded guilty Monday to breaking into NASA computer
systems as ordered to undergo mental health treatment and not use computers
without permission from a probation officer. Richard Wittman, 24, of Lakewood
[Colorado] was sentenced to three years probation by Denver U.S. Distrcit Judge
Sherman Finesilver in a rare prosecution for breaking into a computer system.
Wittman pleaded guilty last fall to one count of breaking into a National
Aeronautics and Space Administration computer. Prosecutors said Wittman had
spent four years trying to get into computer systems. In a plea bargain,
Wittman admitted gaining access to NASA's computer via a malfunction in a
bulletin board service.

------------------------------

Date: Thu, 12 Mar 92 0:38 BST
From: "Olivier M.J. Crepin-Leblond" <[email protected]>
Subject: Wiretapping of future communication networks

The following couple of articles were sent to the ISDN discussion list. I have
briefly commented at the end. (very briefly) OCL.

==============================

Date: Tue, 10 Mar 92 09:32:56 PST
From: [email protected] (Frank Heath)
Subject: Wiretapping and ISDN
Sender: isdn-request%[email protected]

From the LA Times Saturday, March 7,1992
FBI Fear Phone Advances Will Hamper Wiretapping

Washington- The FBI, contending that rapidly developing telecommunications
technology is hampering the vital tool of wiretapping, proposed legislation
Friday that would require the industry to ensure that improvements do not
interfere with the ability to secretly record conversations.

It also proposed that consumers pick up the cost of changing current
wiretapping equipment to keep pace with new technology.

If the problem is not solved, "terrorists, violent criminals, kidnapers, drug
cartels and other criminal organizations will be able to carry out their
illegal activities using the telecommunications system without detection." FBI
Director William S. Sessions said. [...]

At issue is the rapid move toward digital telephone communications and
fiber-optic systems in which thousands of conversations can be carried by
filaments roughly the size of a strand of human hair.

William A. Bayse, assistant FBI director for technical services, and other FBI
officals contend that the transmission of hundreds and sometimes thousands of
digital conversations over a single link prevents current wiretapping
technology from isolating conversations for recording as required under the
1968 federal wiretap law. [...]

Other FBI offical said the expense could be passed on to telephone users at a
cost of "probably less than 20 cents an average per month." [...]

FBI officals maintained, however, that they already have encountered
difficulties in recording digitally transmitted conversations, now used by
about 10% of the nations phones. They declined, however, to give any examples
of such difficulties.

[Well folks, we may have finally discovered the long awaited
"Killer ISDN Application", drug dealing! ;-)

On a more serious note is the FBI's technology that broken,
that it can't deal with multiplexed transmission? You would
think the NSA has sufficent technology to do it. I don't
know of ISDN phones that come with built in scramblers,
although it would be pretty easy to do. I don't think this
is what they are talking about here.

Particulairly galling is we are all going to be changed 20
cents a month to support big brother type intursions.

This sort of legislation can't help but to slow ISDN's
already glacial deployment.

For the ASI types what we need now is a new session block,
Circuit Switched Voice, Secure(except where prohibited by
law).

Frank S. Heath, CMC.COM
My views not CMC's or Rockwell's. ]

[And here is a followup article - OCL]

Date: Tue, 10 Mar 92 17:54:13 +0000
From: [email protected]
Sender: isdn-request <isdn-request%[email protected]>

I find it strange that the FBI should be tapping into lines directly (I saw an
old Cagney and Lacey last night which had them sitting in a basement with a
breakout box and a tape-recorder - definitive proof of the obsolescence of US
police equipement). Here in the UK, there is this persistent rumour that our
digital exchange has the most advance security facilities in the world,
allowing tapping of a conversation at the switch rather than on the wire. This
means our police don't have to get their hands dirty, assuming that the Home
Secretary gives permission, and all they need to do is attach a tape-recorder
(or tape drive) to a port at the exchange.

Does this mean we can expect the sales of System X to take off in the US, as
long as the FBI give their backing? Or are the FBI forbidden to attach to the
switch?
cheers, ian

[One of the forthcoming set of RISKS related to future telecommunication
systems. I'm currently working on Broadband ISDN, and believe me, when that
will be implemented, I doubt that the FBI will even bother about monitoring
lines due to the excess amount of information being transmitted.
Olivier M.J. Crepin-Leblond, Imperial College London, UK.]

------------------------------

Date: Fri, 13 Mar 1992 09:54:50 GMT
From: [email protected] (Torsten Lif)
Subject: Bugging ISDN

The recent thread on ISDN and bugging reminded me of an interesting issue.

Some years ago I worked in Ericsson's effort on designing ISDN phones. One of
the features we implemented was that in order to faciliate testing, the
exchange could send signals to set up loops in the terminals (this is fairly
standard) and to leave an "open end" in case deeper testing was ever needed, a
mechanism for reading or writing any data address on the terminals internal
system bus was provided. In theory, a piece of code could then be added byte by
byte to the RAM of the terminal and a patch jump applied to link it in. Not
that I think anybody would be foolhardy enough to actually do it, but in theory
it would be possible.

But one morning in a coffee-break brainstorm-session we started speculating on
what COULD be done if a feature like this were abused (say, by the FBI) and we
realized that since all the control ports of the phone were regular bus
devices, anybody who knew the address to the proper latch (easy to read if you
got hold of the system description documents), could send the instructions to
activate the microphone and connect it to a B-channel without going through all
the layer-3 protocol stuff or the phone's internal program. Just a couple of
"POKE"s and presto, the room is bugged. This would be more devious than the
"normal" kind of bugging where a line is tapped, since it would take place when
there's no phone call going on.

So as a collective act of civil disobedience the HW and SW designers got
together and put in an extra HW "AND" gate in a strategic location so that the
bitstream from the codec to the S-interface was choked unless either the
receiver was (hardware) off-hook or the "hands-free" indicator LED was turned
on. This meant that the SW had to set two latches to connect the phone to the
line but, hey, that's what macros are for... At least, if anybody were to try
and turn the phone on for bugging purposes, they would have to turn on the LED
on the front. Hopefully this would be conspicious enough to alert anybody in
the room.

Of course, this didn't prevent bugging of a phone call, but that's impossible
to guard from without encryptation anyway. ALL exchanges have supervision
devices that can be (ab)used to listen in on conversations. Telecom
manufacturers selling to certain countries routinely get orders for far more
supervision equipment than would normally be needed. Why is not too hard to
guess.

The upshot of this is that when I read the discussions about FBI's fear of new
technology, I remembered what we did to deliberately prevent something akin to
what they want legislation to force designers to give them. Does this mean that
I'm now "Persona Non Grata" in the US? :-)

Any others out there who can think of similar "features" of the new digital
technologies? Are we (the guys who then worked at Ellemtel) the only ones to
have thought of it and tried to prevent it? Are there any others on the
list/net who have worked in the field and have stories to share?

Torsten Lif
Ericsson Telecom AB, EO/ETX/TX/ZD
S-126 25 STOCKHOLM, SWEDEN
Phone: +46 8 719 4881

------------------------------

Date: Wed, 18 Mar 92 20:15:09 GMT
From: [email protected] (Nancy Griffeth)
Subject: CFP Workshop on Feature Interactions in Telecommunications Systems

Call For Participation

INTERNATIONAL WORKSHOP ON FEATURE INTERACTIONS
IN TELECOMMUNICATIONS SOFTWARE SYSTEMS

St. Petersburg, Florida, USA, December 3-4, 1992

DESCRIPTION

This workshop is planned to encourage researchers from a variety of
computer science specialties (software engineering, protocol
engineering, distributed artificial intelligence, formal techniques,
and distributed systems, among others) to apply their techniques to
the feature interaction problem that arises in building
telecommunications software systems.

The feature interaction problem has been a major obstacle to the rapid
deployment of new telephone services. Telecommunications software is huge,
real-time, and distributed; adding new features to a telecommunication system,
like adding new functionalities to any large software system, can be very
difficult. Each new feature may interact with many existing features, causing
customer annoyance or total system breakdown. Traditionally, interactions were
detected and resolved on a feature by feature basis by experts who are
knowledgeable on all existing features. As the number of features grows to
satisfy diverse needs of customers, managing feature interactions in a single
administrative domain is approaching incomprehensible complexity. In a future
marketplace where features deployed in the network may be developed by
different operating companies and their associated vendors, the traditional
approach is no longer feasible. How to detect, resolve, or even prevent the
occurrence of feature interactions in an open network becomes an important
research issue.

The feature interaction problem is not unique to telecommunications software;
similar problems are encountered in any long-lived software system that
requires frequent changes and additions to its functionality. Techniques in
many related areas appear to be applicable to the management of feature
interactions. Software methodologies for extensibility and compatibility, for
example, could be useful for providing a structured design that can prevent
many feature interactions from occurring. Formal specification, verification,
and testing techniques, being widely used in protocol engineering and software
engineering, contribute a lot to the detection of interactions. Several causes
of the problem, such as aliasing, timing, and the distribution of software
components, are similar to issues in distributed systems. Cooperative problem
solving, a promising approach for resolving interactions at run time, resembles
distributed planning and resolution of conflicting subgoals among multiple
agents in the area of distributed artificial intelligence. This workshop aims
to provide an opportunity for participants to share ideas and experiences in
their respective fields, and to apply their expertise to the feature
interaction problem.

We welcome papers on preventing, detecting, and/or resolving feature
interactions using either analytical or structural approaches. Submissions are
encouraged in (but are not limited to) the following topic areas:
- Classification of feature interactions.
- Modelling, reasoning, and testing techniques for detecting
feature interactions.
- Software platforms and architectures for preventing or
resolving feature interactions.
- Tools and methodologies for promoting software compatibility
and extensibility.
- Environments and automated tools for related problems in other
software systems.
FORMAT

We hope to promote a dialogue among researchers in various related areas, as
well as the designers and builders of telecommunications software. To this end,
the workshop will have sessions for paper presentations, including relatively
long discussion periods. Panel discussions and a short tutorial on issues in
the feature interaction problem are being organized.

ATTENDANCE

Workshop attendance will be limited to 75 people. Attendance will be by
invitation only. Prospective attendees are asked to submit either a paper
(maximum 5000 words) or a single page description of their interests and how
they relate to the workshop. About 16--20 of the attendees will be asked to
present talks. We will strive for an equal mix of theoretical results and
practical experiences. A set of working notes will be provided at the workshop.
Papers with the highest quality will be considered for publication in a special
issue or section of a research journal.

SUBMISSIONS

Please send five copies of your full original paper or interest description to:
Nancy Griffeth
Bellcore, MRE 2L-237
445 South Street
Morristown, NJ 07962-1910, USA
E-mail: [email protected]
Tel: (201) 829-4538 Fax: (201) 829-5889

IMPORTANT DATES

1 June 1992: Submission of contributions.
1 August 1992: Notification of acceptance.
15 September 1992: Submission of camera-ready versions.

WORKSHOP CO-CHAIRPERSONS

Nancy Griffeth (Bellcore, USA)
Yow-Jian Lin (Bellcore, USA)

PROGRAM COMMITTEE

chair: Hugo Velthuijsen (PTT, The Netherlands)

E. Jane Cameron (Bellcore, USA)
Steven Harris (BNR, Canada)
Gerard J. Holzmann (AT&T Bell Laboratories, USA)
Michael Huhns (MCC, USA)
Luigi Logrippo (University of Ottawa, Canada)
Harm Mulder (PTT, The Netherlands)
Jan-Olof Nordenstam (ELLEMTEL, Sweden)
David Notkin (University of Washington, USA)
Akihiro Shimizu (NTT, Japan)
Yasushi Wakahara (KDD R&D Laboratories, Japan)
Pamela Zave (AT&T Bell Laboratories, USA)

------------------------------

End of RISKS-FORUM Digest 13.29
************************