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 17 Issue 62

Weds 10 January 1996

Contents

o E-Mail-Tap Nets Criminals
Edupage
o Pacific Northwest air-traffic outage
Mich Kabay
o Sting-Re: "ghoti"?
o Microsoft continues to mislead public about Windows security bugs
Rich Graves
o Configuration files may travel
Kurt Tekolste
o Re: Brunnstein / Compuserve / Germany
Martin Virtel
o Attacking CompuServe Subscribers
Mich Kabay
Henry G. Baker
o Re: Floating Point Number formats
Phillip C. Reed
o Reliable development methodology
Andrew Robson
o New Security Paradigms '96 -- Call for papers
Yvo Desmedt
o ABRIDGED info on RISKS (comp.risks)

E-Mail-Tap Nets Criminals (Edupage, 4 January 1996)

Educom <educom@elanor.oit.unc.edu>
Thu, 4 Jan 1996 14:32:51 -0500 (EST)

The first-ever court-approved wiretap of an e-mail account has resulted in the arrest of three people charged with running a sophisticated cellular-fraud ring. The alleged mastermind, a German electrical engineer, advertised his illicit wares on CompuServe, where they caught the attention of an engineer at AT&T's wireless unit. The Secret Service and the Drug Enforcement Agency then got into the act and obtained the Justice Dept.'s permission to intercept e-mail messages between the alleged perpetrator and his accomplices. "This case represents the challenges in the future if we can't get ahead of the curve in technology," says a U.S. attorney, whose office is prosecuting the case. (*Wall Street Journal*, 2 Jan 1996, p.16)


Pacific Northwest air-traffic outage

"Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com>
09 Jan 96 14:58:56 EST

From the Associated Press news wire via CompuServe's Executive News Service:

Air Traffic Outage (by George Tibbits, Associated Press Writer)

SEATTLE (AP) -- A technician won't be disciplined for an accident that cut off all power to an air-traffic control center and delayed flights throughout the Pacific Northwest, an FAA spokesman said Sunday. The power outage early Saturday darkened radar screens and silenced radios and telephones at the Federal Aviation Administration center, leaving controllers completely in the dark for at least five minutes.

Key points:

M.E.Kabay,Ph.D. / Dir. Education, Natl Computer Security Assn (Carlisle, PA)

Sting-Re: "ghoti"?

"Peter G. Neumann" <neumann@csl.sri.com>
Mon, 8 Jan 96 19:33:36 PST

Not surprisingly, many folks hastened to remind me that the "o" in "ghoti" is properly pronounced as the "o" in "women". Yes, of course, but I was seeking a minimalist alternative, noting that pronouncing "ghti" as "fsh" sounds pretty much like "fish" in most dialects -- although phonetically the "o" in "women" might be considered necessary for precision in high english. Incidentally, for those of you who are language buffs (in any language), pick up a copy (in paperback) of Anthony Burgess' "A Mouthful of Air". It is a truly marvelous book about language and languages. PGN


Microsoft continues to mislead public about Windows security bugs

Rich Graves <llurch@Networking.Stanford.EDU>
Mon, 8 Jan 1996 19:16:50 -0800

Please do not dismiss this as mere "Microsoft Bashing." c2.org has similar promotions running for Netscape, DigiCash, and Java.

The following is a quote from Microsoft's "Knowledge Base" technical support and marketing database, which is online in CompuServe and at:

http://www.microsoft.com/kb/peropsys/windows/q90271.htm

Security of the Windows for Workgroups Password Cache
_____________________________________________________

The password list file is encrypted with an algorithm that meets the U.S. government Data Encryption Standard (DES). This encryption technology is the highest security allowed in software exported from the United States. The odds of breaking the encryption algorithm are less than those for random guesses of what the password might be.

Even if your logon password is blank, Windows for Workgroups generates seemingly random data in your PWL file, so you cannot discover the passwords if you look at the PWL file using a file viewer. Currently, no user interface exists that allows you to unencrypt passwords in the PWL file, so password caching in Windows for Workgroups is as secure as the choice of the password used to encrypt your PWL file.

