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 80

Tuesday 27 February 1996

Contents

o 100 kept in Philadelphia jail after case disposition
Bob Witanek
o SurfWatch vs. NYNEX
David B. Slifka
o CFP: IEEE Software Special Issue on Risk Management
Tom DeMarco
o Re: The Risks of Sleeping Dogs
Peter Ladkin
o Risks of year-2000 precautions
Mark Brader
o Real `bug' in Alpha VAX
Chaim Seymour
o Re: Li Gong's posting on Mac file deletion
Martin Minow
o Re: Java security
Drew Dean
o Re: Risks of Contributing to Risks
Derek Lyons
o Re: Publishing and the Web
H. Koenig
o Nerd processing
Pete Mellor
o Windows 3.11 Data Loss Problem
Dave Robinson
o WordPerfect Replaces text you wrote with its own
John Haseler
o Empty Word Doc Space
J Grant
o Re: Risks of using Microsoft Word
Rich Mulligan
o More RISKS of Using Microsoft Word
Mark Thorson
o Info on RISKS (comp.risks)

Philly - 100 Kept In Jail after case disposition

Bob Witanek <bwitanek@igc.apc.org>
Mon, 26 Feb 1996 21:13:27 -0800 (PST)

  [From pol-abuse <pol-abuse@igc.apc.org>
  Posted dadoner@chesco.com  Sun Feb 25 06:25:48 1996
  http://www.phillynews.com/inq/city/JAIL25.htm]

  Clerical glitch kept dozens in jail too long:
  Up to 100 people stayed in Phila. jails after judges had freed them.
  By Suzanne Sataline
  [PGN-Abstracted From the Philadelphia Inquirer: City & Region, 25 Feb 1996]

As many as 100 citizens were locked in Philadelphia's overcrowded jails for
weeks and months after judges had ordered them freed.  Sentences, paroles,
work releases, and drug rehabilitation orders remained unrecorded for
several weeks, mostly from a single courtroom (Rocket Docket) specializing
in disposing of something like 150 cases each day.  Apparently, the
paperwork was generally OK.  However, after a lot of finger pointing, it
seems that the paper orders were not being entered fast enough into the new
computerized system, and that that system was the driving force for putting
orders into effect.


SurfWatch vs. NYNEX

David B. Slifka <davids@mail.nltl.columbia.edu>
Sat, 24 Feb 96 22:15:03 EST

I went to NYNEX's page looking for ISDN information, and attempted to open
the appropriate link. For whatever reason, NYNEX's ISDN page is named
"iixxxpg1.html." SurfWatch, deftly noting the "xxx," decided I was trying to
access something naughty and blocked the page.

This might not be so problematic for just one page, but a large number of
NYNEX's pages have the forbidden xxx in them. Not just potential ISDN
buyers, but those requesting information on phone cards, home products,
NYNEX grants, towns which NYNEX serves, business and home-office services...
Anyone running SurfWatch will be blocked from all of this information.
Granted, there are far more pages with xxx in their names that contain
questionable material, rather than NYNEX info. But it is an issue that
people--especially large companies who want as wide an audience as
possible--now have to keep in mind.

David


IEEE Software CFP: Special Issue on Risk Management

Tom DeMarco <tdemarco@shore.net>
Sun, 25 Feb 1996 10:38:12 -0400

IEEE Software seeks articles for this special issue, scheduled for
publication in May, 1997.  Software development is an inherently risky
business, but risk is not spread evenly over all software projects.  The
most risk-prone projects are likely to be the very ones to offer the most
attractive opportunities.  The tradeoff between risk and opportunity must
necessarily involve a disciplined approach to the capture, assessment and
tracking of risks.  This special issue will focus on the practice of
software risk management.

We seek original articles on:
o       case histories of risk management in action
o       risk assessment and tracking tools
o       legal and social issues pertaining to risk
o       software risk management in practice

Authors should present their work in terms that are useful to the software
community at large, emphasizing lessons learned.  Please submit one
electronic copy in RTF interchange format or eight printed copies by
August 1, 1996 to either of the special issue editors:

Barry W. Boehm                  Tom DeMarco
TRW Professor                   The Atlantic Systems Guild
University of So. California
Computer Science Department     PO Box 160
Los Angeles, CA  90089-0781     Camden, Maine  04843
T: 213 740-8163                 T: 207 236-4735
F: 213 740-7285                 F: 207 236-8432
boehm@pollux.usc.edu            tdemarco@shore.net

Articles should be 10-20 double-spaced pages, including illustrations.
Submissions are peer-reviewed and are subject to editing for style, clarity,
and space.  For detailed author guidelines, contact Angela Burgess, IEEE
Computer Society, PO Box 3014, Los Alamitos, CA 90720; fax 1 (714) 821-4010;
aburgess@computer.org.

===Tom DeMarco, The Atlantic Systems Guild: tdemarco@shore.net===


Re: The Risks of Sleeping Dogs (Shaw, RISKS-17.71)

<ladkin@TechFak.Uni-Bielefeld.DE>
Sun, 25 Feb 1996 17:36:48 +0100

>[Perhaps this explains (in part) the
>number of articles regarding air safety in comp.risks ;-) ]

Not content to let them lie, Shaw has suffered the consequences. His note,
with follow-ups in RISKS-17.72, is included in my `Incidents and Accidents
with Fly-By-Wire Commercial Aircraft' Compendium:
   http://www.techfak.uni-bielefeld.de/~ladkin/

