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…
The National Security Archive (NSA), a non-profit clearinghouse for Freedom of Information Act (FOIA) materials, requested from the Central Intelligence Agency (CIA) a list of materials that the CIA had released under the FOIA. The CIA responded to the request by producing "a random dump", 5000-pages long summarizing the released material. The NSA and the CIA are frequently at odds with each other, hence the "hostile" reply by the CIA. Under the FOIA, agencies are not required to create (i.e. organize, sort, or merge) data, merely to provide information that already exists. So, it is unlikely that the NSA would have any recourse other than to attempt to reconstruct the index from the info-garbage it was given. [Common Cause 17(4): 20 (1991)]
Flight International (11 Sept 1991) reports that British Airways has been granted Category IIIB autoland clearance for its 747-400s and 767s by the UK CAA. Cat IIIB means that autolandings are permitted where the decision height is touchdown (zero altitude cloud ceilings) and the forward visibility is zero. BA are requiring 100 metres visibility for the 747 to taxi (75m for the 767). The clearance was granted after the CAA has monitored "almost flawless" autoland trials. 440 approaches were demonstrated on the 747, 520 on the 767. "At the heart of the system in both types is the Collins FCC132 flight control computer". The 747 clearance includes 3-engine operation. The single-engine limits for the 767 are 14m decision height and 200m visibility. BA expects FAA clearance for Cat IIIB in about six months. Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. Tel: +44-225-444700. Email: mct@praxis.co.uk
John Hobson gives a nice summary of the risks associated with rushing a weapons
system into use either prematurely or after lots of modifications are mandated
by paper-pushers. He makes passing reference to the greater-than-usual need
for cleaning of the firearm in its second major ... umm ... "distribution"
(the M16A1). The detailed story behind that is itself a study in mismatched
specifications.
The cartridge ultimately chosen for the M16 was originally a ``wildcat'' round,
and to some extent it evolved with the light rifle designs (some of which are
referred to as the Stoner system, although Eugene Stoner's ideas affected to
several products of the era ... the designs were successively owned by several
companies during early 60's.) One of the goals for this combination of rifle
and cartridge --- as inspired by those nice folks at DARPA, I believe --- was
to have a system that we average users would not have to waste time cleaning at
all.
The system as rapidly tested and then fielded achieved this goal. Then
government procurement got into the act. When the contracts for large
quantities of ammunition were written, the part of the specification about not
needing to clean the rifle was violated: to serve manufacturing needs,
companies used a slightly different formula for the powder than was used in the
original cartridge. Its use resulted in much greater accumulation of residue
in the rifle's gas system, in turn increasing failure rates (often with
consequences that didn't have as happy an ending as Hobson's story). The whole
mess was made worse since everyone was told *not* to clean the rifle, and no
cleaning kits were shipped with the first rifles delivered. Before the problem
was sorted out, congress got involved and the reputation of an otherwise
serviceable system was permanently damaged.
For what it's worth, those of us who actively compete in this class of shooting
sports use the M14, which led off Hobson's article. I guess we either view the
committee-designed tweaks to the Garand design as "features" or we have longer
arms than he does.
Jim
I'm interested in identified incompatibilities between the various US Government standards, beginning with POSIX GOSIP Ada B2 Security (etc.) in various applications. I know of one between UNIX-based POSIX implementations and Ada tasking that makes the combination inappropriate in safety-critical real-time and near-real-time applications, and I'm interested in identifying any others that are known for specific applications. [NOTE ADDED LATER IN REPONSE TO A QUERY FROM PGN:] There is a real issue. Ada running over UNIX can't handle data enablements of tasks reliably--the problem being that you don't have access to a test-and-set instruction and you can be interrupted in the middle by the arrival of data from outside. The result is spurious enablements and the loss of other enablements. That can be disastrous in a safety- or nuclear- critical system. How many nuclear-capable systems have been written using Ada tasking over UNIX? How many other problems have been created by incompatible standards? If you want a background brief, call me at (W)703.734.6092 or (H)703.758.9660. Harry Erwin Internet: erwin@trwacs.fp.trw.com
In the September 19th Rolling Stone at page 67 an article titled "Samurai Hackers" by Lynda Edwards tells us that a: "new breed of hacker has been finding a niche in the corporate world in the last two years. These hackers are hired by white-collar professionals at ad agencies, law firms, newspapers, and investment houses who want to steal co-workers' ideas and clients or pillage supervisors computer files for marketing strategies, performance evaluations and managerial gossip." Ms. Edwards presents several tales of crackers hired by unethical people in business to snoop in or sabotage other peoples' computer files. She also describes how victims sometimes hire their own crackers to mount a counter-attack. The crackers use their knowledge and skills to ferret out information from companies' networks and minicomputers. They usually receive a leg up from their employers, who get them modem 'phone numbers and basic account/password info. The crackers then overcome or bypass the often trivial security on the target systems. Most of what they do could be done by any jackleg expert with a given system, but the crackers are the agents of computer illiterates and thus constitute a threat unconsidered by the managers of systems in non-computer businesses. These crackers are seen to be somewhat akin to the wandering samurai of Japan's past. They work as mercenaries, honing their own skills and testing them in combat on behalf of employers they often hold in contempt. (The crackers are said to refer to ignorant computer users as "Stupids.") The samurai image is distorted and romanticized but the jobs the crackers take on are very real. These crackers are well paid by those who hire them through bulletin boards or by word-of-mouth. Tales of their exploits circulate on BBS's and they are getting some notice in 2600 magazine. [Begin Mark S.'s comments.] Of course, the notion of the computer whiz employed by some nefarious scheming man or woman of business is not new. What is new is the increasing dependence of service businesses on networked PC's. In the past non-computer firms tended to rely on computers and software dedicated to certain business tasks like accounting, process control, engineering, printing paychecks. These were often vulnerable to cracking for one purpose or another, but they weren't much of a resource for "fuzzy" information like supervisors' memos or private e-mail. Even offices using word- processing systems often relied on stand-alone machines which were easy to crack if you had the office key but impossible to crack by 'phone or from another office because they were not connected to any communication links. Only recently have PC networks become all-purpose communication tools in places like law or advertising offices where you can find memos, workups, payroll info, private diaries, electronic mail, etc. all lurking in the system. All in all, this sort of thing seems to bolster the argument that systems should be designed with security features even if the end customer doesn't know to ask for them. A cracker given access to one employee's account should not be able to use that access as a springboard to crack all of the other accounts or data on the system. Mark Seecof <marks@latimes.com> Publishing Systems Dept. Los Angeles Times
>Bravo. The database programmers made a mistake. The Salomon traders
>committed a crime.
Not quite. The programmers implemented a design that was laid down in detail
(you may assume, and hope) by analysts working under the direct orders of
executives from Operations and Finance. It's the job of those gentlemen to
ensure controls and audit trails. Their failure to do so is much more serious
than an error by programmers: it is more evidence of incompetence and/or
corruption, most likely both, pervading the company.
Dan Drake drake@Autodesk.com
Mark Fulk's article on the fetal tests on pregnant women brought back memories of my younger days several years ago when I was in Yale Med School. Well, it was only for a day and I was visiting friends and they took me to one class which was on pre-natal diagnosis. I remember a very practical and straight-forward professor discussing all of the possible techniques for checking out the womb and making sure everything was okay. He would carefully explain the technique and all the facts you could discern from the various bits of bio-matter you could snag from the womb. The Maternal Serum Alfa-fetoprotein test is only the beginning of their bag of tricks. It turns out that the doctors can't learn too much from this one because the fluid comes from the mother and contains only a very dilute amount of the child's bio-matter. The next step up was to get some of the chorion (sp?) which is essentially the boundary layer between the placenta and the uterus. All the nutrients pass through this membrane so it is rich in data. The most aggressive procedure, though, was when they poked around with a needle until they managed to find the placenta. Then they grabbed a bit of fetal blood. This, the professor explained, was a data gold mine. The rub was inserted very parenthetically at the end of each section of the lecture. He would say things like, "the amniocentesis test is the most successful and we find we only induce miscarriages in 1 to 2% of the time." (All numbers in this section are subject to bad memory fudging. They are approximate.) I remember thinking to myself, "Wow! 99% that's great!" because I think I was lead on by the can-do tenor of the lecture. About 5 minutes later I realized that "inducing miscarriages" was not the same as failing to cure cancer or a cold. It was a big deal. Statistically it was a violation of the Hippocratic oath. The patient died because the doctor was curious. And as it was the only "cure" they have for Down's Syndrome or other tri-somic babies is abortion. The tone of the lecture, though, was much worse that the attitude that you couldn't make an omelette without breaking eggs. They didn't do any of the risk analysis or any number crunching what-so-ever. The lecturer just ploughed on and his manner and diction was just saying, "We're doctors. This is what we do." Peter Wayner Department of Computer Science Cornell Univ. Ithaca, NY 14850 EMail:wayner@cs.cornell.edu Office: 607-255-9202 or 255-1008
Robert W. Kerns lists this point that makes people dislike certain risks:
* Low amount of individual control over individual risk factors.
This is a very important point but not quite accurate. It is *perceived*
control or *perceived* lack of control that affects risk aversion, and it
is the difference between perception and reality that injects a lot of the
irrationality into most people's risk avoidance behavior (myself included).
For a simple example, one of the effects of being drunk is thinking that
one isn't — hence many people at great risk of injuring themselves and
others go ahead and drive anyway, because feel that they are in control.
I think people's apparent preference for old familiar risks over new risks
is in the same category — familiarity breeding a false sense of control.
But preferring risks where one has individual control is, indeed, rational,
provided that one really has control, and doesn't just feel one has control.
Larry
As has been said before, the Scandinavian alphabets contain letters "alien" to Anglophones. One such is often referred to in English as "A-ring". In Danish it is written "aa". You can get it on a SUN keyboard by hitting "<compose>A*". It has ISO8859-1 codes 0xc5 (upper case) and 0xe5 (lower). On a PC it has character codes 0x81 and 0x8c. Vehicles from the Finnish archipelago A*land all have numbers starting with "A*L", followed by some digits. Since they are part of Finland, they may use the "SF" identification marker when travelling abroad, but some prefer to underline their regional identity by using an "A*L" sticker. I wonder how French police computers are set up to handle all this. The possible permutations of confusing mistakes here are fascinating. Torsten Lif, Ericsson Telecom AB, EO/ETX/TX/ZD, S-126 25 STOCKHOLM, SWEDEN Phone: +46 8 719 4881
> ... In the days of the 5 1/4" diskettes, the sensing was in the opposite way
Worse than that, *both* senses of write protect existed! If I recall
correctly, the 5.25" floppies sold by a certain major retail electronics outlet
differed from those sold by a certain major mainframe and microcomputer
manufacturer in this respect! I was working with both kinds of equipment at
the time (sigh) and, if I remember right, trashed a diskette by getting
confused by this at one point.
> ... it seems to me that the position of the plastic tab in the open
> position signifying "protected" is backwards from a fail-safe
> point of view. If dust prohibits sensing the position, or the
> detector/light source fails, the drive will incorrectly assume
> that the disk should be writable.
Ahh, but the chief failure mechanism for the 5.25" diskette write-protect
system was for the little "sticker" which was commonly used to write
protect/enable the diskette to fall off — this failure should make the disk
write-protected, no? :-)
Probably the 3.5" diskette emulates the argument of the above paragraph, even
though it is no longer valid. What it *should* do, IMHO, is have the whole
slider open, and use 2 LED/sensor pairs to write-enable the disk, with the
obvious state table. Of course this would add $5 or more to the disk drive
cost, for a possibly rare failure mode...
Bart Massey bart@cs.uoregon.edu
5.25" floppies' copy-protect is a risk because it is backwards from every other magnetic medium I have ever encountered. The standard is: You insert something to permit writing and remove it to protect. This is true for: -9-track tape (write rings) -VHS video cassette -audio cassette -8" floppy -3.5" floppy How come 5.25" floppies are backwards? --Bruce 213/333-3538
"If dust prohibits sensing the position, or the detector/light
source fails, the drive will incorrectly assume that the disk
should be writable."
The RISK of assuming a particular implementation. My Panasonic 3.5"
floppy disk drive senses the tab position by attempting to insert a
metal probe into the hole. A successful insertion means that the disk
can be written. The likely failure modes would falsely indicate
unsuccessful insertion, i.e., write prohibited.
-=- Andrew Klossner (andrew@frip.wv.tek.com)
(uunet!tektronix!frip.WV.TEK!andrew)
I noted a comment in Cliff Stoll's message that he had the perception that virus events and interest were kind of winding down. I just wanted to comment that, indeed, the messages-per-week posted on some of the local hacker bbs virus groups has been dropping off steadily for months. In one case the "group" was deleted to make room for something else! Humanity can only write so many payroll programs right? Most viruses seem to be re-hashes of existing ones. Perhaps the fun is deflating? The idea of a helpful virus is an interesting one. Perhaps one that would sense when your PC is locked up and warm-reboot? HA. I suppose that a helpful virus would really be called a commercial TSR? Mark Hittinger [answ.machine] (606)-272-2424 PO BOX 43358 Middletown, KY 40243
In <RISKS DIGEST 12.27> Cliff Stoll retells Fred Cohen's article which describes how viruses and virus-like programs can be beneficial. >automated bill-collectors, where, "each bill collector virus is a >small program designed to collect one bill"; this program modifies >itself depending on the debtor's response. [...] maintenance >viruses which dispose of temporary files or hung programs. I fail to see how these programs are virus-like. The first is a self- modifying program, and the second is what might be called a daemon. Neither program is (or in the second example, needs to be) self-reproducing. The only example of a `beneficial virus' I can think of is the one that was released to fight another virus, namely the `Animals' program. The problem with viruses of either sort (in my unqualified opinion) is that once released, they are hard to exterminate. Another (more likely?) possibility is that I'm completely misunderstanding the brief excerpt from Dr. Cohen's article.
I wonder whether Dr. Cohen's bill collector virus included a provision for an audit trail, say by appending a record of every transaction to a database? His "The Sciences" article mentions no such device, and indeed boasts the lack of any large permanent database as an advantage. Feature or bug?
I don't know about the *most* useful, but one very useful virus would be a
virus that identifies and destroys other viruses. I suppose it would have to
be more virulent that the others.
Whoever implements this, please don't forget to program in some appropriate
self-destruct condition...
(Maybe there should be an RFC to cover that topic.)
Dave
desint!geoff@uunet.UU.NET (Geoff Kuenning) writes: "Remember that, by definition, 50% of the population is of below-average intelligence," [David goes on to shoot down this old war-horse... once again... I truncated the rest of his message, but would like to remind our contributors that it really helps if you are alert enough to avoid the mistakes that have already been kicked around in back issues. See Mark Seecof's note in RISKS-12.11 that included counterexamples from Tim Smith and Jeremy Grodberg... And thanks to those of you who are on your toes. PGN]
CALL FOR PAPERS
Seventh Annual Conference on Computer Assurance
The Seventh Annual Conference on Computer Assurance (COMPASS), sponsored by
the Institute of Electrical and Electronic Engineers and IEEE Aerospace and
Electronic Systems Society, in cooperation with the British Computer Society,
will be held at the National Institute for Standards and Technology in
Gaithersburg, Maryland, USA, June 15-18, 1992. The purpose of this conference
is to bridge the gap between emerging technology for computer assurance from
research laboratories into industrial computer systems development. Papers may
present original research on theoretical aspects and applications of technology
to assured computing, or may be reports detailing experiments, evaluations, and
open problems in the use of new technologies for computer assurance. Typical
but not exclusive topics of interest include:
* Models and modelling (process, mathematical, and requirements models)
* Formal approaches (proofs of correspondence, formal specifications,
and IV&V)
* Experiences with assurance (illustrative examples from communications,
energy, financial, medical, military, transportation, and other
types of systems)
PAPER SUBMISSION:
Authors are requested to send five single-sided copies of their papers (not
exceeding 7,500 words) to the program chair by January 10, 1992. If available,
an electronic mail address for the contact author should be included. Papers
submitted simultaneously to another conference with published proceedings are
disqualified. Papers will be refereed by the Program Committee and will be
returned with comments. Accepted papers will be published in the proceedings.
IMPORTANT DATES:
Papers due: January 10, 1992
Notification of acceptance: March 7, 1992
Camera-ready paper due: April 1, 1992
Conference: June 15-18, 1992
Additional information about the COMPASS '92 can be obtained from the
General Chair. All inquiries concerning paper submissions should be addressed
to the Program Chair.
GENERAL CHAIR: PROGRAM CHAIR:
Robert Ayers Dr. Edgar H. Sibley
ARINC Research Corporation Department of Information and
2551 Riva Road Software Systems Engineering
Annapolis, MD 21401 USA George Mason University
voice: (301)266-4741 4400 University Drive
fax: (301)266-4040 Fairfax, VA 22030-4444 USA
(703)993-1640, or esibley@gmuvax.gmu.edu
Please report problems with the web pages to the maintainer