As Microsoft well knows, this is completely untrue. The rest of the world has known that this is untrue since November 29th. Microsoft quietly acknowledged on December 7th (after a day of much "Internet Strategy" hype, and after the deadline for the morning papers) that the exact same implementation was insecure in Windows 95, and claims to have released a patch that fixes the problem (the efficacy of the Win95 patch does not appear to have been verified by anyone outside Microsoft, however).

Microsoft has not even admitted that this bug in both Windows 95 and Windows for Workgroups affects Windows for Workgroups, apparently because they have decided not to fix it.

Information on the .PWL implementation bugs was first broached on the sci.crypt newsgroup in late November 1995, then discussed on the cypherpunks list and refined for Community ConneXion's "Hack Microsoft" promotion, http://www.c2.org/hackmsoft/.

We have since been given a sample trojan horse that will very efficiently exploit this bug in Windows for Workgroups. Distributed as a Word Basic virus, MIME attachment, or downloadable archive (note that Exchange and Internet Explorer unwisely execute downloaded binaries without even a virus check, a problem that Sun's Java has long acknowledged and addressed), this trojan horse could collect passwords and other sensitive information from .PWL files and other sources and send them out via e-mail, possibly through
an untraceable chain of remailers or to a throwaway trial account on, for example, America "Online."

We believe that it would be highly irresponsible to release the full version of this hack, but we will soon release a crippled demonstration-only version if Microsoft does not at the very least admit that this problem has always affected Windows for Workgroups, correct their online documentation, publish the specifications of the Win95 security patch for review by outside security experts, and issue a public retraction.

See also:

http://www.microsoft.com/kb/peropsys/windows/90210.htm
http://www.microsoft.com/windows/pr/clarifications.htm
http://www.c2.org/hackmsoft/

http://www-leland.stanford.edu/~llurch/win95netbugs/faq.html

{mirror of above} http://www.mari.su/guide/win95/
{mirror of above} ftp://ftp.demon.co.uk/pub/mirrors/win95net/
{more mirrors are under construction in Australia and elsewhere}

In other news, I assume everyone knows by now that NT's claimed C2 security rating was granted *for use a standalone workstation only*. It has been widely reported that its NetWare Services implementation does not ask for passwords for nonexistent usernames, making a potential cracker's job that much easier. The correct response, which is given by real NetWare servers and other servers that are certified C2-secure on networks, is to silently ask for a password in all cases.

I started getting copies of hackmsoft@c2.org mail on December 20th. It's really depressing.

We've also seen problems with Microsoft Access 95's security. Basically, there is none. Anyone can access the network-enabled Access as any user without knowing the password. We don't think it would be responsible to publicly release this hack, either, until Microsoft has had another chance to patch the hole (they've known about it for some time).

These are far, far worse than the widely publicized bugs in Netscape's SSL implementation, which have been fixed. Yet the only place I've seen them mentioned is the lapdog Seattle Times, which only reports bug *fixes* in glowing terms.

Is anybody listening?

- -rich
owner-win95netbugs@lists.stanford.edu ftp://ftp.stanford.edu/pub/mailing-lists/win95netbugs/ gopher://quixote.stanford.edu/1m/win95netbugs http://www-leland.stanford.edu/~llurch/win95netbugs/faq.html

Configuration files may travel

<tekolste.kurt@ist.vf.mmc.com>
Tue, 09 Jan 96 11:27:23 PDT

I have not been a participant in this newsgroup, so I am trusting the advice of someone who is that the following constitutes a risk of interest.

Concerned about the amount of disk space on my laptop, I opted to use the copy of Netscape on my company's server. I configured Netscape to my parameters and used it this way until I realized that it was important enough to live on my C: drive.