New items of potential RISKy interest are:

*) Three papers which discuss the notion of `cause' and use as examples the
   X-31 accident and the Warsaw A320 accident:

  1. `The X-31 and A320 Warsaw Accidents: Whodunnit?' by Peter Ladkin, which
  discusses articles from RISKS (16.89, 17.45, 17.46, 17.47, 17.60) and
  elsewhere.

  2. `A Model for a Causal Logic for Requirements Engineering', by Jonathan
  Moffett, Jon Hall, Andrew Coombes and John McDermid, to appear in the
  Journal of Requirements Engineering.

  3. `Reasons and Causes' by Peter Ladkin, which continues discussion arising
  from the first article, and comments extensively on Moffett et al.

*) The full text of AAIB Bulletin 3/95, reported on in RISKS-16.92 and 16.96.

*) `Computer-Related Factors in Incident to A320 G-KMAM, Gatwick on 26 August
    1993' by Peter Mellor, which comments on the incident reported in
    AAIB Bulletin 2/95.

*) The NTSB Press Release on the December 1995 B757 Cali accident;
   `Comments on Confusing Conversation at Cali' by Dafydd Gibbon and Peter
   Ladkin, which comments on some linguistic features of the ATC/pilot
   communications as reported in the NTSB Press Release.

(Concerning Cali: a limited analysis only is possible from the Press
Release. The FMS may be peripherally involved, since I understand the pilots
were using it to obtain navigational information just before impact, and the
turn which led to impact was initiated by an autopilot selection. This by
itself wouldn't justify RISKy comment. However, there has been discussion in
the non-specialist press and on some newsgroups about other aspects of the
accident so I thought it as well to include some available reliable info.)

Planned to appear shortly:

*) Clive Leyman has just finished an analysis of the braking distances
   at Warsaw, which I hope will be available before March 1.

*) a summarised version of AAIB Bulletin 2/95 (see above).


Risks of year-2000 precautions (Re: Lesher, RISKS-17.79))

Mark Brader <msb@sq.com>
Sat, 24 Feb 1996 03:46:08 GMT

David Lesher (wb8foz@netcom.com) writes:
> I'm beginning to seriously consider that advice [Dyson?] to withdraw
> ALL your money on 30 Dec 1999 & keep it cash for a day or two....

Now there's risk of the year 2000 that I hadn't thought of.

What if *lots* of people take that advice seriously, and as December 1999
passes, there are increasing intense runs on all the banks?  Now throw in a
few news reports of particular banks whose cash reserves run low to the
point of possible failure -- and add to that the even faster Net of 3 years
from now, and its even greater ability to propagate misstatements ahead of
their corrections.

