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…
Phil Goetz quotes (without attribution to me, probably out of deference to my age) as follows: >To suggest that [write-protection] is 100% effective against a virus is to >overstate. Studies in biology suggest that a virus can thrive even in a >population in which a large percentage of the members are immune, if a there >is sufficient commerce among the non-immune members... >Depending upon design of the virus, the target system and population, and >the chosen distribution vector, the effectiveness of this mechanism against >the spread of the virus might vary from high to none at all. Those of you that read the original posting may remember that the reference in the original posting was not to "write-protection" in general but to a specific hard-disk write protection mechanism that could write protect up to 80% of the hard-disk. You may also recall that the ellipsis at the end of the first paragraph represents: >This is not an argument against vaccines but only a caution >about the limits of their effectiveness. Mr. Goetz asserts: >Conclusion: Write-protecting the hard drive can offer 100% protection. I concede the following: Write-protecting 100% of the hard drive 100% of the time can offer 100% protection against any contamination or infection of the hard drive. 100% protection of 100% of all hard drives (an absurd case) can provide 100% protection against any infection of those hard drives. However, even write protection of 100% of 100% of the hard drives will not be 100% effective against 100% of viruses. [I refer Mr. Goetz to Mr. Cohen for proof of that assertion.] The assertion in the second pargraph was also made in the narrow context of the particular implementation of write-protection which was the subject of the posting. However, upon inspection, I conclude that it stands by itself. I leave it to Mr. Goetz' peers to instruct him as to why. Mr. Goetz concedes: >Of course, if you are using your computer as a terminal, you might move a >virus between accounts on a mainframe, or between different computers you >dial up. But your computer is protected. The interesting characteristic of a virus is not how it behaves in the target machine but how it behaves in the community. The interesting characteristic is the ability of the virus to replicate rather than its ability to infect. The XMASCARD program did not infect; it only replicated. After it replicated a sufficient number of times, the number of copies overwhelmed the community. The issue here is not how or whether you can protect yourself. Rather it is how viruses will behave in a community of systems many of which are not protected. It is whether or not Mr. Goetz will have to write protect his hard disk. It is whether or not the community will be sufficiently orderly and well behaved that we can safely share programs and other data that we did not create ourselves. Forgotten, but not gone. Bill Murray William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
Some info on the brain virus not previously mentioned by those who were trying to quell it - it modifies several .com files, maybe all of them eventually, without changing file sizes or dates - this was found by using a cryptographic checksum on a golden unit, infecting it, and looking at the results. Apparently, at Miami U of OHIO, they were accidentally reinfecting every time they cleaned a disk because they had NO GOLDEN UNITS! We found a 2 year old disk and are going to use this as a beginning from now on. We also got help from a programmer who wrote a little routine that checks for changes in the interrupt vectors and halts the machine as soon as they change. We are in the process of installing an improved self defending command interpreter, but are having a hard time because we cannot get sources for the system files we are trying to protect. Once again, protectionism causes more problems than benefits. Oh yeah, did I forget to mention, that since you cannot write protect lotus, etc because of copy protection, you cannot keep them from getting infected - I thought I should bring it up. Finally, even if you rewrite the boot sector, the brain we found remains active through the com files it modified. So much for the cures I've heard about. As always, suggestions are welcomed, but I think we will get it under control before the summer break (2 days away). If we don't it could be real trouble for the rest of you. - Fred
In WHMurray's recent article to this bboard, I hear the same sounds
I have heard for years when attempting to discuss computer viruses
in an open forum. To speak of the disease is to invoke it. Did anyone
ever consider that the disease is inevitable, but the defense is not.
Society does not progress by failing to recognize threats, by hiding
its head in the sand, or by ignoring gaping holes in its integrity.
It survives by identifying corruption and eliminating it. Those who
would permit society to live in a situation so frail that a single
attacker could bring it to its knees, and then try to cover up that
knowledge by hiding it from those best prepared to put up a defense
are begging for the destruction of that society. Imagine howbad the
virus situation would be 20 years from now if we didn't find out about
it now! We would have cars that could be infected, automated airliners
waiting for an accident to happen, automated defense systems that
could strike individuals deads directly from space, all existing in an
environment without integrity.
To hide the truth is not to make the world safe. Only the truth can
set us free from the oppressive forces that lack integrity but live
in a dearth of secrecy. I think we need to start to spend our efforts in
computer security on protecting integrity, not secrecy, and I will say
it in public forums, dispite the best efforts of some of our government
agencies to keep me from doing it. Furthermore, I will continue to encourage
others to do so.
Don't get me wrong,. I don't think we should glorify attackers, I think we
should start to talk about rational defenses that protect the individual.
Don't forget that society is made up of individuals, and that by protecting
those individuals, we protect the society as well. It is the attempt to
protect the society by allowing individuals to come to harm that rationalizes
needless wars, police actions, illegal arms deals, and the whole slew of other
corrupt practices that are bringing our society down. It is the truth that
will set us free, but only if we are brave enough to face it.
Sorry for the flaming nature of this, but I feel strongly on this
issue, and have had enough from those who would silence important work.
Fred
You've described a general problem, of people refusing to document security
problems out of fear that some unscrupulous readers (or children) will use
the information. The result, of course, is that honest computer users are
kept ignorant while the dishonest ones slowly learn the tricks.
I've discovered one approach that is often successful at tricking people
into telling me about the problems. I tell them that I don't believe them.
Very often they will respond by trying to demonstrate my ignorance, and of
course, the only way they can do this is to demonstrate the problem.
You can vary the form of the insult quite a bit. For instance, if they have
named a particular commercial product and claimed that it is infected, you
can suggest that they have a financial interest in another product, and are
using scare tactics to discredit a competitor. (This isn't hypothetical, of
course; people have done this.)
Recently, there was a debate in unix.wizards about a supposed security
problem with the Bourne-shell's IFS feature. The same debate raged, with
nobody willing to document the problem. I finally got fed up, and announced
that I didn't believe there was a problem; that they were just shooting off
their mouths, trying to sound like security wizards when they weren't. I
got lots of flames that didn't document any problems, but among them was one
letter containing a piece of code that used IFS to create a shell that was
setuid to root. It's now part of my collection of security bugs.
As for viruses, I have the feeling that most people talking on the subject
are rather ignorant, and can't tell you or me anything. Perhaps if you
challenge them, you can find a few who will try to show that they know more
than you....
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
For anyone who may be interested, I've started a LISTSERV discussion forum on BITNET, entitled VIRUS-L. It is dedicated to the discussion of computer viruses, including present viruses and their progress, and the prevention/detection of viruses. To subscribe to the list, as with any LISTSERV-run list, send a message to the appropriate LISTSERV; in the message, say: SUB listname your name. That is, send a mail message to LISTSERV@LEHIIBM1, stating SUB VIRUS-L your real name. To subsequently sign off of a LISTSERV group, send a message to the appropriate LISTSERV stating SIGNOFF listname. Please do not send these requests to the list itself, as they will be distributed to the entire list [and] do nothing other than annoy people... :-) Once subscribed, send list submissions to VIRUS-L@LEHIIBM1. VIRUS-L is currently open to the public. Regards, Ken van Wyk Kenneth R. van Wyk, User Services Senior Consultant, Lehigh University Computing Center, Internet: <LUKEN@VAX1.CC.LEHIGH.EDU>, BITNET: <LUKEN@LEHIIBM1>
In regards to the continuing debate in RISKS about the KAL007 incident, it appears that one side of the argument is putting all of its faith in the version of the story reported in the book "Shootdown". It seems to me that you are always at RISK when you chose to put all of your faith in a single source, be it a pressure sensor in an engine, the phone company's billing system, an elected official, or a book about an aircraft that was shot down. [... and the OTHER side of the story is putting its faith on information that is all derived from one set of interrelated sources??? If you wish to speak in analogs with fault-tolerant computing, beware of the common-mode failures that can undermine supposedly redundant systems. By the way, one difficulty with trying to prove a conspiracy theory is that everyone on the inside will deny it (which may thus seem credible), whether or not the theory is true. So, you are ALWAYS AT RISK, period. PGN]
In the Letters column of the 1 May 1988 NEW YORK TIMES MAGAZINE (p. 14), a Steven Goldberg writes concerning an earlier article (27 March) on civil aviation accidents. He observes, "In the 'all accidents' category, the pilot is found responsible for the accident in only 38.6 percent of the cases. However, in the 'fatal accidents' the pilot is found responsible 61.5 percent of the time. It may be that there is a benign explanation for the fact that a pilot who is dead is far more often blamed than one who can defend himself. But the prima facie conclusion, in the absence of such an explanation, is that considerations other than safety lead the authorities to blame the pilot, who can not speak for himself." - Jon Jacky, University of Washington
The 1 April 1988 issue [!!] of DATAMATION includes an article, "Economic Modeling Gains Despite Accuracy Concerns," by Gary McWilliams (pps. 43-54). I am not familiar with this field, and the article never really explains what the inputs and outputs of the models are, where they come from or how they are validated. Nevertheless, people apparently use them to forecast economic trends and seem to regard them as useful. One model, called Project Link, includes more than 20,000 equations. Much of the article appears to be based on an interview with Sam Cole, economist and model builder at SUNY Buffalo, and author of GLOBAL MODELS AND THE INTERNATIONAL ECONOMIC ORDER (Oxford Pergamon, 1977). The article reports, "The World Bank uses a global model in its lending, says Cole, sometimes to the detriment of its debtors. 'When the World Bank lends [a country] money, it expects that country to have a [repayment] plan, and usually pursuades the country to accept World Bank forecasts. Since its forecasts are usually wrong, these countries end up with debts and no way to repay them,' says Cole. The World Bank's use of optimistic growth forecasts often are built into the models for political reasons, according to Cole." - Jon Jacky, University of Washington
In the middle 70s I was responsible for designing a simple on-line
inquiry system for automating bad-check lookup for one of those
firms that guarantee checks for retail merchants.
The way this works is that for a monthly fee (based on average
purchase amount and volume), the guaranteee firm would automatically
guarantee any check up to some limit, and provide a guarantee for
any higher amount check that was verified with them.
Initially this consisted of having the guarantee firm's telephone
operators page through a thick paper listing of bad checks and
returning a code 1, 2, 3, or 4 (1=accept:guaranteed, 2=accept:follow
ID procedures and we'll guarantee it, 3=do not accept:no guarantee,
4=do not accept:detain customer, police notified). For example,
checks listed as "stolen" would return a code 4 (yes, they stored
the range of check numbers so that they wouldn't flag unstolen checks
on the same account). The default (we don't know that check) was
code 2 [i.e., what the store should have done without the guarantee
service]. Merchants would be paid by the guarantee service for a
guaranteed check that didn't clear, and the guarantee service would
then assume the responsibility of collecting on the bad check.
Each inquiry was recorded for amount, the assigned approval number
and code, check customer number (a reference to the name used to
verify/guarantee the check), and the merchant number. This
was printed in a ledger and cleared from the system each night.
A new entry for someone was given code 2 until they'd been inquired
about several times over some period of time (I seem to recall more
than twice in 30 days), at which time they'd be advanced to code
1 on the assumption that they hadn't bounced any checks yet. Since
the merchant's best interest was served by reporting bad checks
ASAP, this seemed to work. Downgrade to code 2, 3 and 4 was manual
and done by accounting types at the guarantee firm from bad check
collections referred by the customer merchant. Perhaps they also
used other data; I don't know.
The whole premise was that each guarantee office usually served
repeat check customers: it could build a payment history database.
I think the assumption was that people who wrote several checks
without bouncing them would probably continue to do so.
We built the database for online inquiry by storing the last name
Soundex-indexed (as a sort of hashing technique, if you will), and
listing other information such as SSN, driver's license number,
account number on the check, etc in a cross-reference. If more
than one "hit" occured when an operator keyed in a last name, he
was prompted for more information to resolve the hits, or he could
page through a summary of the records on line to see if one fit
the profile of the check being submitted.
Clearly the RISK here is misidentification: the more information
they stored and the more the merchant's clerk collected for check
verification, the better they could do at eliminating false denials.
The system was clearly biased towards generating accepts to avoid
pissing off honest customers, but to contain the losses of the
guarantees. Last I heard they were still using revisions of that
software and making a chunk of money.
Note that most of the actual data used to determine check acceptance RISK was
not stored online. Probably it is now, but at that time (about 15 years ago)
the disk storage was too dear and the retrieval time simply wasn't important:
paper files in file drawers was quite good enough. Since the review was manual
anyway, it seemed reasonable to have the relevant documents in human-readable
form. One of them - the returned check - was always on paper anyway. This all
ran on a Microdata REALITY system with 64K of main memory (the max) and one 10
Meg hard drive. Nowadays you'd do it on an ATKlone.
Brian Kantor, UC San Diego
The May 1, 1988 issue of the NEW YORK TIMES MAGAZINE has a feature article about Tom Clancy, author of the best-selling thrillers HUNT FOR RED OCTOBER and RED STORM RISING. In the background of the obligatory picture of the author in his study by his bookshelves, you can clearly see NORMAL ACCIDENTS by Perrow (p. 55, right edge of page, halfway down). - Jon Jacky, University of Washington
In reply to two articles by Stanley F. Quayle: > This store uses price scanners. It would be possible to establish a > profile of each check-paying customer with this system....If they > haven't thought of this already, I don't want to give them any ideas. Don't worry; they've already thought of it and do it. My wife reports that Stew Leonard's in Norwalk, Connecticut is one store that does; by name, and what you buy, and if it was on sale. Paying cash is the only sure way to avoid this. (on Normal Accidents) I think Perrow was studying nuclear power as it existed from 1979 to 1984, not as it might exist. I don't think his conclusions on nuclear power are weakened at all if someone tells me that we could build safer plants, but don't. You can rightly say that safe plants haven't happened for economic, political, legal, and bureaucratic reasons, and you still haven't weakened his conclusions. David Chase, Olivetti Research Center, Menlo Park
Harvard Distinguished Lecturer Series, GB/SIGPLAN, and GB/SIGSOFT Present:
W.H.J. Feijen, Visting Professor at University of Texas, Austin
Professor at Technologie Universitat, Eindhoven, Netherlands
Speaking on MAY 3rd, 7:00 pm, Lecture Hall B, Harvard Science Center,
Cambridge, MA, Prof. Feijen promises to update Software Engineers on the
latest developments in the Formal Specification of Programs. He is co-author
with Edsger W. Djikstra of the recently released "Methods of Programming". (A
large crowd is expected.) Host is Professor Mark Schneider, Harvard Univ.
Please report problems with the web pages to the maintainer