A few months after running Netscape from the server, I began to get an occasional e-mail which seemed to be intended for someone else. It took me a while to realize that my netscape.ini file had been saved on the server, not on my laptop. Apparently, other employees were copying the INI file and, not knowing how to properly set it up, were leaving my return address in place.

The primary risk here is clear: saving various .cfg, .ini, etc. files in the default location determined by the application may result in the information in those files being made available to the public. Since these files may include logon names and passwords, care must be taken to ensure that they are saved in appropriate locations.

There is also a secondary risk: by intentionally supplying a .cfg or .ini file of his/her own design to the common server, a hacker could configure the apps of the unwary in ways which are not wanted.


Re: Brunnstein / Compuserve / Germany

Martin Virtel <M.VIRTEL@bionic.zerberus.de>
Tue, 09 Jan 1996 23:38:54 +0100

Klaus Brunnstein's work is of great value for the computing community, but he messed up some concepts of German criminal law.

KB: CompuServe OVERREACTED in blocking access to ALL these electronic fora WORLDWIDE. As most national laws (with exception of some laws requesting universal applicability :-), German law deliberately applies to Germany :-)!

Wrong. In special cases, German criminal law claims international validity. One of these cases (listed in Par.6 of the Criminal Code) is the distribution of pornographic material containing "violent actions, sex of human beings with animals or child abuse" ["Gewalttaetigkeiten, den sexuellen Misbrauch von Kindern oder sexuelle Handlungen von Menschen mit Tieren"].

KB: Either was CompuServe TECHNICALLY UNABLE to react ONLY FOR GERMAN users (and leave worldwide users unaffected).

This was the case, according to German media reports. TV newscast "Frontal" reported Tuesday evening that CompuServe is rewriting its Software to allow Internet access control according to the nationality of the user. But regarding child pornography and the german law, this wouldn't help CompuServe much. - see above -

KB: The procedure of Bavarian State Attorney may have one week point in whether the term "writing" (evidently meant by legislators as applying to traditional paper-work) may apply to "electronic documents" even in "virtual form".

Wrong again. Par. 11 Sentence 3 of the Criminal Code defines the word "writing" ["Schriften"] as applying to audio and video storage systems, pictures or any other form of representation ["Ton- und Bildtraeger, Abbildungen und andere Darstellung"]. Technically, this is a so-called "open catalog" definition, this means that any attorney or judge can add any form of representation of a contents he or she chooses appropriate - even non-physical representations on screens.

So, where's another RISK?

Any CompuServe Executive reading comp.risks? No?

RISK! RISK!

Martin Virtel
[Etliche Mispelungen von PGN korrektiert (hoffentlich!).]

Attacking CompuServe Subscribers

"Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com>
09 Jan 96 08:15:43 EST

In an excellent analysis of the stupidity of CompuServe staff in overreacting to the Bavarian request for cooperation in stopping the distribution of child pornography in their jurisdiction <Metaphorplay on Compuservile>, Henry Baker wrote the following dismaying text:

> Copyright (c) 1996 by Henry G. Baker. All rights reserved.
> ** Warning: Due to its censorship, CompuServe and its subscribers **
> ** are expressly prohibited from storing or copying this document **
> ** on CompuServe in any form. **

