Subject: RISKS DIGEST 17.57

Subject: RISKS DIGEST 17.57

RISKS-LIST: Risks-Forum Digest Thursday 21 December 1995 Volume 17 : Issue 57

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

********************* HAPPY AND RISK-FREE HOLIDAYS ***********************
***** See last item for further information, disclaimers, etc. *****

Contents:
Problems with computerized "translation" (Jesper Holck)
German Windows 95 dishonors write-protection (Arslan Broemme)
German service providers must maintain covert customer databases?
(Wilhelm Mueller)
The cellular-phone encryption debate in Israel (Jonathan Kamens)
Domain Registration RISK? ()
Risks of Checking Accounts (Gary M. Watson)
Re: Naval Battleship takeover - I don't think so. (InfoWar moderator)
Re: Indelible words (Andrew Marc Greene)
Re: Medical diagnosis by computer (Bob Morrell)
Re: Definitions for hardware/software reliability ... (Pete Mellor)
Pilot-in-command authority (Re: a well-managed risk) (Andrew Koenig)
ABRIDGED info on RISKS (comp.risks)

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

Date: Thu, 21 Dec 1995 16:04:45 +0200 (METDST)
From: Jesper Holck <[email protected]>
Subject: Problems with computerized "translation"

A few months ago I was looking in the table of contents for the Danish
users' guide for Windows for Workgroups 3.11, and I noticed some
very peculiar words like "Stogardinstallation" and "ogre". I know
most readers of this mail are not able to read Danish, but these
are certainly not ordinary Danish words.

At last I managed to find an explanation to these strange words. Apparently
someone wanted to "translate" the English word "and" to the equivalent
Danish word "og". And made this "translation" using a simple
search-and-replace.

So "standard" became "stogard", "andre" (other) became "ogre" and so on ...

I hope Microsoft will be able to find some better ways of translating
from English to Danish in the future.

Jesper Holck, Ballerup Business College, P.O. Box 40, DK-2750 Ballerup DENMARK
[email protected] or [email protected] +45 44 97 3597 Fax: +45 44 68 3350

[This method might be known as "hog to mouth", where a "dandy" becomes
a "dogy", a "landslide" a "logslide", and quite appropriately a "sandwich"
becomes a "sogwich". This is definitely worthy of a Victor Borge scene,
along the lines of his world-famous "off-by-one" (+1) routine. PGN]

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

Date: Wed, 20 Dec 1995 23:28:12 +0100
From: [email protected] (Arslan Broemme)
Subject: German Windows 95 dishonors write-protection

My name is Arslan Broemme. I'm a student of computer science at the
University of Hamburg (Germany).

While watching airplanes land with my girl-friend, I heard on Radio Hamburg
(moderator: K.D. Ackermann, 12 Dec 1995, 22:10h and again at 23:15h) that it
is possible to format write-protected disks when using the German version of
Windows 95.

http://www.informatik.uni-hamburg.de/Arbeitsbereiche/AGN/people/broemme/
arslan.html [email protected]

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

Date: 21 Dec 1995 13:44:09 +0100
From: [email protected] (Wilhelm Mueller)
Subject: German service providers must maintain covert customer databases?