A vicious circle follows, and banks start collapsing left and right -- a
process ended only after massive economic damage by government intercession
in the form of a Rooseveltesque banking holiday.  (One which incidentally
extends into 2000, giving the surviving banks time to detect and correct
their remaining serious bugs, so the computer-disaster scenario that
started the process is forestalled after all.)

Do I believe it?  Well, no.  Do I believe it *couldn't* happen?  Well, no.
Do I intend to withdraw all my money in *November* 1999?  Well, no...

Mark Brader  SoftQuad Inc. Toronto   msb@sq.com


Real `bug' in Alpha VAX

Chaim Seymour <seymour@ashur.cc.biu.ac.il>
27 Feb 1996 08:03:37 GMT

On Sunday, 25 Feb 1996, the Bar-Ilan University Library Alpha VAX was
working with only one third of the cpu.  An attempt to reboot stopped the
computer completely.  The Digital technician changed the memory board and
found a real dead bug in the old board.  It seems that even the best of
computers are not bug proof.

Chaim Seymour, Chairman, Cataloguing and Classification Department
Wurzweiler Library, Bar-Ilan University, Ramat Gan 52100 Israel   03-5318127


Re: Li Gong's posting on Mac file deletion (RISKS-17.79)

Martin Minow <minow@apple.com>
Sun, 25 Feb 1996 14:27:42 -0800

In an offline correspondence, Li Gong noted that the circumstances when
files were accidentally deleted after pressing the space bar were somewhat
unclear, including a system upgrade and system disk formatting, so this may
have been a one-off incident. In any case, neither Li Gong nor I were able
to reproduce the problem.  Please note that I am in no way suggesting that
this incident did not happen.

The Macintosh has an extremely robust file system (especially given its
design and usage constraints) with some automatic repair capability.  If it
appears that something may have been lost, I recommend that users run the
Apple "Disk First Aid" utility, which can repair many file system
inconsistencies. Also, there are third-party utilities, such as Symantec's
"Disk Doctor" that repair and test an additional set of problems, including
hardware errors and bizarre file creation dates, that Disk First Aid does
not address.

In all circumstances, however, the best remedy is to realize that these
problems can happen, and use a consistent backup strategy to provide
reasonable assurance against data loss, whether by operating system glitches
or one's own dumb mistakes. Indeed, in our offline correspondence, Li Gong
noted that the missing files were quickly recovered from a recent backup.

Martin Minow, Apple Computer Inc. minow@apple.com

   [Thanks to the many of you who also responded on this curiosity.  PGN]


Re: Java security (Mueller, RISKS-17.79)

Drew Dean <ddean@CS.Princeton.EDU>
Sun, 25 Feb 1996 22:41:53 -0500

We do not view the risks of the Java problem (RISKS-17.77) in the same light
as Sun.  Please see http://www.cs.princeton.edu/~ddean/java for our rebuttal
to Sun's reply.

Drew Dean <ddean@cs.princeton.edu>
Ed Felten <felten@cs.princeton.edu>
Dan Wallach <dwallach@cs.princeton.edu>


Re: Risks of Contributing to Risks (Comeau, RISKS-17.79)

Derek Lyons <elde@hurricane.net>
Tue, 27 Feb 1996 03:31:41 GMT

> ... Playboy now prints the e-mail addresses of people who send electronic
> Letters to the Editor.  If I send Playboy anything in the future, I will
> be sure to send it on paper.

Most publications that accept 'Letters to the Editor' via e-mail will, on
request, publish only the traditional Name,City,State.  But ONLY IF YOU ASK.
Risk?  Never assume nuthin' ....


Re: Publishing and the Web (Seecof, RISKS-17.77)

H.Koenig <hkoenig@halcyon.com>
Wed, 21 Feb 1996 13:55:10 -0800

>If I were going to censor anything about the WWW, it would be the use,
>by those of us who should know better, of the term "publish" to
>describe the act of making data available from a server.

While publishing isn't the only purpose of web pages, publishing is exactly
the purpose of my web pages. My goal was to make information available to
others and to distribute it. This is what a publisher does. I do not
interact with any viewer or reader, and have no desire to do so. If I didn't
use the Web, then I would have had put together a booklet or pamphlet.

>Most people do not understand that surfing the net is much more like
>placing 'phone calls than reading a magazine found lying on a chair.

No, it's more like wandering through a library or bookstore, looking at the
spines or covers, and occasionally opening a book up to decide if its the
one you're looking for.

> Publishers are required to register with the government, for goodness' sake.

This is not true in the United States. Except for business licenses for tax
purposes, or for special mailing rates, the registering of publishers would
(and should) get immediate response, not just from publishers organizations
but from the ACLU. I can (and do) publish a newsletter without getting
anyone's permission.

>Magazines may be mailed to non-subscribers; but only computer geeks
>know that the images on the web-browser's screen appear only when the
>user calls for them.

This is akin to saying that the pages of a book are blank until I turn to
them. The information that is used to create a particular web page exists on
its server independent of the number of people who happen to be viewing it
at any one time.

>Links to other folks' pages are akin
>to giving out a 'phone number--no one who does so should be thought
>responsible for any message which may be heard by calling it.

Wrong again, they are more like giving out a card catalog number, ISSN,
ISBN, or simply a book's title. A list of links is like a bibliography.
All, including URLs, describe how and where to find a particular
publication or source of information. And like a book, magazine or
newsletter, no one sees my web pages unless they make an effort and
decision to see them, by clicking on the link or typing it in.

There seems to be an attempt here to split semantic hairs, confusing the
fact that while information may exist on the server, it can only be read
through a client. The only novel item introduced by the Web in the
publisher/reader relationship is that the information presented is sent on
demand (and perhaps individually tailored) to the person requesting the
information.

-HK  hkoenig@halcyon.com


Nerd processing

Pete Mellor <pm@csr.city.ac.uk>
Tue, 27 Feb 96 12:03:40 GMT

I have been working on a large document for the British Standards
Institution. They use Word 6, and provided me with a diskette containing the
latest master so that I could make my amendments electronically.

One thing that had surprised me about the printed draft was that the words
"reliability's" and "non-conformance's" occurred all over the place, whereas
I had originally written "reliabilities" (as in: "The same software may show
different reliabilities on different installations.") and "non-conformances"
(as in: "The purpose of Fagan inspection is to detect non-conformances
between code and design before these become faults in the delivered
software.").

When I ran the Word 6 spelling checker, the reason became obvious.  The
dictionary did not allow for a plural of either of these words.  The typist
who had originally input my text had taken its suggestions at face value and
done a global change.

The checker also insisted that I was either "Mellow" or a "Melon", and that
M.E. Fagan of inspections fame was either a "Pagan" or a "Fagot"! :-)

Peter Mellor, Centre for Software Reliability, City University, Northampton
Square, London EC1V 0HB, UK. Tel: +44 (171) 477-8422, p.mellor@csr.city.ac.uk


Windows 3.11 Data Loss Problem

Dave Robinson <Amber_computer@mindlink.bc.ca>
Tue, 27 Feb 1996 09:07:15 -0800

This problem has been independently verified by other WFW 3.11 users.
We have a mail file on the subject, including a message from
Rick Mayell[101323,2073] , Project Engineer, South Western Electricity.

It appears to be verified by Microsoft (obliquely) in Document Q110092.

Subject: Data loss: VCACHE with BDE, problem??
         Windows For Workgroups Caching Problem

This problem was discovered using Borland Delphi, however the engine
is the same, and the same problem may be apparent on Paradox...

We have discovered a problem where the WFWG 3.11  VCACHE caching
mechanism appears to stop committing data to the local hard-drive
and is lost following a hard reset or power-off. Disabling 32-bit
access and using Smartdrv appears to correct the problem (see note 5).

Known factors:

(1) We have so far only observed the problem when the system is running
    our application which is written in Delphi 1.0 and uses the Borland
    Database Engine (BDE) ver 2.51a. Note: The BDE cache is NOT the
    cause of the data loss (see point 3). We have not been able to
    determine whether it also occurs without our application running.
    If our app or the BDE causes VCACHE to fail - we have not been
    able to determine how this occurs since it seems to happen
    somewhat randomly (?)

(2) A significant amount of data can be lost - even several hours worth
    - so this is not the effect of write-behind cached data that has
    not yet had the opportunity to commit at the time of reset. Our app
    can sit idle for an hour and still lose cached data.

(3) The Borland Database Engine caching mechanism is NOT responsible
    for the data loss.
      Evidence:
       -after each data post, each table in our app is closed and/or
          flushed from the BDE cache using the dbiSaveChanges engine
          call
       -data is also lost from text output files written to with the
          Pascal writeln command
       -data is lost from all other running apps (see Notepad example
          below)

(4) When VCACHE fails... all running apps fail to commit data to the
    local drive. We tested Notepad running concurrently with our app -
    periodically editing and saving a file from Notepad as we worked
    on our app. After reset data added after a given point in time is
    not included in the file. The time of failure to save data is the
    same time as for our app and all other running apps. The Progress
    Runtime client also acted this way in a similar test.

(5) When 32-bit file access is disabled, and only Smartdrv is used to
    cache data - this problem DOES NOT exist - even when write-behind
    caching is enabled (of course, in this case,  the last 5-seconds
    worth of editing will be lost). This suggests that even if our
    app or the BDE causes the failure, then VCACHE is somehow
    vulnerable in a way that Smartdrv is not. The problem does not
    exist in Windows 3.10 or 3.11 (non-Workgroups) - since these do
    not use VCACHE/32-bit file access. We have not tested the
    behaviour yet under Windows 95.

(6) We have identified this problem using two fairly different
    computer systems (one DEC and one Acer) - both running
    WFWG 3.11 on a Novell 4.10 network (all patches installed)
    with recent VLMs (version 1.20a).

(7) Data written to network volumes is NOT lost (of course, this
    data is not cached by VCACHE)

(8) All the running apps seem to behave "as normal". not reporting
    errors. Note: when the apps write data - they can re-read it
    back successfully even though this data will be lost after reset,
    therefore, the data does exist in the cache as valid data -
    the data just has not been flushed to the disk.

(9) The problem seemed to be connected to low USER resources (<40%)
    - however, we have reproduced it with fairly high (>55%) levels
    so we are not sure if there is really a connection.

 Does anyone recognize this problem ???

 Thank you, in advance, for any help.

Contacts:

amber_computer@mindlink.bc.ca

     Ted Sorensen, Systems Analyst / Programmer, Amber Computer Systems Inc.
or   Dave Robinson, VP Development
     Ph: 604 599-9167  Fax: 604 599-9261


WordPerfect Replaces text you wrote with its own

John Haseler <jhaseler@cix.compulink.co.uk>
Sat, 24 Feb 96 23:31 GMT

WordPerfect has a feature that generates a table of contents at a chosen
place (at the front by default).  I had a long report which needed this
feature, and to see whether I had marked enough text to make a sensible
contents list I generated the table with only the 'body' of the report
entered.  It worked well.  I then went to work to add the conventional pages
before the TOC - summary, title sheet, and so on.  When this was done I
started improving the body, and in due course needed a new TOC.  Result:
summary, title sheet, and so on all disappeared.

What WPF does is to mark a section of text as 'generated' using marker codes
which you don't normally see.  When you generate a TOC, it removes all the
text between these markers and inserts what it creates.  Unfortunately,
moving to 'top of text' can get you above the TOC but (just) within this
marked area.  Result: anything you have put there gets wiped out next time
you do a 'generate'.  Pretty obvious when you look into it - but infuriating
to a learner.

John Haseler


Empty Word Doc Space

<jgrant@namsa.nato.int>
Mon, 26 Feb 96 9:31:48 CET

The current thread, about Word using disk space without initializing it,
seems not to be a Word problem, but an OLE problem and thus would apply to
all applications that use OLE2.  I have noted this problem with Word on my
own workstation.  Additionally, Microsoft has addressed this problem and a
fix is available for Win 95 users in the recently released Win 95 Service
Pack.  I believe that the OLE2 update is also available as a single file
download from ftp.microsoft.com.

I am not defending Microsoft's products in any way.  I use them because I
have to and I don't care about which vendor's product is "better" as long as
the one I have allows me to get the job done effectively.  It appears that
the Microsoft fix does indeed work and we may now direct our thoughts to
other topics.  I am also surprised that Microsoft addressed this problem so
quickly!  ;-)


Re: Risks of using Microsoft Word (RISKS-17.76)

Rich Mulligan <rich.mulligan@trw.com>
Thu, 22 Feb 1996 17:15:08 -0700

Several authors have noted the presence of "extra data" within Microsoft
Word files.  These are frequently found in files that use the "Quick Save"
feature of Word.  Here a document is first saved as a baseline and
subsequent saves will only update it with the changes.  Another feature of
Word is the "Undo" command.  Any text that is deleted from the document can
be "Undone" up to the point of the last save.  Thus an "Undo" cannot
retrieve text from a previous increment of the document.  However, all of
the deleted text is still within the original document.  This can be
verified with a disk editor.  The best way to remove this undesired text is
to user the "Save As" command create a new document.  All of the deleted
text is left behind in the original document.  The obvious risk is taking a
classified document and trying to remove classified data to create an
unclassified document.  Unless a new document is created, all the deleted
data is still part of the "unclassified" document.  Word will not display
the deleted text, but a disk editor or non-Word word processor will be able
to display it.

On another note, the problem of extra data found between the end of file
mark and the end of sector has been around since the beginning of DOS.  DOS
will fill the space with random data from memory.  I have seen disk
directory data and parts of documents in that space.  This also is a problem
when unclassified files were copied from a classified machine onto a floppy
disk.  Special utilities were created to zero fill these "slack bytes" as
they were called.

The bottom line is, if you want to be sure that unintended data is not
included in a Word document, check it with a disk editor.  They usually have
an ASCII/HEX find feature that will scan the file.  It will find any text in
a document that Word refuses to display on the screen.  The disk editor will
also display the slack bytes in a file.  These procedures are needed only if
you have very sensitive data that should not be disclosed.

Rich Mulligan  rich.mulligan@trw.com
TRW Space & Electronics Group, Redondo Beach, California, USA

   [Lots of submissions on this topic.  Just one more follows.  PGN]


More RISKS of Using Microsoft Word

Mark Thorson <eee@netcom.com>
Sat, 24 Feb 1996 14:46:09 -0800

I came across an interesting security problem with Word not too long ago.  I
was preparing a highly confidential document for release to the licensees of
the technology of the company I work for, and the company lawyer had given
me a paper stack of pending patent application abstracts.  I was to format
these and include them in the document I was preparing.  For each patent
application, there was a figure and a single paragraph.

I also got the same information on disk.  I would edit the disk information
into my document and reserve white space for where the figures would be
pasted in.  I was given paper copies of the text, so I could match up the
stuff on disk with the paper figures.

A funny thing happened when I opened up the file on my Mac.  The Mac version
of Word is always downrev from the PC version, and so I lost all the
formatting of the file.  That's okay because I was going to re- format it
anyway.

But even after stripping out all the formatting information which had become
garbage, the text itself was slightly mutilated, with large blocks of text
in out-of-order sequence.  Fortunately, I had the paper copies, so I could
reconstruct the file fairly easily.

But then I discovered I had something like a dozen paper figures and
paragraphs, but more like 20 paragraphs in the disk file.

The next day, when I asked the lawyer whether he had forgotten to give me
paper copies of some of the stuff on disk, he was surprised I had those
extra paragraphs.  Those were for patent applications that hadn't even been
filed yet, and were definitely NOT for release to the licensees before then!

What happened was he had taken a larger file, edited out the stuff I wasn't
supposed to see, then copied the file to a floppy.  I converted the file to
the Mac, and reconstructed the original file.

When you save a file in Word, it usually does a "fast save".  That means a
small amount of information is saved that tells Word what changes you made
to the original.  That's faster than actually re-writing the whole file.

You can disable this "feature".  I suppose Microsoft should make that as the
default.  Or, you can do a "Save As", which will force the true file to be
written out.

Mark Thorson (eee@netcom.com)

Please report problems with the web pages to the maintainer

Top