I and many other CompuServe (CIS) users despise the decision to apply a blanket prohibition against the news groups. At the same time, I protest the inclusion of this prohibition in the RISKS FORUM DIGEST.

  1. CompuServe is a private organization, not a government agency. If CompuServe management were to decide to prevent access to news groups with, say, the letter "k" in the third place of the name, its customers could (a) protest to CIS management; (2) obtain Internet access through another supplier; and (3) cancel their subscriptions. However, there would be no violation whatever of free speech in such action, even though it would be stupid, counter-productive and offensive. A commercial service has no requirement to provide all possible services--it merely supplies services and takes the commercial consequences of its actions.

    In the current case, if enough CIS users require access to the banned groups, the economic consequences will be borne by CIS owners and shareholders. Treating us CIS subscribers as pariahs because we find the balance of services at CIS acceptable even with the stupid ban is itself a bizarre overreaction.

    So Mr Baker wants to punish subscribers to CIS because it DOESN'T provide access to all news groups. What's next, punishment of subscribers to services who provide access to new groups that he _dislikes_? Is Mr Baker aligning himself with the lunatics in the far-right religious fringe who would jump on _him_ for subscribing to an Internet access provider which _does_ allow access to news groups _they_ disapprove of?

    How would Mr Baker respond to a suggestion that CompuServe ban all postings from people with netcom.com addresses? Would that seem fair? Why not?

  2. CIS is not simply an Internet access provider. Many users depend on the service for access to databases simply unavailable on the Internet. Why should Baker or anyone else single us out for punishment in this way?
  3. The internal response from CIS subscribers on CIS management has been enormous--and negative. There have been thousands of messages all over the service in which the ban is dissected; there have also been public meetings in the CIS Conference Rooms where the issues are analyzed.

    Baker's prohibition prevents me from supplying ammunition to the very forces who are on Baker's own side of the argument. His article would normally be posted in the NCSA Forum where it could be read by 50,000 members who could then build on his contribution. Now it will be available only in the archive copy of RISKS instead of in the public Forum. Pity.

  4. Because many of us receive the RISKS FORUM DIGEST via e-mail on CompuServe, we simply cannot comply with Baker's prohibition even if we wanted to. The DIGEST did indeed reside on CIS computers until I downloaded it from my e-mail in-basket. Since I certainly will not unsubscribe to the DIGEST simply because one correspondent wishes to punish all CIS users, I will continue to receive his occasional contributions whether he wants me to or not. I suggest that Baker either stop publishing his messages in the DIGEST or stop appending his offensive signature text.
  5. The National Computer Security Association (NCSA) makes RISKS FORUM DIGEST archives available in a Library in the NCSA FORUM. Is Mr Baker proposing that we _edit_ the RISKS FORUM DIGEST to remove his contributions? Preposterous. I refuse to tamper with the contents of the DIGEST simply because one individual is in a snit about some jerk of a CIS manager's decision to go into hysterics over a request from a Bavarian prosecutor.

    If Mr Baker has a problem with that, I suggest he contact a lawyer.

  6. The NCSA extracts certain individual articles from the RISKS FORUM DIGEST and other Internet publications for inclusion in specific sections of the Forum; for example, this message will appear in the PRIVACY/ETHICS section of the NCSA Forum. Contrariwise, several Sysops from the NCSA Forum cross-post our summaries of news wire service articles to RISKS and other new groups. The arrangement makes the information and opinions available to a wider audience than would otherwise see the contributions.

    One contributor to RISKS has requested that we NOT post his contributions to the Forum and we have complied with his request even though we think it is ridiculous for him to stop the 50,000 people in the NCSA Forum from seeing his public postings. We will comply with Mr Baker's implicit request as well even though it's a nuisance to have to remember that these two individuals have such a prohibition in place. I shudder to think what will happen if lots of people append this kind of restriction on their postings.

The more fundamental issue for RISKS FORUM DIGEST and news group moderators and users in general is whether it is acceptable for a contributor to (1) post a message for worldwide distribution and simultaneously to demand that it not be received by or redistributed to users of specific services.

Mr Baker's prohibition is an example of the very problem he attacks in his message. Carried further, one might see demands that a message not be available to subscribers of a service because specific users of that service have spammed the Net; or because the managers wear ties; or because people who eat meat subscribe to the service; or .... the possible targets of prejudice are infinite.

If Mr Baker doesn't want his message to be public then he shouldn't post it in public.

I hope that Mr Baker will reconsider his offensive signature string and that no one else will include such prohibitions in their contributions to RISKS.

M.E.Kabay,Ph.D. / Dir. Education & Chief Sysop of CompuServe NCSA Forums Natl Computer Security Assn (Carlisle, PA)