This is an excerpt from an article that appeared in the weekly German
newspaper *Die Zeit*, No. 52 (22 Dec 1959), p.58 (Bulkware/Telephon-CD
gestoppt). [literal translation by WM] [*emphasis* below is *Die Zeit*'s]
[further translation by PGN, respecting the original German (not included)]:

For others, though, address data will suffice only if it can be
easily compared with other databases. Such a practical ["praktisches"!]
information system is needed by the German government and secret
services. Paragraph 92a TKG-E of a proposal for a new *telecommunications
law* published last week would oblige all telephone companies, on-line
services, and even private mailboxes to maintain a database at their own
expense containing the full names, addresses, and phone numbers of *all
customers* -- in case someone is under suspicion. This database must be
organised so that it can be accessed by higher places ["hoeheren Orts"!]
without the telecommunication provider noticing it.

Wilhelm Mueller, Am Wall 139, D-28195 Bremen (office) +49-421-361-10629
[email protected] (home) +49-421-169 2525

[Ah, mandatory trap doors are a wonderful opportunity for misuse,
internally and externally. We've been around this topic in RISKS
many times before, but this is a new context. PGN]

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

Date: Wed, 20 Dec 1995 15:07:07 GMT
From: Jonathan Kamens <[email protected]>
Subject: The cellular-phone encryption debate in Israel

An article headlined "Knesset considers lack of protection against cellular
phone eavesdropping" and sub-headlined "Communications Ministry
director-general: Databases can be easily entered", by Evelyn Gordon,
appeared in today's "Jerusalem Post". Some excerpts:

*************************

Cellular phones are completely unprotected against electronic eavesdropping,
and the same is true of many databases and even some regular phone lines,
the Knesset Economics Committee's consumer affairs subcommittee was told
yesterday. ...

"All of the public databases in Israel can be very easily entered,"
[Shlomo] Wachs [Communications Ministry director-general] added. "And
there are some towns in Israel connected to the telephone via
microwave transmissions, and it is possible to listen in on regular
phone calls via every such transmission." [sic] ...

Hanan Achsaf, general manager of Motorola, said that instructions for
eavesdropping on cellular phones are available on the Internet, and
therefore are now public domain. [Apparently (summarizing from another
recent article in the "Post"), someone recently posted instructions for
activating a "debugging" mode in Israeli cellular phones which causes them
to pick up any calls being carried on by other cell-phones in their
vicinity. I don't think there's anything special about Israeli cell-phones,
so I suspect that cell-phone networks in other countries are also vulnerable
to this attack.]

Both Eyal Levy, managing director of Pelephone [one of the Israeli
cell-phone networks], and Shalom Menuba, deputy managing director of Cellcom
[the other one], said that while they could not prevent eavesdropping, they
had the capability of knowing when it was happening and who was responsible.
[[SEE BELOW.]] ...

Menuba also said Cellcomm phones are technically capable of encoding
conversations, and that the company would examine the feasibility of
allowing customers to do so. Wachs, however, opposed this idea, noting that
even in the US, encryption is illegal for security reasons. [[SEE BELOW.]]
Achsaf said that in any case, the technology was still in the experimental
stage, and not yet ready for commercial use. ...

*************************

In response, I sent the following letter:

*************************

<my address and phone number deleted>
December 20, 1995

Shlomo Wachs, Director-General
Ministry of Communications
The Knesset
Jerusalem

Dear Mr. Wachs:

I am writing to correct two serious errors in the testimony about cellular
telephone security presented to the Knesset Economics Committee's consumer
affairs subcommittee on December 19, as reported in The Jerusalem Post on
December 20.

The Post reported, ``Both Eyal Levy, managing director of Pelephone, and
Shalom Menuba, deputy managing director of Cellcom, said that while they
could not prevent eavesdropping, they had the capability of knowing when it
was happening and who was responsible.'' That is simply not true.

The signals which carry cellular telephone conversations can be
listened to by anyone with a radio scanner capable of being tuned to
the correct frequencies. While it may be true that Pelephone and
Cellcom can detect eavesdropping done using the instructions recently
made available on the Internet (since those instructions pertain to
the use of regular cellular telephones, rather than scanners, to
eavesdrop on conversations on other phones), they cannot detect or
identify those who eavesdrop using scanners.

The Post further reported that you oppose the use of encryption to protect
cellular telephone conversations, and that you claimed that ``even in the
US, encryption is illegal for security reasons.'' This, too, is simply not
true.

There are currently no restrictions in the United States on the use of
encryption to protect cellular telephone conversations. Plans to enact such
restrictions have been proposed by the government, but those proposals have
been received so negatively by American civil-liberties advocates that none
of them has succeeded, and it is not clear if any of them will.

It is clear that there are serious privacy problems with unencrypted
cellular-telephone conversations. It is also clear that prohibiting their
encryption will not help security, since anyone who has a desire to do
anything illegal using a cellular telephone will be willing to use
encryption whether or not it is legal. I therefore urge you to reconsider
your stand, and to encourage cellular telephone carriers in this country to
make encryption available to their subscribers.

Sincerely,
Jonathan I. Kamens

cc Editor, *The Jerusalem Post* FAX: 02-389-527

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

Date: Thu, 21 Dec 1995 09:36:26 -0500
From: [Identity withheld by request]
Subject: Domain Registration RISK?

I administer an ISP that owns the name XXXXs.net; and sent in a request to
the InterNIC [Domain Registration Role Account <[email protected]>] to
update our list of nameservers. Unfortunately, I made a typo and left off
the last character ("s") of the domain name. The update went through anyway,
changing someone else's entry so that the entire planet will think they
should contact US for his address info instead of his real servers.

I immediately sent a note to the NIC informing them of the mistake. It's
now >18 hours later and I haven't heard back from them. As the reply from
the NIC indicated, root server updates for this change won't happen until 5
PM tomorrow ... the Friday before XMAS ...

The RISKs are rather obvious.

[Attached correspondence deleted for RISKS. PGN]

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

Date: Wed, 20 Dec 1995 17:00:14 -0800 (PST)F
From: [email protected] (Trimm Industries)
Subject: Risks of Checking Accounts

A couple weeks ago I was depositing a check at an ATM, filled out the
deposit slip, and was ready to seal it in the envelope when something
attracted my attention to the name on the deposit slip -- it wasn't mine!
It came out of my pad of (correctly) printed checks, but about half of the
deposit slips in the pad were some other guy, from a different state, with a
different account number AT A COMPLETELY DIFFERENT BANK! Now, I understand
that check printers service many different banks, but this guy's name was
distant from mine alphabetically and the account number was quite different.
The RISKs here are several and obvious, such as what fate befell _my_
deposit slips, but alas as yet no one has deposited money into my account by
using one of my deposit slips by mistake.

Okay, life is weird and all that, but the very next week BofA accidentally
included someone else's bank statement in with mine, including all their
cancelled checks. It occurs to me that this would be a goldmine for a
swindler -- here I had a sample of the person's signature, their
(substantial) starting and ending bank balance, their check style and
account number, as well as their home address. Thus far, not much for a
crook to go on. But here's the kicker -- the person paid her phone bill and
put her unlisted phone number on the Memo line, paid her Visa bill and put
her Visa number on the Memo line, and paid some other bill whose account
number was her Social Security Number with an alphabetic prefix, and this
was on the Memo field of the appropriate check. I had a dossier on this
person and if I was a swindler I could have ruined her life.

The RISKS:
1. Banks are idiots. Don't trust them to keep your secrets.
2. Don't put all sorts of important numbers on check Memos.
3. Keep in mind that people can _steal_ your checking statement
from your mail.
4. Merchants: don't assume that because someone has a few personal
numbers of someone that they are indeed that person.
5. Consider letting the bank store your cancelled checks on microfilm
for you (but keep #1, above, in mind.)

Gary M. Watson Sigma-Trimm Technologies [email protected]
350 Pilot Road, Las Vegas, NV 89119 Phone: (800) 423-2024 x2115

[This is clearly RISKS relevant, although some of you may wonder about
the computer-relevance. The bottom line seems to be that if we blindly
trust technology, we may be more easily led astray. PGN]

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

Date: Thu, 21 Dec 1995 10:14:42 -0500 (EST)
From: [email protected] (Information Warfare Mailing List)
Subject: Re: Naval Battleship takeover - I don't think so. (Long, RISKS-17.55)

I thought RISKS readers might be interested in this moderator's note from
the IW mailing list, responding to the earlier message in RISKS-17.55.

Moderator's Note:
Subject: Navy hacked by Air Force

I talked to some people I know about the purported IW attack on a battleship
by the Air Force, and I thought I would help debunk this story, which my
contacts tell me is "wildly inaccurate", but looking at a few facts. Let's
start with the title:

> War of the microchips: the day a hacker seized control of a US battleship

No!!! There are NO active US battleships!!! And there weren't any last
September.

..
> BY SIMPLY dialing the Internet and entering some well-judged keystrokes,
> a young US air force captain opened a potentially devastating new era in
> warfare in a secret experiment conducted late last September. His
> target was no less than gaining unauthorised control of the US Navy's
> Atlantic Fleet.

According to my sources this was not "SIMPLY dialing the Internet and
entering some well-judged keystrokes". It was a controlled experiment
with participation of both Navy and Air Force, and involved a great deal
of planning by a large number of people. It was performed using DoD
owned and properly keyed cryptographic devices designed to be allowed to
communicate with the systems being attacked.

> He was armed with nothing other than a shop-bought computer and modem.
> He had no special insider knowledge but was known to be a computer
> whizzkid, just like the people the Pentagon most want to keep out.

100% wrong - he was an insider, he had a great deal of assistance, he had
cryptographic devices and keys, and he had special insider knowledge. If he
was a Navy captain, he could not have been all that young. Whizzkids are
usually considered teenagers. Anyone know of any teenaged Navy captains?

> A few clicks and whirrs were the only signs of activity. And then a
> seemingly simple e-mail message entered the target ship's computer
> system.
..
> targeted ships surrendered control as the codes buried in the e-mail
> message multiplied inside the ships' computers. A whole naval battle
> group was, in effect, being run down a phone-line. Fortunately, this

Not quite. This was not an e-mail sent from some Internet site and e-mail
messages did not multiply inside the ships' computers. Furthermore, the
total bandwidth of a phone line is nowhere near enough to "run" a naval
battle group, or probably even a naval kitchen for that matter.

> The exact method of entry remains a classified secret.

The first really true part of the story.

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

Date: Thu, 21 Dec 1995 13:12:49 -0500
From: "Andrew Marc Greene" <[email protected]>
Subject: Re: Indelible words (Hawthorne, RISKS-17.56)

After reading Brian Hawthorne's discussion of the altavista search engine, I
had to try it. Not only did I find all sorts of things that I wrote (or that
people wrote about me :-) going back to 1988, but I tried something else
even more enlightening:

I did a web search for my URL.

It's amazing who has links to my homepage or to one of the two other web
sites that I run. Yahoo thinks I'm an entertainer (one of the sites I host
is for a chorus that I sing in). People I've never heard of have links into
my stuff.

This is great news. The things I put on the web are useful enough that
people want to link to them. I'm proud and happy.

On the other hand, I now have a list of about thirty people who are
interested in Jewish law or Jewish music. If only I were trying to sell them
something... :-)

