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

RISKS-LIST: RISKS-FORUM Digest  Weds 4 January 1995  Volume 16 : Issue 70

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

***** See last item for further information, disclaimers, etc.       *****

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

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

Date: 04 Jan 95 14:51:09 EST
From: Tim Oren <[email protected]>
Subject: GIF, UNISYS, and CompuServe

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

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

Date: 04 Jan 95 06:16:28 EST
From: "Mich Kabay [NCSA Sys_Op]" <[email protected]>
Subject: Datastream may be charged in Jan 1995

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

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

Date: Fri, 30 Dec 1994 13:58:25 +0100
From: Klaus Brunnstein <[email protected]>
Subject: Common Criteria Draft (0.9) on CD-ROM

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 :-)

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

Date: 26 Dec 94 16:38:07 EST
From: "Mich Kabay [NCSA Sys_Op]" <[email protected]>
Subject: Computer Addiction

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

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

Date: 04 Jan 95 12:12:43 EST
From: "ANDY S. LOPEZ" <[email protected]>
Subject: Virus Creation Labs

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).

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

Date: 31 Dec 94 06:50:38 EST
From: "Mich Kabay [NCSA Sys_Op]" <[email protected]>
Subject: Don't plot murder via cordless phone

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 [email protected] (Ry Jones).]

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

Date: 31 Dec 94 06:51:09 EST
From: "Mich Kabay [NCSA Sys_Op]" <[email protected]>
Subject: Cell phones in Israeli army

>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

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

Date: Tue, 3 Jan 1995 15:55:21 +0800
From: [email protected] (Mark Stalzer)
Subject: Dense ordinateurs (Mark Brader)

>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

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

Date:   Wed, 4 Jan 1995 01:50:34 -0500
From: [email protected] (Mark Brader)
Subject: Re: COBOL's Two-Character Year Field (Ballard, Risks-16.69)

->->-> Date: 01 Jan 95 21:30:57 EST
       From: Fred Ballard <[email protected]>

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  [email protected]  SoftQuad Inc.  Toronto

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

Date: Wed, 4 Jan 95 10:18:53 -0800
From: Walter Murray <[email protected]>
Subject: COBOL addresses date risks

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

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

Date: Tue, 03 Jan 1995 22:41:12 -0500 (EST)
Subject: Re: Dates and Times Not Matching in COBOL
From: Paul Robinson <[email protected]>

Fred Ballard <[email protected]> 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?

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

Date: 22 December 1994 (LAST-MODIFIED)
From: [email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

The RISKS Forum is a moderated digest.  Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from 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.  U.S.
users on .mil or .gov domains should contact <[email protected]>
(Dennis Rears <[email protected]>).  UK subscribers please contact
<[email protected]>.  Local redistribution services are
provided at many other sites as well.  Check FIRST with your local system or
netnews wizards.  If that does not work, THEN please send requests to
<[email protected]> (which is not yet automated).  SUBJECT: SUBSCRIBE
or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent]

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.  PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them.  Contributions will not be ACKed; the load is
too great.  **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks.  Anonymized mail is not accepted.
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.
All other reuses of RISKS material should respect stated copyright notices,
and should cite the sources explicitly; as a courtesy, publications using
RISKS material should obtain permission from the contributors.

CURRENT ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>YourName<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.
Issue J of volume 16 is in that directory: "get risks-16.J<CR>".  For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 15, J always TWO
digits) for Vol I Issue j.  Vol I summaries in J=00, in both main directory
and I subdirectory; "bye<CR>"  I and J are dummy variables here.  REMEMBER,
Unix is case sensitive; file names are lower-case only.  <CR>=CarriageReturn;
UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username,
password; [email protected] and WAIS are alternative repositories.
Risks can also be read on the web at URL http://catless.ncl.ac.uk/Risks
  Individual issues can be accessed using a URL of the form
  http://catless.ncl.ac.uk/Risks/VL.IS.html
  (Please report any format errors to [email protected])

FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving
it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info
regarding fax delivery.  PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL
RISKS COMMUNICATIONS; as a last resort you may try phone PGN at
+1 (415) 859-2375 if you cannot send E-mail to [email protected] .

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

End of RISKS-FORUM Digest 16.70
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.