Attacking CompuServe Subscribers

Henry G. Baker <hbaker@netcom.com>
Tue, 9 Jan 1996 09:38:22 -0800 (PST)
[Henry's response to Mich's message follows. I generally truncate most of the unusual trailers, and reject a priori all messages with restrictive redistribution, but I ran Henry's message with its "copyright" notice sensing that it might just help to raise the level of awareness to this particular issue. However, don't expect other messages to get by with such restrictions. PGN]
I have nothing against Compuserve subscribers themselves. I hope to continue fruitful dialog with them through other ISP's. There is currently a wide choice of excellent, inexpensive, non-censoring ISP's, but how long this choice will remain due to government interference is very much in doubt.

Compuserve apparently lost their backbone and refused to fight for their subscribers, so why should their subscribers fight for Compuserve? Subscribers should all put their subscriptions 'in escrow' until full Internet service is provided, the same way that tenants put their rent in escrow until the landlord fixes their electricity, their water, or their sewer(!) ;-)

Paraphrasing Shakespeare, Compuserve should screw their courage to the sticky post.

Re: minor inconveniences

Our forefathers fought and _died_ for the right to free speech. Do you think anyone should have any sympathy for this whining about the minor inconvenience of changing ISP's?

Henry Baker www/ftp directory: ftp.netcom.com:/pub/hb/hbaker/home.html

Floating Point Number formats (Bowmer, RISKS-17.60)

Phillip C. Reed <reedpc@libbey.com>
Mon, 08 Jan 1996 08:26:11 -0500

> "Microsoft had their own floating point format for a while.
> What was it? Was it binary, too? Or did it have a BCD-type storage?"

Writing as somebody who once had to convert a database from an old Microsoft Fortran format to a more standard system, I can state with some authority that the floating point number format Microsoft used to use was indeed binary, and it was indeed some goofy format that nobody else used. I can't say whether it was subject to the same kind of inherent errors that the IEEE floating point format has, but it did have the generic floating point conversion problems.

Phil Reed Libbey, Inc reedpc@libbey.com

Reliable development methodology (Mellor, RISKS-17.60)

Andrew Robson <arobson@Gateway.Uswnvg.COM>
Mon, 8 Jan 1996 21:54:59 -0800 (PST)

Your article "Re: X-31 crash follow up" in RISKS-17.60 tends to trivialize the importance of development methodology for reliable systems in favor of more thoughtful programmers. While this attitude may be appropriate to your role in training programmers, I would hope that the majority of RISKS readers would not give it too much weight.

Locating the source of a design fault is not a futile waste of time in many cases. You do, however, have a clue as indicated by your parenthetical "except perhaps during an internal post-mortem to decide whose head is going to roll!" The identification of the source of the problem often determines who pays for the change, and perhaps pays damages for the failure. More importantly it can identify flaws in the development methods used and prevent future failures.

Your first point is very dependent on *who* thinks the flaw is obvious. For every user experience problem fixed, two problem reports get satisfied with a change to the documentation to remove reference to a non-existent feature deemed unimportant.

You may believe that "The omission of an obviously desirable feature IS A DESIGN FAULT." but the user will probably pay for an upgrade to get that feature.

What constitutes "required behaviour" *is* merely "what is in the specification" when deciding whether you have to pay the invoice, and usually in the test plan. Whether you get "WHAT A REASONABLE USER WOULD EXPECT" depends on the quality of both the vendor and the specification. If it is in the specification, it is likely to get tested and actually work correctly when needed.

High reliability systems cost much more to develop than systems that only need to work fairly well. I would prefer to anticipate this, and invest in attempting complete and accurate specifications, than to hope that every programmer will understand the big picture well enough to make their own design decisions. I would like the programmer to be rewarded for identifying a specification flaw to the designers, but proceed to build the design until it changes.

Andy Robson

New Security Paradigms '96 -- Call for papers