- Andrew Greene

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

Date: Wed, 20 Dec 1995 10:30:38 -0500 (EST)
From: Bob <[email protected]>
Subject: Re: Medical diagnosis by computer (Herbkersman, RISKS-17.56)

> As a sometime programmer and dabbler in databases, I find this news
> exceedingly disconcerting. It is the best reason I can think of for staying
> well. At any rate, please read the rest of the article.

Medical expert systems are nothing new, and should not really be all that
frightening to people. Remember, your doctor is an expert system, operating
on rules derived from his education (programming), his experience (case
database) and on the data input (your complaints). Computerized expert
systems have several advantages to offer. Consider for instance, the number
of physicians currently *not* treating and curing ulcers, because they have
not gotten up to speed on this new therapy. An expert system, managed
receiving updates from the best in each field, would make that change
overnight. Computerized expert systems would also not be influenced by
factors such as a very whining child and a overly worried mom, that might
lead to over-prescription of antibiotics and other unnecessary therapy.

There are risks to medical expert systems: over-reliance by physicians and
the loss of skills that entails, "gaming of the system" by patients desiring
certain therapies or diagnosis, failure to recognize unusual cases outside
the systems case-base, but note that many of these risks exist in some form
or another with human physicians.

I have worked for several years now with another kind of medical es, the
simpler, "inspector" kind that monitors human-guided therapy and attempts to
find "discrepancies", so my bias on this matter is clear. I maintain
however, that this technology has matured well past the point where it
offers positive gain to the patient. Much of the resistance to it is founded
not on fear of mistakes but on fear of loss of status by physicians. Enter
the new world with your eyes open and quick to question your care, but
frankly, you should have been doing that all along....

