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…
A cute article by Joan E. Rigdon in the *San Francisco Sunday Examiner and Chronicle* Computers & Technology section (``How do you spell dated? MS Word hasn't brought dictionary into cyber-age'' — 26 Nov 1995, B-5) points out that the Word spellchecker makes the following suggestions for words that putatively would seem important to Microsoft:
Internet --> interment
Internet's --> internee's
e-mail --> emboli (blood clots)
cybershoppers --> [no suggestions]
Netscape --> [no suggestions, although pretending that your competitors don't exist is a nasty strategy.
Ms. Rigdon also notes that Microsoft should have received adequate warning last December when the *Dallas Morning News* ran a garbled story resulting from an editor accidentally accepting all of the alternative spellings, including the following conversions:
Intel --> Until
Microsoft --> Microvolts
As noted in RISKS on numerous occasions, our archives are full of such transgressions (most recently, see RISKS-17.32). [Transgreshams Law, I suppose.] Similar to MS ignoring Netscape was Scott Siege's item in RISKS-15.72 that the Apple MacIntosh spellchecker suggested changing "Laserwriter" to "Laserjet" (not surprisingly, an Apple product).
The Oakland airport radar failed again on 29 Nov 1995 for about two hours, beginning at 9:44am. ("The cause ... was not known.") Backup radar at Moffett Field was used; however, it covers a smaller area, and delays were incurred on 17 takeoffs at SFO. There had also been a brief failure on 28 Nov 1995, but it caused no disruption. Usual statements were made about how safety was not impaired and no one should be concerned. FAA spokesman Mitch Barker said, "We don't let it operate if it's not safe." He was also quoted in a made-for-RISKS statement: "Things are going to go wrong from time to time, especially with a system as complicated as this."
[Source: *San Francisco Chronicle*, 30 Nov 1995, A13. For further
background, the August 1995 Fremont (Oakland) ATC outage is discussed beginning in RISKS-17.24 to 28. Another Fremont outage earlier this month required the backup system to be used for two days, but was not reported in
RISKS at the time. Other ATC problems are also noted in recent RISKS — in Chicago (17.35) and Las Vegas (17.41). The system may be safe, but it does not seem sound.]
Christopher Pile, 26, the first person in Britain to be convicted of creating computer viruses, was jailed for 18 months. His creations (Pathogen and Queeg) were apparently rather sophisticated stealth viruses that used an encryption program (Smeg) to hide their presence.
According to a front-page story by James W. Roberts in the 29 Nov 1995 _Asbury Park Press_ (NJ), a student at Monmouth University has been charged
with disrupting the school's electronic mail system for five hours by bombarding two adminstrators with 24,000 e-mail messages. The student's computer access had been terminated on 9 Nov 1995 because of posting advertising and business venture
solicitations to "inappropriate sections of the Internet" (presumably, Usenet groups).
It took 44 hours to trace the source of the attack through a service provider in Atlanta, GA and back to an account based in Red Bank, NJ, shared by the student. The student is being charge with a federal crime because of using interstate communication to deny service. Carl Stern of the Justice Department is said to have remarked that this is the first time the federal computer fraud act has been used for an act of this type.
James E. Burns, Bellcore, NVC-3X114, 331 Newman Springs RoadRay Panko's story of being outsmarted by Excel trying to be clever in dealing with percentages reminded me of my recent struggles with WordPerfect 6.1.
I recently started using WordPerfect 6.1, upgrading from 5.2. It has some nice features, but several strange things happened:
I recently underwent total hip replacement surgery. As part of the procedure, for pain control, the doctors fitted me with an intravenous infusion system that gave me a continuous morphine feed in fluids at a constant rate. The system used two intravenous infusion (IV) pumps, one to feed the morphine into the carrier fluids (a potassium salt solution, I think), and the other to feed the carrier fluids into me. Both pumps were capable of operation from AC line or from internal rechargeable batteries; this allows the patient to be transferred from the surgical suite to the various other wards of the hospital without worrying about extension cords on the way. The pumps have an audible alarm, and there are several illuminated icons on the front panel to indicate the reason for the alarm.
Morphine is a controlled narcotic, and IV pumps for morphine have a number of special features. The morphine is carried in a large syringe that is mounted inside the pump, behind a locking panel cover. The programming controls for the pump are behind the locking panel as well; the pump cannot be set up or reset without the key. There is a patient-operated demand switch, with an associated programmable lockout time, that allows the patient to get an extra boost on demand, but no more often than the certain interval. The patient is expected to use the switch if he anticipates a need for more pain control than the baseline; this happens for example when the patient is transferred between beds, or when the physical therapists enter the room. (The physical therapists do a very necessary job that is unfortunately not a whole lot of fun for the patient.) Additionally, the physician will generally allow the patient to request an additional booster dose from the nurse, at longer intervals.
Because of other medical concerns, I spent the first 24 hours or so post-op in intensive care, rather than going immediately to the orthopedic floor. When we transferred me up to orthopedic, the ICU nurses rearranged everything, loaded the pumps onto a conventional IV tree, switched them over to battery operation, and we were on our way.
Transferring a patient from an ICU bed/gurney to a standard hospital bed is something of a production, requiring several nurses to lift and a patient not to scream. Then all the various hoses coming out of the patient have to be arranged, the IV pumps situated, power cords plugged in, and etc. etc.
About an hour after the transfer to orthopedic was completed, one of the IV pumps alarmed. I called the nurse's station and told them "alarm on the IV pump". I couldn't see the pump face to see which alarm indicator was on. A nurse, not the one assigned to me, came in, said, "Oh, that is just the battery alarm; you don't have to listen to that; I'll silence it." She did something on the front panel of the morphine pump, and the alarm stopped. I asked whether the pumps were in fact plugged in; she glanced at the power cords and said they were.
A few minutes later, the assigned nurse came in, just as I was starting to notice discomfort building up. She asked about the alarm; I explained; she checked the morphine pump, and discovered that it had just shut down from battery exhaustion. She had to go get the patient chart and the safety key and reprogram the pump, after plugging it into the wall.
The risks in the above design should be evident. 1) There should be an unequivocal indication, continuously present, that the pump is running on batteries. 2) There should be no operator procedure, other than getting the pump running on AC line power, or shutting it off completely, to silence a low-battery alarm. 3) Personnel have to be trained to think about WHY a particular alarm is sounding, and the implications of the alarm, BEFORE they reach for a "Silence" key.
The story from <M.Cushman@lse.ac.uk> about multiple failures of back-ups in RISKS-17.48 reminded me of a somewhat similar incident which I perpetrated many years ago while working in the Service Programming Department at ICL in Stevenage.
The main programming effort was concentrated in the Executive Programming Department. (The basic operating system on the ICL 1900 series was referred to as an "executive". There was a more powerful operating system known as GEORGE 3, but this ran on the larger machines in the range. Stevenage was responsible for medium range machines which ran executives. I still think that if ICL had played its cards right, GEORGE 3 could now have been a serious rival to UNIX, but that is a separate story! :-)
Anyway, one task of Service Programming (as well as writing and maintaining editors, assemblers and various utility programs) was to keep back-ups of the source programs. The "executive masters", which were sources from which a compiled executive for any hardware configuration could be derived, were big beasts. The back-up involved running a disk-to-tape copy program, using a grandparent-parent-child cycle of three pairs of tapes. If a pair of tapes became full, the administrator (me) had literally to go from desk to desk and persuade people to delete their out-of-date sources to make room for the latest ones.
My job included reading the printed operator's log every morning to check that the previous overnight back-up run was OK, and in particular that it had not overflowed the two tapes. Came the day when I had neglected to do this check for a while, and discovered that three nights previously, the back-up had overflowed. All three generations of back-up MT had been overwritten with a truncated copy!
Worse, the stuff that had dropped off the end included executive masters that had not been changed for years. (They were still very live, however, just not under active development.) The on-line medium was exchangeable disk store (EDS). In those days, the largest EDS pack held 8 megabytes, and the department had three drives. Only active sources were kept on-line. The only copies of the masters I had lost resided on those back-up tapes. Ouch!
I confessed. The most polite and least personal comment was from the programming manager: "Oh my God! What are we going to do?"
Fortunately, on the day after the overflow, some of my colleagues had deleted several large files. The result was that Monday night's back-up (for the sake of illustration) had resulted in tape overflow and a truncated copy of the back-up. On Tuesday night and Wednesday night, the actual size of the entire back-up had been reduced, so that the second tape of the pair was nowhere near full. (The back-up procedure was driven by a set of parameter cards which specified which files were to be added and which deleted. The back-up program worked by first copying any new files from disk, then copying the child tapes to the grandparent tapes (overwriting them in the process) omitting files which were declared as "deleted" by its parameters.)
Eureka! The "lost" data might still be there on the end of the second of one of the pairs of tapes. So I took a program which would do a hardware block-by-block read of a magnetic tape, patched into it a modification (in 1900 object code) so that instead of stopping at the "end of tape" (EOT) mark, it halted with a suitable display and could then be restarted to copy what lay beyond EOT, and so copied the tail-end of one of the less than full back-ups.
Sure enough, there were all the files I had "lost"! My annual salary increment began to look healthier!
For some reason, when I told my colleagues how I had saved the day, they were less than impressed by my ingenuity, and unfortunately their responses were couched in language which cannot be repeated in a polite forum such as RISKS! :-)
Peter Mellor, Centre for Software Reliability, City University, Northampton Square, London EC1V 0HB +44 (171) 477-8422 p.mellor@csr.city.ac.uk<> As an aircraft mechanic who once witnessed a returning aircraft
run out of fuel on the taxiway with 5,000 pounds of fuel showing on the gauges, I tend to disagree.
This triggers an old memory: In April 1971, my then boss bought a new Pontiac Bonneville wagon. He thought he was getting GREAT gas mileage. He was driving all over Northern Virginia and the gauge hadn't moved since leaving the dealership. The gauge was still registering 3/4ths of a tank when the car ran out gas. What had happened was that the float arm had been spot welded (accidentally? bored autoworker?) in place.
[Permission granted ... to redistribute ... electronically or otherwise as long as the entire file is printed without substantive modification.]
I differ from the current practice of grouping online activity, information theft, and component theft into "high tech" crimes. While I feel strongly that most malintentioned online activity is covered as an instantiation of existing law and practice, it is a different kind of activity from stealing chips. In my mind, hijacking a truckload of RAM chips is just like hijacking a truckload of flavorings destined for a food plant, or grabbing a package out of the hands of someone just leaving a jewelry store: simple theft of valuable material with low traceability. True "Internet crime" might be using a hole in security to gather information about another system; and that's no different in intent from using an insecurely-locked door to breach the physical security of the building to get at the same system.
Reductio ad absurdum: If someone breaks into my house and steals my silverware, that's low tech crime; if they steal my computer, it's high-tech crime; and if they take the stereo, it's medium-tech crime.
We should educate the press and public on this matter, before we find carjacking considered a "high-tech" crime because of the engine computers.
-Harlan RosenthalCorporate America is emerging from a lengthy state of denial, and beginning to take measures to protect its electronic assets. Nearly half of the respondents to an Information Week/Ernst & Young poll reported having lost valuable information during the past two years, with at least 20 saying they'd lost information worth more than $1 million. Nearly 70% said security risks had worsened in the last five years, and nearly 80% now have a full-time information security director. As one analyst noted, "As organizational structures are flattened, corporate reliance on the availability and integrity of information systems is becoming painfully obvious." (*Information Week*, 27 Nov 1995, p32)
CERT Summary CS-95:03, November 28, 1995
The CERT Coordination Center periodically issues the CERT Summary to draw attention to the types of attacks currently being reported to our incident response staff. The summary includes pointers to sources of information for dealing with the problems. We also list new or updated files that are available for anonymous FTP from ftp://info.cert.org
Past CERT Summaries are available from ftp://info.cert.org/pub/cert_summaries
* * * * *
RECENT ACTIVITY
Since the September CERT Summary, we have seen these continuing trends in incidents reported to us. The majority of reported incidents fit into four categories:
We continue to see daily incident reports about intruders who have installed sniffers on compromised systems. These sniffers, used to collect account names and passwords, are frequently installed with a kit that includes Trojan horse binaries. The Trojan horse binaries hide the sniffer activity on the systems on which they are installed.
For further information and methods for detecting packet sniffers and Trojan horses, see the following files:
ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks
ftp://info.cert.org/pub/cert_advisories/CA-94:01.README
ftp://info.cert.org/pub/cert_advisories/CA-94:05.MD5.checksum
ftp://info.cert.org/pub/cert_advisories/CA-94:05.README
The vulnerability described in CERT advisory, CA:95:15 "SGI lp Vulnerability" continues to be exploited, though we have seen a decline in the number of reports since the advisory was released on November 8. Intruders gain unauthorized access to Silicon Graphics, Inc. (SGI) IRIX systems through a passwordless lp account; they use this initial access to leverage additional privileges on the compromised system.
As distributed by SGI, the lp account (as well as other accounts), has no password on a newly installed system. This fact is addressed in the documentation that SGI distributes with their systems: "IRIX Advanced Site and Server Administrative Guide" (see the chapter on System Security). More information on this vulnerability and how it can be addressed can be obtained from
We continue to receive several reports each week of intruders using the Internet Security Scanner (ISS) to scan both individual hosts and large IP address ranges. The ISS tool, which is described in CERT advisory CA-93:14 "Internet Security Scanner", interrogates all computers within a specified IP address range, determining the security posture of each with respect to several common system vulnerabilities. Intruders use the information gathered from such scans to gain unauthorized access to the scanned sites.
As part of a defensive strategy, you may want to consider running ISS against your own site (in accordance with your organization's policies and procedures) to identify any possible system weaknesses or vulnerabilities, taking steps to implement security fixes that may be necessary. ISS is available from
ftp://info.cert.org/pub/tools/iss/iss13.tar
More information about the ISS tool and steps for protecting your site are outlined in the following documents:
ftp://info.cert.org/pub/cert_advisories/CA-93:14.Internet.Security.Scanner
ftp://info.cert.org/pub/cert_advisories/CA-93:14.README
ftp://info.cert.org/pub/tech_tips/security_info
ftp://info.cert.org/pub/tech_tips/packet_filtering
New reports of intruders attacking sites through sendmail vulnerabilities are continuing to arrive daily, although most reports indicate the attacks have failed. The types of attacks are varied, but most are aimed at gaining privileged access to the victim machine.
We encourage sites to combat these threats by taking the appropriate steps, described in the following documents:
ftp://info.cert.org/pub/cert_advisories/CA-95:05.sendmail.vulnerabilities
ftp://info.cert.org/pub/cert_advisories/CA-95:05.README
ftp://info.cert.org/pub/cert_advisories/CA-95:08.sendmail.v.5.vulnerability
ftp://info.cert.org/pub/cert_advisories/CA-95:08.README
ftp://info.cert.org/pub/cert_advisories/CA-95:11.sun.sendmail-oR.vul
ftp://info.cert.org/pub/cert_advisories/CA-95:11.README
WHAT'S NEW in the CERT FTP Archive
We have made the following changes since the last CERT Summary (September 26, 1995).
* New Additions
ftp://info.cert.org/pub/cert_advisories/
CA-95:12.sun.loadmodule.vul
CA-95:13.syslog.vul
CA-95:14.Telnetd_Environment_Vulnerability
CA-95:15.SGI.lp.vul
ftp://info.cert.org/pub/cert_bulletins/
VB-95:07.abell (lsof)
VB-95-08.X_Authentication_Vul
ftp://info.cert.org/pub/tools/sendmail
sendmail/sendmail.8.7.1.tar
sendmail/sendmail.8.7.1.tar.Z
* Updated Files
ftp://info.cert.org/pub/cert_advisories/
CA-93:16a.README (sendmail - note to use smrsh with all versions)
CA-95:05.README (sendmail - date of Digital Equipment's patch)
CA-95:08.README (sendmail - note to use smrsh with all versions)
CA-95:10.README (ghostscript - patches and explanations)
CA-95:13.README (syslog - information from vendors)
CA-95:14.README (telnetd - information from vendors; correction to compilation example)
ftp://info.cert.org/pub/tools/cops
README (more recent email address for COPS author Dan Farmer)
* * * * *
HOW TO Contact the CERT Coordination Center
Email cert@cert.org
Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST
(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours.
Fax +1 412-268-6989
Postal address
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
To be added to our mailing list for CERT advisories and bulletins, send your email address to
cert-advisory-request@cert.org
CERT advisories and bulletins are posted on the USENET news group
comp.security.announce
If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the email be encrypted. We can support a shared DES key, PGP, or PEM (contact CERT staff for details).
Location of CERT PGP key
ftp://info.cert.org/pub/CERT.PGP_key
* * * * *
Copyright © 1995 Carnegie Mellon University
This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and credit is given to the CERT Coordination Center.
CERT is a service mark of Carnegie Mellon University.
The conference committee for the 11th Annual Computer Security Applications Conference (ACSAC) is proud to announce the conference home page. It is available on the world wide web at:
http://www.isse.gmu.edu/~csis/acsac/acsac95.html
Vince Reed, CISSP[The next conference is 11-15 Dec 1995. Joe Bob says check it out. PGN]
[A Postscript version of the full announcement is available on the AMAST'96
WWW page, at URL: http://www.pst.informatik.uni-muenchen.de/amast96/ — this version is starkly reduced by PGN.]
[To subscribe to the AMAST'96 mailing list: amast96-request@informatik.uni-muenchen.de]
AMAST '96, July 1-5, 1996
Fifth International Conference on Algebraic Methodology and Software Technology
Ludwig-Maximilians-Universitaet, Munich, Germany Call for Systems Demonstrations
The major goal of the AMAST Conferences is to put software development technology on a firm, mathematical foundation. Particular emphasis is given to algebraic and logical foundations of software technology. An eventual goal is to establish algebraic and logical methodology as a practically viable and attractive alternative to the prevailing ad-hoc approaches to software engineering. We invite submissions of system demonstrations showing the improved effectiveness of software developed on a mathematical basis.
The topics of interest include, but not limited to, the following: SOFTWARE DEVELOPMENT ENVIRONMENTS
SUPPORT FOR CORRECT SOFTWARE DEVELOPMENT
SYSTEM SUPPORT FOR REUSE
TOOLS FOR PROTOTYPING, VALIDATION AND VERIFICATION
THEOREM PROVING SYSTEMS
We invite prospective authors to submit 6 copies of system demo proposals (4 double spaced pages maximum) in an area relevant to the conference theme. Papers should provide adequate information for the reviewers to assess the significance and anticipated impact of the system on software technology. All submissions must be sent to the program chair at the address below; the proposals must be received by January 15, 1996 (new extended deadline).
Martin Wirsing, AMAST'96 Program Chair
Institut fur Informatik, Universitaet Munchen
Leopoldstr. 11B
D-80802 Munchen, Germany
Phone: ++49/89/ 2180-6317 Fax: ++49/89/ 2180-6310
e-mail: amast96-info@informatik.uni-muenchen.de
General Chair: Maurice Nivat (France)
Program Chair: Martin Wirsing (Germany)
[Excellent program committee omitted for space reasons. PGN]Invited Speakers include
Proceedings will be published by Springer-Verlag.
For bulletins on current status of the conference:
http://www.pst.informatik.uni-muenchen.de/konferenzen
amast96-info@informatik.uni-muenchen.de
Tools and Demos: cbaur@informatik.uni-muenchen.de
Registration: hennicke@informatik.uni-muenchen.de
Local Arrangements: diem@informatik.uni-muenchen.de
Please report problems with the web pages to the maintainer