Yvo Desmedt <desmedt@cs.uwm.edu>
9 Jan 1996 02:25:06 GMT

PRELIMINARY CALL FOR PAPERS
NEW SECURITY PARADIGMS '96

A workshop sponsored by ACM SIGSAC, the Department of Defense, and the Aerospace Institute:
UCLA Conference Center
Lake Arrowhead, CA
September 16-19, 1996

Paradigm shifts disrupt the status quo, destroy outdated ideas, and open the way to new possibilities. This workshop explores radical new models for computer security, such as strategies for securing very large networks, providing software safety in large systems, and developing ethics in international cyberspace. The goal is to develop transcendent solutions that provide the flexibility and interoperability users require in trusted systems.

We offer a creative and constructive workshop environment for about 25 participants at the beautiful UCLA Conference Center on lake Arrowhead
in the San Bernardino Mountains, California. Dress is casual. The tone is exploratory rather than critical. The refereed papers will be printed in a workshop proceedings. To participate, submit either a research paper or a 5-10 page position paper, preferably via e-mail, to Program Chairs Catherine
Meadows and David Bailey at the e-mail addresses listed below by April 1, 1996. Alternately, submit five copies of a hard-copy paper to either
program chair by March 24, 1996. The Program Committee will referee the papers and notify authors of acceptance status by June 9, 1996.

Scholarships are available.

As it becomes available, more information will be provided on-line.
E-mail to: newparadigms96@itd.nrl.navy.mil
Use anonymous FTP from: chacs.itd.nrl.navy.mil
in directory /pub/newparadigms96
Use World Wide Web from:
http://www.itd.nrl.navy.mil/ITD/5540/acm/new-paradigms.html

NEW SECURITY PARADIGMS '96
WORKSHOP ORGANIZERS

Steering Committee: Hilary Hosmer, John Dobson, Catherine Meadows,
David Bailey

Workshop Co-Chair:
Tom Haigh, Secure Computing Corp., 2678 Long Lake Road, Roseville, MN
(612) 628-2738 (voice) (612) 628-2701 (fax) Haigh@sctc.com (e-mail)

Workshop Co-Chair:
Hilary Hosmer, Data Security Inc. 58 Wilson Road, Bedford, MA
(617) 275-8231 (voice and fax) Hosmer@dockmaster.ncsc.mil (e-mail)

Program Committee Co-Chairs:

Catherine Meadows Naval Research Laboratory
Code 5543 Washington, D.C. 20375
(202) 767-3490 (202) 404-7942 (FAX)
e-mail: Meadows@itd.nrl.navy.mil

David Bailey, Galaxy Computer Services PO Box 21069, Albuquerque, NM 87154
(505) 296-8805 (voice) (505) 298-4834 (fax)
daveb@gcsi.com (e-mail)

Program Committee:
Rebecca Bace, Department of Defense
Dimitris Gritzalis, Univ. of the Aegean
Deborah Hamilton, Hewlett Packard
Victoria Jones, Univ. of Illinois
Tom Lincoln, M.D., Rand Corporation
Ruth Nelson, Information System Security
Pierangela Samarati, Universita di Milano
Marvin Schaefer, Arca Systems
Jeff Williams, Arca Systems
Jim Williams, MITRE
John Yesberg, DSTO, Australia

Local Arrangements: Daniel Essin (UCLA) (213) 226-3188
Scholarships: Ravi Sandhu (George Mason University) (703) 993-1659
Publications Chair: Marv Schaefer, Arca Systems
Publicity: Yvo Desmedt (Univ. of Wisconsin) (414) 229-6762
Treasurer and Registration Chair: Dixie Baker (SAIC) (310) 613-3606
ACM SIGSAC Chair: Ravi Sandhu (George Mason Univ.) (703) 993-1659
ACM Senior Program Director: Julie Goetz (ACM, 1515 Broadway, NY) (212) 626-0610

Please report problems with the web pages to the maintainer

Top