Bob Morrell http://www-uk.hpl.hp.com/people/ewc/list-main.html#HDR13
[email protected]

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

Date: Wed, 20 Dec 95 19:40:34 GMT
From: Pete Mellor <[email protected]>
Subject: Re: Definitions for hardware/software reliability ... (RISKS-17.56)

I was interested to note that the references cited under "Failure" (surely
the most frequently defined term in the field) include:-

> The termination of the ability
> of an item to perform a required function (BS4778) (O'Connor81).

However the full set of references here is (excuse the Latex format):

BS 4778: ``Quality Vocabulary'', Part 3: {\em Availability, reliability
and maintainability terms\/}, Section 3.1: ``Guide to concepts and related
definitions'', British Standards Institution, 1991.

IEC 50(191): ``International electrotechnical vocabulary'', Chapter 191:
{\em Dependability and quality of service\/}. This has been dual-numbered
as Section 3.2 of the British national standard:--

BS 4778: ``Quality Vocabulary'', Part 3: {\em Availability, reliability
and maintainability terms\/}, Section 3.2: ``Glossary of international
terms'', British Standards Institution, 1991.

The extract also fails to mention:-

ISO~8402 : 1986, {\em Quality - Vocabulary\/}

ISO/IEC~9126: 1991(E) ``Information technology -- Software product
evaluation -- Quality characteristics and guidelines for their use'',
first edition, 1991-12-15

These omissions are somewhat surprising, given that IEC/TC56 is the
technical committee (TC) of the International Electrotechnical Commission
(IEC) working on "dependability" (i.e., reliability, availability,
maintainability and similar concepts, excluding "safety" which is the
responsibility of TC65), and that both it and ISO/IEC JTC1 (Joint Technical
Committee 1, whose subcommittee SC7 is responsible for 9126) are currently
very active.

This makes me suspect that, despite its June 1995 publication date, M.J.P.
van der Meulen's book is grossly out of date in several important respects.

As Principal UK Expert (PUKE - Gentlemen, I kid you not! :-) on "definitions
of terms", representing BSI committee DS/1 on IEC/TC56/SC1, I have been
working in this area for several years. (The main qualification is the
ability to sit through a three-hour argument about the difference between a
"functional unit" and an "item" without committing hara-kiri! :-)

You might be interested to know that, following the receipt of DD198 from
its public comment phase, BSI DS/1/-/1 (Why the "-"? Just DON'T ask!) is
now working on turning it into a fully issued Part 8 "Assessment of
Reliability of Systems Containing Software" of BS5760 "Reliability of
Systems, Equipment and Components".

Peter Mellor, Centre for Software Reliability, City University, Northampton
Square, London EC1V 0HB, UK. Tel: +44 (171) 477-8422, [email protected]

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

Date: Thu, 21 Dec 1995 11:47:16 EST
From: Andrew Koenig <[email protected]>
Subject: Pilot-in-command authority (Re: a well-managed risk, RISKS-17.47)

Steve Fenwick <[email protected]> and Robert Dorsett <[email protected]> responded
to me [Not included here. PGN] about emergencies, and I am in complete
agreement with them. However, I think it's worth saying again that my
original message talked not about emergencies but rather about procedures to
manage risk on ordinary flights.

The two procedures I thought well-chosen were (a) picking a closer
`destination' to allow for 10% slop in fuel estimation and (b) requiring
independent confirmation before changing the official destination to match
the real one.

After reading the various comments, I still think they are evidence of
well-considered risk management.

Andrew Koenig [email protected]

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

Date: 6 September 1995 (LAST-MODIFIED)
From: [email protected]
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) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...]
DIRECT REQUESTS to <[email protected]> (majordomo) with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:]
INFO [for further information]

CONTRIBUTIONS: to [email protected], with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious. Diversity is
welcome, but not personal attacks. [...]
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.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks

RISKS ARCHIVES: "ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP. [...]
[Back issues are in the subdirectory corresponding to the volume number.]
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]
ftp://unix.sri.com/risks [if your browser accepts URLs.]

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

End of RISKS-FORUM Digest 17.57
************************