Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
Ming Jyh Hsieh, 38, a computer product support engineer who had been fired for ``nonperformance'' by the Wollongong Group in Palo Alto CA in November 1987, was caught in the act while downloading Wollongong-proprietary software to her PC. She used the ``secret password'' and privileges that were still valid two months later, and spent 18 hours over several nights copying software. Police placed a ``trap and trace'' device on Wollongong's computer phone lines to identify her phone line. [Source: Palo Alto Times Tribune, 7 February 1988] A few comments are in order. (1) A password is not secret when it is known to more than one person; in this case, it was shared among at least 5 people. (Shared passwords are generally a bad idea.) (2) A password is not necessarily secret even if it is kept private by one person. Exposures (stored unencrypted, transmitted unencrypted, derivable, guessable, etc.) are often very easy to obtain. (3) It is extraordinarily bad practice to fire someone and then not change all relevant passwords, revoke their privileges, etc. (4) This kind of problem of nonrevoked privileges seems to happen amazingly often.
Thie following is a notice posted to Compu$erve's HyperCard forum in the
last 24Hrs... I think this is the first occurance of a live (as opposed to the
sources I mentioned in my last note) virus on the Macintosh (in North America):
I might mention, that based on the sources that were posted to Compu$erve
(please don't send mail asking for copies, requests will be politely, but
firmly, rejected), and the description of the virus below, it is possible that
the posting of the sources directly contributed to this (new?) virus...
Pretty Scary....
David
David HM Spector New York University
Senior Systems Programmer Graduate School of Business
Arpa: SPECTOR@GBA.NYU.EDU Academic Computing Center
UUCP:...!{allegra,rocky,harvard}!cmcl2!spector 90 Trinity Place, Rm C-4
MCIMail: DSpector/Compu$erve: 71260,1410 New York, New York 10006
AppleLink: D1161
= = = = = = F r o m — C o m p u S e r v e = = = = = =
CompuServe APPHYPER
One moment please...
Welcome to MAUG(tm):HyperForum, V. 4C(232)
Hello, David HM Spector
Last visit: 06-Feb-88 22:31:04
Forum messages: 1489 to 2516
Last message you've read: 2409
Subtopic(s) Selected:
All Accessible
No members are in conference.
Short bulletin:
============================
Welcome to HYPERCARD FORUM!!
============================
=========
!!ALERT!!
=========
DO NOT USE THE STACK "NEWAPP.STK" WHICH WAS ONLINE HERE FOR ABOUT 24 HOURS. IT
WILL MESS YOUR SYSTEM WITH UNKNOWN RESULTS. DO NOT USE ANY OTHER SYTEM FROM ANY
OTHER DISK THAT WAS RUN WHILE THE NEWAPP.STK'S MODIFIED SYSTEM WAS ONLINE.
The above stack contains code which modifies your System and other Systems it
comes into contact with. It is a "computer virus." If you run NEWAPP.STK it
will modify the System on the disk it is on so that the System's INITs contain
an INIT labeled "DR." Then, if you use another System with the DR-infected
System as your boot System the new System will also contain the
self-propagating "DR" INIT Resource. While it is possible to, apparently, "cut"
this Resource from infected Systems with the Resource Editor THE ONLY SURE
COURSE OF ACTION IS TO TRASH ANY SYSTEM FILE THAT HAS COME IN CONTACT WITH THIS
STACK.
I apologize for this having happened. Obviously, whoever programmed this
qualifies as being less than pond scum (if it was done purposefully). The
uploader has been locked off the network (not just the Forums) and he will be
contacted by CompuServe and/or myself. Please keep in mind, as always, that
although Sysops do check uploads it is impossible for us to do such things as
examine every file with the Resource Editor. As I have always recommended, keep
downloads away from your hard disk until you are sure they are OK.
In eight years of operation this is the only such occurrence. While I, of
course, cannot say it will be the last I still have just as much confidenc as
always in the fact that 99.99999999% of the Mac Community are quite trustworthy
and that there is no real need to "fear" downloads. Thanks,
-- Neil Shapiro (Chief Sysop)
*****************************************************************
|MAUG(tm)(Micronetworked Apple Users Group is a trademark owned |
| by MCU Inc. (PO Box 520, Bethpage, NY 11714). Voice help line |
| available at 516/735-6924 daily _only_ from 10am to 5pm EST |
*****************************************************************
Rochester Telephone Corporation (New York) erroneously billed 4,800
customers for phone calls to Egypt. The company blamed the error
on a computer which "...misread the number dialed and determined
that they were coming from Egypt".
(From the February, 1988 issue of Online.)
Bill McGarry, Bunker Ramo, Shelton, CT
{philabs, decvax, fortune, yale}!bunker!wtm
[Sounds as if they did not know whether they were coming or going! PGN]
Many RISKS readers who have been following the recent discussion of whistle-blowing will be interested in "Making the world safe for whistle- blowers," by Rosemary Chalk, TECHNOLOGY REVIEW 91(1):48 - 57, Jan 1988. Now on newstands. Several case histories, a bibliography, and a review of legal status and protection. - Jon Jacky, University of Washington
In Risks 6.1 Bob Ayers writes:
>Is it better to have a computerized system — knowing that it is not
>perfect — or to have a non-computerized system — which also will not
>be perfect, though its faults will be different?
>Would you use a computer system if, on each use, it had a one in 10^9
>chance of killing you? You use such [non-computer] systems every day.
>I recommend the book (also mentioned before) On Acceptable Risk.
The difference is that in non-computerized systems there are techniques to
measure or assess risk so one knows whether the risk is acceptable or not.
These do not exist for software. So the question is whether it is better
to have a non-computerized system with known, acceptable risk or to have
a computerized system with unknown (and perhaps unacceptable risk).
Would you use a computer OR non-computer system in which you were unsure
whether the risk was 10^-9 or 10^-3 or 10^-1 chance of killing you?
How many complex, real-time software systems do you know of that have
demonstrated anything close to a 10^-9 chance of erroneous behavior
(i.e., virtual perfection) over its entire lifetime? Even if you might
somehow name one or two, does this occur in all software systems so
that one can count on it?
Another difference is that interlocks and other devices are used to protect
against expected failures (non-perfection) in non-computer systems. How many
software systems do you know of that contain such protective features? How
many software engineers know how to build in such protection? How many
government agencies have guidelines that require safety analysis of computer
systems as they do for non-computer systems?
Nancy Leveson
An extract from "Practical Wireless" February 1988 shows that even
the sort of computer found in homes aren't immune from RISKs. Most
amateur radio enthusiasts using amateur satellites use a computer to
derive their predictions, and PW has this to say:
"Those using some satellite computer programs may find that with the
coming of the new year, their predictions may go astray. It is possible
that the new sidereal time values, usually as lines stating "IF Y2 = '87'
LET G2 = 0.2753606" may not automatically update in some of the older
programs. Whilst this can be overcome by calling January 1 1988 "December
32 1987" and January 2 "December 33" etc, is is better to update your program
with the new values following: [numbers deleted]"
Yet another "new-year-bug"? The work-around really tickled my fancy!
Dave Horsfall (VK2KFU) ACS: dave@stcns3.stc.OZ.AU
Alcatel-STC Australia ARPA: dave%stcns3.stc.OZ.AU@uunet.UU.NET
11th Floor, 5 Blue St UUCP: {enea,hplabs,mcvax,uunet,ukc}!\
North Sydney NSW 2060 AUSTRALIA munnari!stcns3.stc.OZ.AU!dave
On reading Dave Horsfall's contribution from "The Australian" about incorrect
results being sent out to students I remembered a similar situation that
happened here in one of Australia's other states - Tasmania.
One of my friends doesn't like her final results being published in the
state's main newspaper (it's standard practice to print them). So, she rang
up the newspaper's office and asked for them not to print her results.
No problems they said except we are having a few problems with our database,
but we'll see what we can do.
So, sure enough when the results came out in the paper it was evident that
they had some problems with their database. Her name was printed along with
4 lower passes (not good enough to count towards her Higher School
Certificate). However, these results were incorrect and she had in fact
higher passed 3 subjects and passed 2.
It seems to me that they must have really had some big problems with their
database if they couldn't just flag someone's results not to be printed, and
whatever flag they used corrupts the results that are printed.
Luke Visser
Snail: Uni of Tasmania, Box 252C GPO, Hobart 7001, Tasmania, Australia.
ACSnet: luke@tasis.utas.oz ARPA: luke%tasis.utas.oz@uunet.uu.net
UUCP: {enea,hplabs,mcvax,uunet,ukc}!munnari!tasis.utas.oz!luke
>Consider, too, that such a concerted attack on satellite sensors is precisely >analogous to, say, saboteurs simultaneously blowing up all the BMEWS missile- >warning radars: it is itself an act of war, and an extremely ominous one, >pointless except as a prelude to a nuclear attack. It in fact IS a strong >warning of imminent attack, although not quite an actual launch warning. True, very true. But the US does not have a "launch on suspicion" policy. Consider this scenario: The Soviets blind most of the US Early Warning satellites. Please note, there are NOT of lot of birds tasked for EW; they wouldn't have to take a lot out. Assume some small capability remains, as well as limited functioning among the cripples. The U.S. immediately goes to high DEFCON. SAC places the bombers on air alert, the missile crews batten down the hatches, the President dives into the airborne command post. The Soviets do *nothing*. Maybe issue a public apology. Maybe raise their eyebrows and say, "are you sure it wasn't another gas well fire? Where's your proof?" They do not launch their missiles. Meanwhile, the US is left with limited missile warning capability. SAC stays in the air/in the holes, the president lands occasionally, and NORAD crews work 24 hours a day trying to keep cripples working. We can't keep it up forever. Spacecraft are expensive, launch costs are high. It doesn't make sense to the bean counters to have replacement birds on any sort of alert. We CAN NOT regain capability quickly. Nor can we remain at elevated DEFCON levels indefinitely. Two months of this type of operation, and the BUFFs (SAC B-52s) are down for maintenance, the missile crew's morale is at rock bottom, and the cripples are falling by the wayside. The President is back in DC, working on the budget. *Then* would be a good time for a major attack... Ron Wanttaja ex-NORAD Satellite Systems Engineer (ssc-vax!wanttaja)
Jim Horning once suggested that we need the equivalent of an Underwriter's
Lab for software. It appears that such a thing now exists, at least for one
professional group. Three years ago the ABA (American Bar Association)
created the Legal Technology Advisory Council (LTAC) staffed by software
technicians and scores of volunteers (both lawyers and software experts).
The LTAC establishes performance standards for law office software, tests
products against those standards, and gives an official "ABA Mark of
Approval" to products that pass their tests. To become an ABA-Approved
product, it must have the features that will meet the needs of the law
office, it must do what the vendor claims it will, and it must not have
serious errors in manuals, training, or the software itself.
More than 1500 products have been tested and they have found errors in
EVERY ONE. About 50 products in time-and-billing, word processing,
docket and diary, real estate, litigation support, and other areas have
eventually been able to get the stamp of approval after making required
corrections. Errors that they found include systems that:
— would not print a bill
— did not identify which key to press to retrieve a document
— added dollars to hours (instead of multiplying hours times a
billing rate to yield dollars)
— in a docketing system, automatically erased entries, including
future court dates, once its capacity was reached
— would not show an item as billed, making it likely that the item
would be inadvertently billed twice
— had non-functional security systems
— multiplied rate by hours incorrectly
— printed the wrong billing name and address on a bill
— tallied different totals across and down headings
— had instruction manuals that provided incomplete or incorrect
information and omitted crucial steps.
The LTAC publishes detailed information for each approved product on
product features and results from the testing process. There are also
guidelines for various types of software that specify features that must
be offered for ABA approval and preferred features (not required but very
desirable). Besides performance features, the guidelines also require that
systems be free of bugs, that advertising claims conform exactly to system
capabilities, and that printed or on-line training and help instructions
be clear and easy to understand. That is, they claim that ABA approval
will assure that a product is free of bugs and will perform as advertised.
The most fascinating part to me is that they recommend that if lawyers must
consider a product that is not approved, they should ask the vendor to
WARRANT that their product meets the ABA standards: that it has ALL the
features you need AND that it is free of errors and bugs. The booklet
I read says to "either prepare a formal, written warranty for the vendor
to sign or prepare a formal RFP that lists the LTAC guidelines for the
specifications." Considering the standard disclaimers that usually come with
commercial software, I wonder how successful lawyers have been at getting
vendors to sign such warranties.
This seems like an interesting model for other professional groups to follow.
Nancy Leveson
Please report problems with the web pages to the maintainer