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…
Not too long ago a Telecom worker in Western Australia was reportedly killed when a fragment of fibre optic glass accidentally got into his blood stream. Remembering this, I was horrified to see at a recent trade show some very casual handling of raw fibre by visitors and sales reps at a stand. Some children were trying to handle the fibre bundle too (I stopped them) The risk is apparent, in the frenetic effort to "de-mytholise" [demythologize?] technology for the general public, we (industry professionals) unknowingly jeopardise their safety. Can anyone confirm the Telecom worker report? (RISKS-15.17, `Fiber Optic Cable "Meltdown" in Connecticut' prompted this response, as it is not strictly computing.)
There was a story on the radio (which is why I can't spell it) about patients dying from incorrect dosages of Lanocaine (sp?) because the syringes for the different dosages look too much alike. It brings to mind the discussion on incorrectly calculated radiation dosages. While one can argue that the computer-based systems are very complex and need to meet high standards, I wonder how the problems of such systems compare with those of more conventional systems. The estimates I've heard about incorrect dosages during normal hospital procedures is very high. (Yes, I'm being vague but I don't have the actual numbers readily available).
In RISKS 15.18, padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) discusses a scheme for using the ethernet MAC address as a mechanism for verifying location, much like we used to do with hardwired mainframe ports. Unfortunately, there are two problems here. The first is probably the most damaging - the ethernet address is the address of the transmitting unit ON THAT ETHERNET segment. If the unit is not on that segment and is sending via a router, for example, then the ethernet address will be that of the router's ethernet transmitter, and not the originator's physical address. As to re-writing the ethernet address in the unit itself, I believe that cicso routers can do that rather easily. I don't have the manuals here at home but I seem to remember that is a functionality that is needed in the DEC world. Bob
The BBC Radio 4 programme "File on Four" last Tuesday was devoted to the subject of safety-critical software. It discussed the causes of the "software crisis", described a number of the famous recent disasters, and then considered what can be done about it. The problems that arise with software are due to "complexity", "novelty", and "discontinuity". Prof. Cliff Jones of Manchester characterised the complexity of software in terms of the number of branch points it may contain, and hence the number of possible paths through it. The combinatorial explosion of possible paths makes exhaustive testing impossible in all but the simplest programs. It may be difficult to achieve with 50 Lines of code and 10 branch points. With 10,000 LOC and the same density of branch points, the testing time would exceed the time elapsed since the big bang. As he pointed out, the Sizewell B Primary Protection System contains 100,000 LOC. Prof. Bev Littlewood of CSR criticised the tendency of manufacturers to take advantage of the presence of software to make systems perform more and more new functions, so that the soft-centred systems are many times more complex than those they replace, and are also attempting completely novel things, whose consequences may be poorly understood. Cliff Jones returned to describe the discontinuous nature of digital systems, whereby changing one bit in the internal state or input may cause a vast change in the output. This is in contrast with the "traditional" engineering approach which relies on the fact that, in systems which are governed by the laws of physics instead of the rules of logic, a continuous variation of input leads to a continuous variation of output. I spoke briefly about the problems of certifying software to a certain numerical level of reliability, with particular reference to avionics systems, where the regulations specifically exclude software from reliability measurement, with the result that manufacturers treat its reliability as 1 for the purposes of calculating overall system reliability. Martyn Thomas described the guidelines for avionics software as simply exhorting the manufacturer to "try harder" with the more critical stuff. Dan Hawkes of the CAA pointed out that "do your best" is an approach often used with certain hardware systems on aircraft, and said that software was treated no differently from some hardware. Martyn was in favour of using formal methods on safety-critical software, and also of qualifying the people who work on it. There are no formal qualifications required before a practitioner may tackle a safety-critical item of software, and yet, as Cliff Jones pointed out, programming productivity has been found to vary by up to a factor of 10 between individuals. "Error-prone" modules are regularly found in industry, and this, Cliff speculated, could be due to their being written by error-prone individuals. Various disasters were cited, including the recent Gripen crash in Stockholm, and the London Ambulance fiasco. Both have been well covered on the list. A couple of anecdotes of interest concerned the man who called an ambulance for his mother, who had suffered a stroke. After several hours, he took her to hospital in his own car. The ambulance turned up 10 hours later. The crew of another ambulance radioed base after being sent out on a call and asked why the undertaker had managed to get there before them! My favourite item concerned the garage owner who specialises in tuning software. He gets the binary from the engine management ROM by mounting it in some harness on his PC. With experience, he is able to spot the data tables containing the engine parameters, and he alters the values. By trial and error, he has found how to undo the "detuning" that is often designed into these systems, and he makes the car give you "... a bigger kick in the back, when you give it some boot!" (or words to that effect!). Regarding Sizewell B PPS, which was discussed at some length, a "confidential leaked document" had found its way into the producers' hands, and was quoted at length. Presumably, this was the same as the one that was featured on BBC Channel 4 TV news not long ago, and is now being sold for two pounds by Computer Weekly? I'll let you know when I receive my copy! :-) Peter Mellor, Centre for Software Reliability, City University, Northampton Sq., London EC1V 0HB, Tel: +44(0)71-477-8422, JANET: p.mellor@csr.city.ac.uk
This week's (October 21) "Coast Weekly", a Monterey County free entertainment
(mostly) paper has an article on "hacking" by staff writer Nicole Volpe.
I'll quote part of an introduction from the editorial page.
"While interviewing computer hackers for this issue, it occurred
to me that there are a lot of similarities between reporters and
cyberpunks - We share a belief in freedom of information, a general
suspicion of those in power who operate secretly, and an unfortunate
tendency to invade privacy.
This reporter got a taste of what it's like to be on the receiving end
of privacy invasion when a hacker I was interviewing handed me a
printout of personal information about me that he had retrieved,
using nothing more than my home phone number. His reasons were valid
enough - he wanted to be sure I was who I said I was. As a reporter
I was impressed with the investigation, but on a personal level, it gave
me the creeps. It was a lesson they don't teach you in J-school..."
The main article covers the exploits of some crackers in the Monterey area,
their concern about the Clipper proposal, some stuff about arrests of
crackers in other parts of the country, and an interview with a security
man from Metromedia's long distance business. The latter says, "If you
picked up the phone a year ago, dialed one digit, and then hung up, I
could go back and find out what that one digit was. All the records are
stored on magnetic tape." [Balance of message was apparently truncated.]
Dennis Chamberlin, in an otherwise illuminating article, says:
> And, the airplane itself is a mixed and intradependent package of fairly
> high-power emitters (radio, transponder, radar),
Watt counts as a high-power emitter? I'd be ohm-bliged for amp-lification.
The radios (including transponder) in my humble Archer take roughly 7 amps at
something approximating 14 volts when transmitting.
Peter Ladkin
[PL actually wrote "appoximating", but I didn't think that was punny,
so I corrected it. Appox on both your gausses. What a re-volting
development. And, yes, I do have a susceptance for puns. Sorry if my
resistance ebbed. I was in a Faraway Cage. PGN]
I refer all of the risks readers to a set of articles in the LA Times of
10/3/93 which discusses risks related to the Clipper chip. And to fuel the
debate, I add my own comments:
IF we hinge everything on the clipper chip and an enemy breaks it,
we are vulnerable at every level. Isn't diversity a good idea for protecting
the US combined information assets?
I will be willing to use the clipper chip for all of my encryption IF
the NSA, DoD, and ALL US Government applications use the clipper chip for ALL
of their encryption as well. Do they really trust it that much? I doubt it.
The NY Times article says the US is considering giving clipper chip
keys to other governments so they can monitor our communications as well!
Does this mean France will be able to steal our trade secrets? They have
already started doing it on airplanes, but now they will be able to do it
en-masse at low cost - sponsored by the US Government.
Now that we all know the clipper chip is manufactured by Micronix in
Torrence, CA, how long will it be before spies manage to get the design and
the `secret' keys? Do we really believe that security there is good enough
to trust our entire national assets to it?
Is the US Government giving a monopoly to Micronix for all cryptography
in the US? Since when do they have that right?
Won't the criminals the government claims to be trying to catch be able
to buy encryption from the rest of the world? Even if it's illegal to do so,
they are criminals, so they will probably be willing! That means that only
the criminals will be able to avoid surveillance designed to only observe
criminals.
If there are only a thousand or so legitimate phone taps per year in
the US, is it really worthwhile to spend $26 per chip times a few hundred
million chips (over 2 billion dollars) nationwide just to assure 1,000 phone
taps? That's 2 million dollars per (phone tap per year)! I would think that
for 2 million dollars per criminal, the US Government could come up with a
much more effective plan for getting the information they need.
Suppose the NSA is wrong? They've been wrong before! Suppose Clipper
becomes not so hard to break because of some mathematical breakthrough? Are
they willing to bet the farm on this?
Well, that should get things going - FC
United Press Intl newswire via CompuServe Executive News Service:
Computer chip manufacturer seeks way to stem theft
SANTA CLARA, Calif. (UPI) — One of the nation's largest manufacturers
of computer chips said Friday it will start to put serial numbers on its
products in an effort to stem the rising tide of robberies."
This move should make it harder for thieves to sell their loot; one hopes it
will therefore make warehouses less attractive targets for the armed gangs who
have terrorized Silicon Valley in recent months.
And the problem with stealing chips is that you can't take just one....
Michel E. Kabay, Ph.D., Director of Education, National Computer Security Assn
In Risks 15.17, an32153@anon.penet.fi remarked upon the dangers of including a signature with anonymous postings. It's not quite as absurd as it seems, if someone uses a mailer that appends the signature automatically ( I can't imagine that anyone who cared about their anonymity, as opposed to those who just are assigned an anonymous id because they reply to somebody who uses one, would deliberately append a revealing signature ). The solution to that, at least on anon.penet.fi, is simple: The server considers anything after a line beginning with two dashes as a signature and cuts it off ( this can be a complication if someone tries to append a document to a message and uses a row of dashes to separate it from the main text ). So if you want to send mail anonymously, either dump your signature or be certain it starts with --. [Also noted by Chris Moore <Chris.Moore@src.bae.co.uk>. PGN]
Colleagues and friends, thanks for the very helpful and positively critical comments. I append Mr. Frigerio's reply for your information. Klaus (Oct.21,1993) PS: Mr. Frigerio will have another fight with lawyers who think that any legislation is dangerous as it may also hurt the "good viruses". I argued that "good viruses" exist only in Dr. Cohen's head, as those applications which he always mentions can be realized by non-replicative methods. Moreover, any auto matic reproduction has an unwished side-effect, as copyrights for any software does only apply to the original (=uninfected) program, so viruses "steal" also legal rights from both the originator and the user (who looses the guarantee, if any, of a working program :-) >>>>>>>>>>>>>>>>>>>>>>> Mr. Frigerio's response <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Thanks to everybody who replied on the subject of Swiss Anti-Virus Legislation. As somebody noticed there was a word missing in the English translation. It should have been: "... destructs electronically or similarly saved or TRANSMITTED data will..." The text posted to the net, was a trial to include into the "data damaging" even creation and dealing/circulating computer viruses. The idea behind this, is that the virus itself already carries the malicious intent of his author. Therefore it is dangerous in any circumstance. Actually a virus can not be abused, as the idea of abuse includes the possibility, that a virus can be used in a good way too. As I have been told by specialists, there is no such "good use" of a virus as any unauthorized change of data has the potential of interfering with other data and/or programs in environments, that the virus author did/could not foresee. And even the unauthorized use of storage space is a damage, as this space will not be available for authorized uses of the computer system. Computer virus are an "absolute danger", and as any other dangerous thing (like explosive, poison, radioactive materials or genetic materials in specialized labs) computer virus should not be created or circulated without restrictions. It has been remarked that in the text there was no word about the requisite intent or requisite knowledge of the committer. This way any BBS sysop would always risk criminal charges, if his BBS carries any virus infected software but the sysop isn't aware of it. I apologize for not having told that Swiss Penal Law only considers intentional crimes, if there is no explicit indication that negligent acts are punished too. Therefore according to Swiss Penal Law terminology and system, the text posted to the net only considers who "knowingly and willingly" commits the act. That means that the author of the virus has to know it was a virus, what he created: this is always the case. And who circulates the virus has to know it was a virus and he wanted to circulate it. The knowledge that SW was or carried a virus can be proved easily by the fact that nobody knowingly stores viruses without labeling or marking them in any way, in order not to be infected himself (yes, I know: if there really is somebody so foolish, I have to find another way to prove his knowledge). For BBS a "Virus Directory" containing viruses or virus source codes is evidence enough for the "requisite knowledge and intent". The law does no want to punish accidental distribution of viruses. The phrase "means destined for unauthorized deletion" has been considered unclear. "Means" certainly includes not only software, but source code (on paper as on disks) too. It has been remarked that it's the classical toolmaker problem: a knife can be used as woodcarver to make a great work, but it might be used by a thug to commit murder. I realized this problem, but would you consider a knife as generally destined to commit murder? Or would you consider explosive as generally destined to create damage? We have to be aware that most items can be used in a legal or abused in an illegal way. Seldom an item can only be used in an illegal way, but computer viruses are such items! I do not speak about software using virus specific reproduction techniques (like "killer viruses" for copyright enforcement or "anti-viruses" supposed to fight viruses) that make data changes with the explicit (contract/license) or implicit (highly probable agreement of the user) authorization of the user. This kind of SW is actually not included in the definition of "means destined for unauthorized deletion, modification, or destruction of data". Therefore you cannot say that Norton Utilities, WipeFile or any other similar general purpose SW or utilities are "destined for unautorized deletion, modification or destruction", although they certainly could be used for this. The text doesn't say anything about malice, malicious intents or the intent to damage, as these elements are very difficult to prove in trial, if the accused denies any such intention. Actually I considered these subjective elements as not really necessary, as the virus already carries the malicious intent of its author: the malice of the author is proved by his virus, and the malice of somebody circulating the virus is proved, if his knowledge, that he was circulating a virus, is proved. According to general principles of penal law the site of crime is the main link to charge somebody. If a virus has been created or circulated outside the national borders of Switzerland, Swiss Penal law cannot be applied. But if a virus created outside Switzerland is transferred electronically to Switzerland, the downloader will be held responsible, no matter if he was in Switzerland or abroad, as "importing" as a way to circulate the virus. The "success" of the act will take place in Switzerland. Anyway Art. 7 of Swiss Penal Law follows the principle of territoriality and the "Ubiquitaetsprinzip" (sorry: didn't find the correct English word: an act is considered being committed not only where the committer was, when he started his crime, but also where the "success" has been realized. Anyway I do consider clarifying this by inserting that "importing" virus is considered as "circulating in any way". As this crime is prosecuted as soon as police or prosecution authority knows about it (so called "ex officio", there is no need for a specific complaint: a detailed information about a fact is enough to start investigations, no matter where the information came from (e.g. abroad). There is no doubt, that professional ant-virus specialists and scientists should have access to viruses and be allowed to even create viruses. As long as this is covered by the aim of studying strategies to fight computer viruses, this is OK. I actually planned a system of registering these people with a federal authority (e.g. the IS Security Dptm. at the Swiss Federal Office of Information Technology and Systems or the Ministry of Justice). The posted text would be then need to be completed as follows: "Who, without being registered with the proper federal authority, creates... Only trustworthy individuals, who are professionally or scientifically active in combatting such means, may be registered on demand." The Swiss legislator is actually not only considering "data damaging" but "hacking", "time theft" and computer fraud too, but these ARE NOT subjects of the discussion in this forum now. The same applies to software piracy, already ruled by another law. I will gladly email/fax the German, French or Italian text of the Penal Law draft to anybody interested. Please do not ask me an English translation of these, as I am not a professional English translator of legal text. I am aware that the UK and Italy have/are going to have laws allowing to prosecute the creation and circulation of computer viruses. If anybody knows of other countries, may he please let me know in any way and as soon as possible. On Monday, 25 October 1993, there will a meeting with the Ministry of Justice in order to convince them to propose this to the Parliament. This will be very very difficult, as there generally is very little knowledge on, or concern for the threat through computer viruses. Most people have simply never suffered an attack of computer viruses. Thanks again for following this item with your comments. Claudio G. Frigerio P.S.: Please do not suggest to me to send them a floppy with a ..... just to make them more aware of the risks... P.P.S.: You can phone/email/fax/write to me in Italian, German, French, Spanish or English. Claudio G. Frigerio, Bundesamt fuer Informatik/Stabsdienste, Feldeggweg 1, CH-3003 Bern (Switzerland) +41/31/325-9381 bfi@ezinfo.vmsmail.ethz.ch
CALL FOR PAPERS
CONFERENCE ON COMPUTER-AIDED VERIFICATION
Stanford University, Stanford CA, USA
June 21 - June 24, 1994
This conference is the sixth in a series dedicated to the advancement of
the theory and practice of computer-assisted formal verification.
Emphasis will be placed on research results that may potentially
result in improved techniques, implementation issues for existing
verification results, and application of methods to real verification
problems.
Special sessions for tutorials and demonstration of verification tools
are planned.
The boundaries of the conference are not rigid. In the past,
papers on the following topics have been enthusiastically received:
Application areas: synchronous and asynchronous circuits, computer
arithmetic, protocols, distributed algorithms, real-time systems,
hybrid systems.
Methods based on: automata, model-checking, automated deduction.
Theoretical issues: decidability of verification problems and logics,
computational complexity results, verification algorithms.
However, any paper that is of potential interest for computer-aided
verification will be considered.
SUBMISSION:
Electronic submission of Postscript(tm) files is REQUIRED, except for
authors who do not have reasonable access to electronic mail through
Internet, BITNET, etc. Draft papers should be no more than 10 pages
long (with normal font sizes, line spacing, margins, etc.) Papers
should provide sufficient detail so that their technical contributions
can be assessed by members of the program committee. Accepted papers
will be published in the conference proceedings. Submissions must be
received by January 14, 1994. Authors will be notified of acceptance
or rejection by March 11, 1994.
Program Chairman: David L. Dill
CIS 135
Stanford, CA 94305-4070
cav@cs.stanford.edu
Steering Committee:
E. M. Clarke, Carnegie Mellon University, USA
R. P. Kurshan, AT&T Bell Laboratories, USA
A. Pnueli, Weizmannn Institute, Israel
J. Sifakis, Verimag-IMAG, France
Additional members of the program committee:
R. Alur, AT&T Bell Labs, USA
R. Brayton, U. of California, Berkeley, USA
E. Brinksma, U. of Twente, The Netherlands
R. Bryant, Carnegie Mellon U., USA
R. Cleaveland, N. Carolina St. U. USA
C. Courcoubetis, U. of Crete, Greece
R. de Simone, INRIA, France
A. Emerson, U. of Texas, Austin, USA
M. Fujita, Fujitsu, Japan
S. German, GTE Labs, USA
O. Grumberg, Technion, Israel
N. Halbwachs, France
G. Holzmann, AT&T Bell Labs, USA
K. Larsen, Aalborg U., Denmark
K. McMillan, AT&T Bell Labs, USA
L. Paulson, Cambridge U., United Kingdom
N. Shankar, SRI International, USA
F. Somenzi, U. of Colorado, Boulder, USA
B. Steffen, Techical U. of Aachen, Germany
P. Varaiya, U. of California, Berkeley, USA
P. Wolper, U. de Liege, Belgium
T. Yoneda, Tokyo Inst. of Tech., Japan
Please report problems with the web pages to the maintainer