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 16 Issue 70

Weds 4 January 1995

Contents

o GIF, UNISYS, and CompuServe
Tim Oren
o Datastream may be charged in Jan 1995
Mich Kabay
o Common Criteria Draft (0.9) on CD-ROM
Klaus Brunnstein
o Computer Addiction
Mich Kabay
o Virus Creation Labs
Andy S. Lopez
o Don't plot murder via cordless phone
Mich Kabay
o Cell phones in Israeli army
Mich Kabay
o Dense ordinateurs
Mark Stalzer
o Re: COBOL's 2-Character Year Field
Mark Brader
Walter Murray
Paul Robinson
o Info on RISKS (comp.risks)

GIF, UNISYS, and CompuServe

Tim Oren <TIMOREN@csi.compuserve.com>
04 Jan 95 14:51:09 EST
In 1987, CompuServe designed the Graphics Interchange Format (GIF)
specification for graphics files.  The GIF specification incorporated the
Lempel-Zev-Welch (LZW) compression technology on which Unisys Corporation
was independently pursuing a patent filing.  In early 1993, Unisys notified
CompuServe of patent rights granted to LZW.  At that time, CompuServe began
negotiating with Unisys to secure a licensing agreement.  This agreement was
reached in mid-1994, and CompuServe then initiated a process to secure a
similar license that would benefit its GIF developer community.

Following the agreement reached between CompuServe and Unisys, CompuServe
announced the Graphics Interchange Format (GIF) Developer Agreement, shortly
after its completion, on December 29, 1994.  This agreement is aimed at GIF
developers who are developing programs and shareware primarily for use in
conjunction with CompuServe.  The service offers a license to these
developers to use LZW technology in programs written to the GIF
specification.

CompuServe remains committed to keeping open the GIF 89a specification both
within CompuServe and in areas outside CompuServe.  CompuServe continues to
strongly support the use of the GIF specification in the entire online
community including the Internet and World Wide Web.  This agreement will be
transparent to end-users and will not result in any charges for people using
viewers or transmitting GIF images.

The agreement offers software and shareware developers who use the LZW
technology in their GIF programs protection under a software license that
CompuServe is authorized to grant under the agreement with Unisys.
Developers who choose to take advantage of this service would acquire the
rights to use the LZW technology in certain software and shareware developed
primarily for use in conjunction with CompuServe.  Developers who choose to
participate in this agreement within the implementation period will also
benefit in that Unisys has agreed not to pursue royalty claims for past use
of the LZW technology in GIF.  The implementation period has been extended
to January 31, 1995.

CompuServe has presented this new agreement as a service to its GIF
developer community.  Cost to developers will be a $1.00 one-time licensing
fee and a royalty payment of 1.5 percent or $0.15, whichever is greater, per
registered copy of a program containing the LZW technology.  CompuServe will
not profit from this service.

CompuServe encourages developers to work with Unisys directly if the GIF
Developer Agreement does not meet their needs.  Unisys is continuing to make
the LZW technology available to any interested parties under reasonable and
non-discriminatory terms.  Developers are not required to register with
CompuServe.  Registering with CompuServe is simply one option for addressing
the Unisys LZW patent issue.  Developers may want to consider consulting
with legal counsel.

CompuServe is committed to keeping the GIF 89A specification as an open,
fully-supported, non-proprietary specification for the entire online
community including the World Wide Web.  Whether they choose to register
with CompuServe or not, developers are encouraged to continue use the GIF
specification within their products.

A copy of the GIF Developer Agreement is available in the Library section of
the CompuServe Graphics Support Forum (GO GRAPHSUP) and will shortly be
posted to CompuServes World Wide Web page (HTTP:\\WWW.COMPUSERVE.COM).
Developers who are not developing software primarily for use in conjunction
with CompuServe should contact Unisys directly at: Welch Patent Desk, Unisys
Corp., P.O. Box 500, Bluebell, PA 19424 Mailcode C SW 19.

Sincerely,

Tim Oren,  CompuServe Vice President,  Future Technology


Datastream may be charged in Jan 1995

"Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com>
04 Jan 95 06:16:28 EST
The Reuter newswire reports on last year's Datastream case:

    RTw 94.01.03 05:55 EST
    Teenage hacker taps into U.S. defence secrets

    LONDON, Jan 3 (Reuter) - A British teenager allegedly hacked
    into sensitive U.S. government computers and was able to
    monitor secret communications over the North Korean nuclear
    crisis last spring, the Independent newspaper reported on Tuesday.

    The boy tapped into several defence computers for seven months
    in what U.S. officials conceded was one of the most serious
    breaches of computer security in recent years, the paper said.

The article continues with the following key points:

* The youngster posted the data on the Internet and was labelled
"Datastream" because of the volume of information he supplied.

* He "was finally caught by special U.S. investigators because he left
  his terminal on-line to a U.S. defence computer overnight."

* The child was arrested in July in Britain.

* "...[P]rosecutors are expected to decide this month whether he can
  be charged, the Independent said."

* "...[T]he U.S. Air Force Office of Special Investigations acknowledged
  the hacker could have accessed and read the Korean files.

M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn


Common Criteria Draft (0.9) on CD-ROM

Klaus Brunnstein <brunnstein@rz.informatik.uni-hamburg.d400.de>
Fri, 30 Dec 1994 13:58:25 +0100
German Information Security Agency (GISA, in German: Bundeasamt fuer
Sicherheit in der Informationstechnik, BSI) has prepared a CD-ROM containing
the draft (version 0.9) of the Common Criteria presently being issued by a
committee of experts from USA, Canada and European Union. This
(unclassified) version will be sent to every interested person together with
accompanying material guiding comments (deadline of comments: March 1,1995).
Interested experts should send a fax to

                   German Information Security Agency
                   Attention Dr. Kreutz
                   Post Box 20 03 63
                   D 53133 Bonn
                   FAX: +49-228-9582-427

Most regrettably, the CD-ROM is designed for PC work. When trying to mount
the CD-ROM in the mode usually adapt to read PC CD-ROM formats, we succeeded
to crash our SUN OS 4. As our SOLARIS systems have no CD-ROMs, we could not
test whether this may work. (Nice to crash insecUNIX with INFOSEC material :-).

Klaus Brunnstein (Dec.30,1994)

PS: I asked BSI whether we may offer the CDROM material via our ftp-site. BSI
    informed me that they wish to be sure that the letter with guidance to
    the comment process accompanies the CD-ROM so I cannot offer this material
    via ftp :-)


Computer Addiction

"Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com>
26 Dec 94 16:38:07 EST
The Associated Press newswire (via CompuServe's Executive News Service)
reports on addiction to computers on an article datelined 94.12.26 @ 00:00
EST:

  Computer Addiction

  By PATRICE GRAVINO, Associated Press Writer

  KANSAS CITY, Mo. (AP) -- It answers immediately and makes few demands. It
  can introduce you to new friends and lovers, entertain you, organize your
  bills and provide expert information about almost any topic.

  It's the nearly perfect companion: your computer.

  But many people, from industry experts to social scientists, are
  beginning to ask -- and debate -- whether there's such a phenomenon
  as "computer addiction" and whether it's becoming a problem.

The author goes on to cite several anecdotal cases:

o   A "former computer instructor in Kansas City" explains the breakup
of his 16-year marriage in part to the time he spent at his computer.

o   "[F]uturist Andre Bacard, a physicist and author based at Stanford
University in California, where he researches the social impact of
technology," reports several acquaintances who spend an inordinate amount of
time online.  Some "belong to a half-dozen computer networks, and they
log-on to one after another. Their entire social world is vicarious."  He
adds, "I think it both encourages and cultivates psychosis in many people."

o   Some psychologists report having to help parents pull their children
away from their computers because they are neglecting schoolwork and
withdrawing from social interactions not mediated by computers.

o   "Steve Spaw, a computer graphics consultant in Kansas City,"  reports
that he has to force himself not to spend _all_ his time with his system.

o   "Dr. James Donley, medical director of outpatient psychiatry at the
University of Kansas Medical Center in Kansas City, Kan.," reports few
obvious cases of computer addiction so far, but feels that there's certainly
a potential.  He draws parallels with the potentially excessive involvement
in the world of pets that some enthusiasts display.  He also points to the
"inherently self-centered" activity where "people have a fairly simple
relationship, where you can kind of predict or dictate what happens....  It
can be used as an avoidance of social relationships."  He argues that
susceptibility to computer addiction "more to do with their personalities
than with computers."

<<Comments by M.K.: As I have mentioned before, computer addiction, if it
exists, conforms to what University of Chicago Professor Mihaly
Csikszentmihalyi has defined as "autotelic" behaviour.  He describes this
complex of behavioural cues in his book, _Flow: The Psychology of Optimal
Experience_ (1990).  Harper & Row (New York).  ISBN 0-06-016253-8.  xii +
303.

Basically, his research suggests that highly enjoyable activities share certain
attributes (p. 48 ff):

o   Challenging activity that requires skills
o   Merging action and awareness
o   Clear goals an feedback
o   Concentration on the task at hand
o   Sense of control
o   Loss of self-consciousness
o   Transformation of time.

Flow is certainly not inherently dangerous; however, as in any human
experience, some outliers will cross the fuzzy boundaries from wholesome
involvement and commitment into crazy excess.  Perhaps it would be
appropriate for such people to glue timers to their computers!  I can
imagine someone writing a TSR which alerts them with a voice warning:
"Susan, it's time to stop using your computers now: you've been working
steadily for [fill in appropriate time limit] hours." <grin>

Have any RISKS readers experienced such involvement with computer programs
that they worry about the possibility of harmful effects on their relations
with others?  Do social relations through network communications supplant
live interactions?  Is there any reason to be any more concerned about
spending, say, three hours online in a multi-user dimension than three hours
chatting on the phone or--for that matter--three hours in one's own living
room serving a friend tea?<>

M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn


Virus Creation Labs

"ANDY S. LOPEZ" <75713.2205@compuserve.com>
04 Jan 95 12:12:43 EST
I recently bought a copy of a book called "The Virus Creation Labs" by
George C.  Smith (American Eagle, ISBN 0-929408-09-8) and it contains
material, bulleted below, which may be of interest.

----The hiring of a hacker called Priest (who programmed the Satan Bug and
    Natas viruses) by Norman Data Defense, the developer of anti-virus
    software.  The author writes that the initial job offer was carried
    by US Secret Service agents questioning the hacker after the agency's
    network was trashed by Satan Bug in 1993.

----A look back at the AIS Security Branch bulletin board system and the
    bruhaha surrounding its archive of hacker utilities and virus code.
    The coverage by the Washington Post and Associated Press is reviewed,
    and there are some interviews and comment from some of the people involved.

----A revealing look at the cozy relationship between some virus writers
    (who were looking for a little press) and some anti-virus software
    producers (who were looking for even more press and copies of the
    viruses in question).


Don't plot murder via cordless phone

"Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com>
31 Dec 94 06:50:38 EST
The AP newswire (via CompuServe's Executive News Service) for 94.12.30 @ 20:02
EST reports on a murder plot ruined by use of a cordless phone:

    Scanner Plot

    MEMPHIS, Tenn. (AP) -- A woman listening to a police scanner
    she had gotten for Christmas picked up a conversation over
    cordless telephones and heard what turned out to be a murder
    plot unfolding, investigators say.

The article explains that Donna McGee heard a woman and her boyfriend plotting
to kill the woman's husband and then collect insurance money.  As the family
gathered around in horror, "Mrs. McGee's daughter recognized a playmate's name"
and the family figured out "the identity of the intended victim."

Law enforcement officials said that because Mrs McGee was not purposely
zeroing in on a specific conversation but only scanning across the bands,
she had broken no laws in listening to the murder plot.

<<MK:  People who live in glass houses shouldn't throw binoculars.<>

M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn

  [Also noted by rjones@oz.net (Ry Jones).]


Cell phones in Israeli army

"Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com>
31 Dec 94 06:51:09 EST
>From the Reuter newswire 94.12.29 @ 15:07 EST (via CompuServe's Executive News
Service):

    JERUSALEM, Dec 29 (Reuter) - The Israeli army has taken its
    best shot at a formidable new foe -- an insatiable craze for
    cellular phones, which have fast become an essential extra
    in soldiers' kit.

The article explains that cell phones have become a problem for the army because
"soldiers, especially reservists, have begun taking them on army duty, vexing
commanders by making stock market deals and chatting to loved ones even during
live-ammunition exercises."

It is now forbidden to carry cell phones on duty and officers may "forbid a
soldier from having a cellular phone at all."

<<Comments from MK:  The article did not say, but RISKS and NCSA Forum readers
will agree, that using unencrypted cellular phones for _military_ matters would
be a serious mistake.<>

M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn


Dense ordinateurs (Mark Brader)

Mark Stalzer <stalzer@macaw.hrl.hac.com>
Tue, 3 Jan 1995 15:55:21 +0800
>Would English speakers have reacted equally strongly to a -- no pun intended
>-- comparable bug in the instructions for comparing and branching?  I think
>they would not.

On the contrary, it would be far worse: the computer would be accused
of not being able to make up its mind!

  -- Mark


Re: COBOL's Two-Character Year Field (Ballard, Risks-16.69)

Mark Brader <msb@sq.com>
Wed, 4 Jan 1995 01:50:34 -0500
 ->->-> Date: 01 Jan 95 21:30:57 EST
        From: Fred Ballard <72400.1525@compuserve.com>

Hmm... <grin> do you think the mail program that generated that header
was written in COBOL?  In fact, 8 out of 9 articles accepted for that
issue of Risks had Date lines with 2-character years!

Mark Brader  msb@sq.com  SoftQuad Inc.  Toronto


COBOL addresses date risks

Walter Murray <walterm@hprctbs3.rose.hp.com>
Wed, 4 Jan 95 10:18:53 -0800
I'd like to respond to a few statements made in RISKS-16.69.

Fred Ballard pointed out the risk of a COBOL program running near midnight
and retrieving the system date and time as two separate operations.  He
suggests looping, getting the date, the time, and the date again, to make
sure the date and time came from the same day.  I have used that technique
in all the code I have written, and have wondered whether anyone else
worried about such things.

The good news is that the COBOL language now provides a way to get the date
and time in a single statement.  The ANSI COBOL 1985 standard was officially
updated in 1989 with the Intrinsic Function module, which I believe many
vendors have implemented.  There is now a CURRENT-DATE function that
provides, with a single function reference, the system date, time, and local
time differential from Greenwich Mean Time (if known).

Several other of Mr. Ballard's concerns were also addressed in the same
addendum to the COBOL standard.  The CURRENT-DATE function returns the date
and time in a standard 21-character format that includes four digits for the
year.

Addressing the multiplicity of date formats in use, the updated standard
defines three: standard date form (YYYYMMDD), Julian date form (YYYYDDD),
and integer date form (a numeric value representing the number of days
counting from January 1, 1601, of the Gregorian calendar).  The standard
addresses date processing by providing functions to convert between integer
date form and the other two forms.

In summary, the COBOL language has addressed the problems.  Now it's up to
COBOL programmers to learn and start using what the language provides.

Walter Murray


Re: Dates and Times Not Matching in COBOL

Paul Robinson <paul@tdr.com>
Tue, 03 Jan 1995 22:41:12 -0500 (EST)
Fred Ballard <72400.1525@compuserve.com> writes:
> There is no way to obtain the system date and time in one statement in COBOL.

Because most operating systems separate the request for time from the
request for date.  I can't think of any system where the date and time
are returned in a single request; there probably are but I can't think of
any.  OS/MVS on IBM mainframes, Decsystem 20 on Digital Mainframes, RSTS/E
and RT11 on Digital Minicomputers, MSDOS, VS/9 on Univac Mainframes, none
of these returned date in the same call as time.

> The only way in a COBOL program to assure that the time
> obtained is for the date obtained is to loop getting the date,
> then the time, and then the date again until both dates match
> (as would usually be the case).

I guess it's because with the exception of batch jobs being run at that
time, most jobs run at some time other than exactly midnight - usually it's
during business hours - and thus the problem only exists for two minutes of
the day, e.g. during the one minute before midnight and the one minute
after.  The other 1438 minutes of the day, it's not a problem.  Actually
it's less than that.  The problem is during the last one second of the last
minute of the day and the first second of the first minute of the next day,
since unless the call for date and time occurs exactly at that precise
instant, and that one of them occurs just before 00:00:00 and the other just
after.  This means, that during 86,398 seconds of the day this isn't an
issue, and is during "alpha and omega, the first and the last", is when the
problem occurs.

This sort of issue pops up so rarely that it's not something one thinks
about much.  In fact, a lot of reports print date only, so the time doesn't
matter one way or the other.

> I haven't heard of any problems actually caused by this, but the potential
> risk is there as it is in any language that makes accessing the date and
> time simultaneously impossible.  (I believe BASIC shares this problem with
> COBOL.)

I captured a print out from running GW Basic:

  Ok
  PRINT TIME$
  22:33:44
  Ok
  PRINT DATE$
  01-03-1995
  Ok

The question is how fast is the timing here.  Just how many date and time
requests can a basic program issue in one second.  Using an MSDOS version
of BASICA under MSDOS 6.0 running on an AMD 386 DX 40 with turbo on, I wrote
the following program, called "TICK.BAS":

110 REM FIRST START WITH A NEW SECOND
120 T1$=TIME$
130 IF T1$=TIME$ THEN 130
135 REM NOW COUNT NUMBER OF ACTIONS IN ONE SECOND
140 J = 0 : T1$=TIME$ : D1$=DATE$
150 T$=TIME$ : D$=DATE$
160 J = J+1 : IF T$=TIME$ THEN 160
170 PRINT J

When I ran this program, twice, the printed result was:

3023

Basica typically isn't fast, yet in one second, this program, running in
Interpreted basic, issued 3023 date and time requests.  Actually, it
issued 3023 date requests and 6046 time requests.  This means that, for
example, on a computer such as mine, it has to be issuing a request for
the date and the time during the 1/3023rd of one second between the last
second of one day and the first second of the next.  If there is even
2/3023rds of a second before midnight, there would be enough time to get
both date and time in the same second:

A#=1/3023 : PRINT USING "##.##########";A#
0.0003307972

Or a 3 in 10,000 chance of this happening in the cases of someone running
a program in Basic which would hit within the time required to cause an
error of this type.  And in a compiled language the chance is even less
since the time to do two MSDOS calls.

Using Turbo Pascal 6, I wrote the following file called "TICK.PAS":

uses dos;
var yr,mo,day,dow,
    hr,min,sec,tick,
    hr2,min2,sec2,tick2:word;
    I:longint;

BEGIN
   getdate(yr,mo,day,dow);
   gettime(hr,min,sec,tick);
   repeat
       gettime(hr2,min2,sec2,tick2);
   until sec2<>sec;
   I := 0;
   repeat
       gettime(hr,min,sec,tick);
       inc(i);
   until sec <> sec2;
   writeln(i:1);
end.

The results I got for this were: 6767, 6229, 6229, 6575, 6571, 6201,
6205, 6202, 6228, 6575, 6229, 6228, 6229, 6574, 6229, 6575, 6229, 6571.

Figuring worst case at 6200 tests, it means that there would have to be
less than 2/6200 of one second before midnight for the possibility of
this happening.  1/6200 of one second means that if a program of this
type was executed every day in such a manner as to cross midnight, during
the moment the date and time were collected, the chances are an error of
this type happening would strike one execution every 16.9 years, since
it can only happen once a day, and it can only happen during the 1/6200
of a second before midnight.

No wonder I never thought about such a thing.  It may be crass to put it
this way, but how many people worry about an error that *might* happen
once every 16.9 years?

Please report problems with the web pages to the maintainer

Top