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…
We were having the whole family for a Hannukah party last week. Grandpa sat at a chair next to the PC (which was up and running Windows), holding six-month-old May in his arms. Being a digital kid, she quickly reached for the keyboard. By the time we noticed and managed to turn off the computer, half the system files were gone (which is what we discovered the next day, when the system started to behave strangely). Trying to figure out what had happened, it seems little May could only reach the bottom line of the keyboard — but that's where the ALT, ENTER, DELETE and the arrow keys are! In Windows 3.1, ALT puts the cursor into the command menu, ENTER activates the menu item it's on; in some menu, DEL deletes the marked files... Amos Shapir nSOF Parallel Software, Ltd. Givat-Hashlosha 49905, Israel amos@nsof.co.il Tel: +972 3 9388551 Fax: +972 3 9388552
A story with entertainment value, albeit no clear moral: A couple of nights ago I was working away at my workstation when the world (figuratively) collapsed: suddenly all my network connections had gone haywire. A little investigation revealed that /etc/hosts, the file that lists names and IP addresses for the rest of the universe, had become corrupted: it had huge quantities of null characters in it and very little useful data. How had that happened? After some poking around and much thought, I came to the following conclusion. I've recently been setting up some machines for a few of my colleagues. The most straightforward way of getting those machines into a sensible initial state, I thought, would be to restore the dump tapes from my own machine onto theirs. After all, I keep my machine in pretty decent shape. Of course there was no need to restore my home directory on each machine. Instead, I told each of the other machines that my home directory was really a link to the mounted file system that contained my home directory on my `home' machine. All pretty routine so far, but that turned out to be cause number 1. Cause number 2 was that when I cloned my machine, what I cloned included /usr/spool, the directory with all the spool files. That directory includes files that tell cron, a program that starts background jobs at particular times, what jobs to start. That meant that the `midnight' job that normally ran on my home machine now ran automatically on each of several machines. Because my home directory was mounted on each of these machines, that job did its thing simultaneously several times in the same directory. Cause number 3 was that my midnight job, among other things, extracts a complete new /etc/hosts file from one of our other servers and installs it. It checks that what it got is sane, to defend against /etc/hosts becoming empty when the server is down, but of course it doesn't defend against having several instances running at the same time. So what must have happened is that two of those instances finally hit the same file at the same time, causing parts of it to overlay other parts and general chaos to ensue. Andrew Koenig ark@research.att.com
This Monday, 5 December 1994, I was traveling with a colleague from Denver Stapleton to Newark on United flight 302, supposed to leave at 6:06 PM. When we got to the airport at 3:30 (in plenty of time to beat threatened snow), the baggage check-in agents were not actually checking-in passengers but simply tagging bags by hand, because a power failure had brought down the check-in database servers. After the bags where checked in, we were directed to another agent that looked up the gate for flight 302 on a printout. Actual passenger seat assignment and check-in was to be done manually at the gate. Since we were early, we waited at the gate until 5 PM, not wanting to bug the overworked gate agents until near our scheduled departure. But when we talked to the gate agent soon after 5 PM, she told us that she had no information about flight 302; some other flight was due to leave that gate too close to 6:06 PM to allow time for flight 302, and she had no way of finding out where 302 was supposed to be. She finally told us to call the central 800 number for United reservations to check the gate info! My colleague is a United Premier member. He called the Premier help desk, who gave him another gate number for a supposedly on-time departure. He communicated that information to the original gate agent, who proceeded to announce it over the PA for other 302 passengers without further confirmation from any other authority. We went to the new gate, where we found neither plane nor gate agents. We asked the agent at the next gate for help. He knew nothing about 302, and expected some other flight to use the empty gate. His paper notes indicated the original gate for 302. But he eventually called around, and found out yet another supposed gate for the flight. Third time lucky. That turned out to be the correct gate, although its electronic flight info display was showing a different flight. All the departures monitors in the terminal were also showing outdated and scrambled information without any indication of its incorrectness. Enterprising gate agents were taping paper signs with correct flight numbers over the bogus electronic signs. But the problems were not over. The plane for flight 302 arrived, we boarded, and were supposed to leave just 20 or so minutes late. Except that the flight crew was delayed in an incoming flight, and that information, normally handled by the downed computer system, was not made available to the ground staff for assignment of an alternate crew. We ended leaving around 1 1/2 hour late. This all happened in a relatively light traffic non-holiday Monday, in pretty good weather (the snow didn't materialize). I can't imagine what the chaos would have been like around a major holiday. It was clear from all our interactions with all the gate agents that they were not operating according to a well-designed, well-drilled manual backup procedure. They behaved professionally for the most part in a difficult situation, but much of what they were doing seemed decided on the spot, from personal initiative, and without good phone access to an authoritative manual database of flights and gates, even though that information was obviously still available to the air-traffic and airport systems, given that flights were still landing and taking off. Fernando Pereira, 2D-447, AT&T Bell Laboratories, 600 Mountain Ave, PO Box 636 Murray Hill, NJ 07974-0636 pereira@research.att.com
Time magazine (Aug 9) reports a computer error in a Pepsi promotional lottery in the Philippines. The computer generated 800,000 winning numbers instead of 18. Obviously, Pepsi didn't pay the $32 billion in prize money their mistake would have cost them. Pepsi has paid nearly $10 million in "appeasement" efforts ($20 "goodwill" prize), but this apparently didn't satisfy disgruntled "winners." Over 22,000 people, each of whom believed they had won the $40,000 prize, have filed about 5,000 criminal and 700 civil suits. The Philippine Senate Trade Committee faults the company for "gross negligence" and "misleading or deceptive advertising." If anyone knows any technical details about the nature of this "computer error," I would like to hear about them. John Dalbey, Computer Science Dept, Cal Poly, SLO, CA jdalbey@calpoly.edu
With messages in RISKS about formal verification (not) being applied to commercial processors, this might be a good time to mention the work that's going on across the hallway from PGN: "Formal Verification of the AAMP5 Microprocessor: A Case Study in the Industrial Use of Formal Methods" by Steven P. Miller (Collins Commercial Avionics) and Mandayam Srivas (SRI) To be presented at WIFT '95: Workshop on Industrial-Strength Formal Specification Techniques, April 5-8, 1995, Boca Raton, Florida USA. Available over the web through http://www.csl.sri.com/aamp5.html or by ftp from ftp.csl.sri.com/pub/reports/postscript/aamp5.ps.gz The AAMP5 doesn't have floating point, but it is a real processor with a pipeline, microcode, and 500,000 transistors (it's a derivative of the AAMP2, of which there are 30 on board each 747-400). John
The NY Times (or was it LA?) a few days ago reported that the double precision fdiv problem in the Pentium is due to a table that was incorrectly copied from the 486 — not an algorithmic bug. Many formal approaches would not have caught this kind of error since it would have been natural to assume that the table was correct (I mean, after all, it was generated by computer!) Also, one of the floating point bugs in a previous x86 processor (I think it was the atan bug in the 486) was due to electrical difficulties -- the algorithm was correct, but the electrons had different ideas in a certain case. This is a class of errors that only testing or circuit simulation with accurate device models can catch. Mark Stalzer, mas@acm.org [Also noted by "Jeffrey P. Bradford" <jbradfor@ecn.purdue.edu>, who added, "We all know computers make mistakes, either HW or SW, and any results from computers need to be compared against common sense." PGN]
When the T800 came out, my then employers (FEGS Ltd) were working on a research project in collaboration with INMOS and several other partners. At one point INMOS told us they had had to halt production of T8's after a bug had been found in the floating-point microcode, resulting in the wrong result being given for some IEEE-defined special case (I think it was zero divided by zero giving the wrong flavour of NaN). I think the bug was found by the formal verification process, of which they were certainly very proud. One more point is worth mentioning: the T800 is a very simple chip architecture compared to something like the Pentium, and I would guess formal verification of the latter would be a much larger task. Patrick
Perhaps this is a case of less RISK for RISCs! (sorry, couldn't resist) Inmos formally proved only the FPU: they didn't do it for the whole processor. Does the Pentium implement so many more floating point operations that proof is intractable? Mathew Lodge, Software Engineer, Schlumberger Technologies, Ferndown, Dorset, UK, BH21 7PP lodge@ferndown.ate.slb.com (+44) (0)202 893535 x404
Proving that the algorithms used are correct is one thing, but getting a correct implementation of those algorithms in silicon is another, and that's where the testing comes in. Steve_Kilbane@cegelecproj.co.uk
Some staff from Inmos gave a talk here some time ago on their procedure for verifying a floating-point implementation. Their experience was slightly more interesting than Mathew suggested. Apparently, in addition to their formal model they had a "known correct" implementation built by a competitor. All tests were verified against this reference implementation. At one point during testing they found that their implementation disagreed with the reference implementation and spent quite some time trying to diagnose the fault. It turned out that their implementation had been correct first time, but that they had discovered a bug in a competitor's product. No prizes for guessing who built the reference implementation Mark
Rob Slade's review of Schneier's book "Applied Cryptography" should have mentioned that the book contains a substantial number of typos, and that Schneier offers an errata sheet (schneier@chinet.com). This will be especially important if you try to use the programs in the appendix. I like the book. Rich Schroeppel rcs@cs.arizona.edu
With all this talk about self extracting mail "viruses", a friend showed me that in emacs (which I use to read mail, along with vm) has the ability to self-extract elisp code. This feature seems to be turned on by default, and it not only applies to mail read with emacs, but rather every file visited (when the feature is on, of course). The way it works is by having a line which reads "Local Variables:" followed by the lisp variables you would like to set...well, it may seem petty, but you can execute programs, make connections and much more through cleverly written elisp code contained within. It's simple to turn off, at any rate... (setq enable-local-variables f) ;; turns off feature (in emacs 19) (setq enable-local-variables 1) ;; makes it ask first (in emacs 19) (setq inhibit-local-variables t) ;; turns off feature (in emacs 18) Anyhow, I think the risks here speak for themselves...
Shareware has a bad rap as a carrier of computer viruses. But one of the commercial software industry's dirtier little secrets is that viruses often get transmitted via shrink-wrapped boxes in stores. Or, sometimes, viruses just get sent to computer writers. A California company called Bit Jugglers called me today to say a title they'd sent me, Kids World, was infected with a virus. This only happened to the copies sent to the press — those folks who write about computer software in magazines or newspapers. The virus did not make it into copies shipped to stores. Bit Jugglers urged me to destroy my copy of Kids World. And if I'd installed the software (I have not), they would have sent me the latest version of McAfee's Scan, a virus detection program. A new, clean copy is on its way to my desk. The moral of the story is obvious. Trust NO floppy — you don't know where it's been. Scan everything. Dwight Silverman The Houston Chronicle, Computer columnist dwight.silverman@chron.com 713-220-6873 Fax: 713-220-7273 Audiotext: 713-468-7866 ext. 1001
> I have received it 4 times now from different sources.) Obviously, the alert itself _is_ the virus. Watch: <>I have just received this message and been asked to take it seriously: This gets the virus scheduled on the CPU (note that it occurs at the beginning of execution). <>There is a virus on America Online being sent by E-Mail. If you get This is the target architecture and operating system: AOL users. Note that it also works on similar architectures with different operating systems. <>anything called "Good Times", DON'T read it or download it. It is a <>virus that will erase your hard drive. This is something that looks like a useful message to fool the user while the virus does its work. <>Forward this to all your friends. <>It may help them alot. ...and this is the propagation code. ;-) Zygo Blaxell, Math student at the University of Waterloo. System/network admin for the Computer Science Club and miranda.
I'm sure that I am not the only RISKS reader who has been bombarded by warnings regarding the supposed "Good Times" virus. Just about all of the warnings I received were forwarded from two or three previous people, said that the virus was distributed from America On-Line, and claimed that if you were to download or read the message (which had a subject of "Good Times"), your hard disk could be reformatted. Each copy of the warning then suggested that people forward the warning to as many other users and mailing lists as possible, because of the severity of the problem. I've seen at least one announcement from CIAC (at least, I *think* it was from CIAC) telling people that there is indeed no virus, that most mail readers won't automatically execute programs sent via e-mail, and that people generally shouldn't worry. There seem to be several risks associated with this incident: (1) People don't understand what e-mail can and cannot do. Most of the people forwarding the warnings didn't understand the difference between viewing a mail message and turning the contents of that message into an executable program, let alone the fact that different platforms work differently and thus would require separate viruses. (2) Rumors spread quickly. I was amazed to see just how fast this rumor spread; within a 24-hour period, I saw a dozen or so copies of the warning on five or six different mailing lists. People wanted to help their fellow users (a good thing), but passed the warning on without verifying the rumor's validity (a bad thing). You could probably make a good argument that the warning itself was a virus! (3) Explanations spread slowly. More than two days after I first saw the virus warning, people continued to forward copies of it to various mailing lists — even after I and others told list members that the virus announcement was probably a hoax. It will probably be another few days before the CIAC warning (along with assurances from computer experts) reaches all of the people who are no longer sure whether it is safe to read their e-mail. (4) Bugs do exist. The fact is that there probably are holes in mail readers that will do nasty things to people's files and accounts. But now that people have been told not to worry, they'll take future warnings less seriously. Without a universally known and trusted authority on these issues — and let's face it, most users would probably trust their friends more than CIAC or CERT — this may turn into the computer equivalent of the children's story, "The Boy Who Cried Wolf." Reuven
David M. Balenson, Program Co-Chair, ISOC '95 SNDSS Trusted Information Systems, 3060 Washington Rd., Glenwood, MD 21738 USA balenson@tis.com; tel 301.854.6889; fax 301.854.5363 THE INTERNET SOCIETY SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY 16-17 FEBRUARY 1995 CATAMARAN HOTEL - SAN DIEGO, CALIFORNIA The symposium will bring together people who are building software and/or hardware to provide network and distributed system security services. The symposium is intended for those interested in the more practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than in theory. We hope to foster the exchange of technical information that will encourage and enable the Internet community to apply, deploy and advance the state of the available security technology. P R E L I M I N A R Y P R O G R A M [meals, breaks, registration info removed by PGN] WEDNESDAY, FEBRUARY 15 6:00 P.M. - 8:00 P.M. REGISTRATION AND RECEPTION THURSDAY, FEBRUARY 16 7:30 A.M. CONTINENTAL BREAKFAST 8:30 A.M. OPENING REMARKS 9:00 A.M. SESSION 1: DIVERSE APPROACHES TO SECURITY AT THE NETWORK LAYER Chair: Stephen T. Kent (Bolt, Beranek and Newman, USA) Multicast-Specific Security Threats and Counter-Measures, Tony Ballardie and Jon Crowcroft (University College London, United Kingdom). Design of a Key Agile Cryptographic System for OC-12c Rate ATM, Daniel Stevenson, Nathan Hillery, Greg Byrd, and Dan Winkelstein (Microelectronics Center of North Carolina - MCNC, USA). IpAccess: An Internet Service Access System for Firewall Installations, Steffen Stempel (University of Karlsruhe, Germany). 11:00 A.M. SESSION 2: PANEL: SECURITY ARCHITECTURE FOR THE INTERNET INFRASTRUCTURE Chair: Robert W. Shirey (The MITRE Corporation, USA) Security for the Internet Protocol (IP) and IP Next Generation, Paul A. Lambert (Motorola, USA). Security for the Internet Domain Name System, James M. Galvin (Trusted Information Systems, USA). Security of Routing Protocols in the Internet, Gary Scott Malkin (Xylogics, USA). Security Approaches to Routing in the Internet, Sandra L. Murphy (Trusted Information Systems, USA). 2:00 P.M. SESSION 3: OFF-LINE OBJECT DISTRIBUTION SECURITY Chair: Jeffrey I. Schiller (Massachusetts Institute of Technology, USA) Trusted Distribution of Software Over the Internet, Aviel D. Rubin (Bellcore, USA). Location-Independent Information Object Security, John Lowry (Bolt Beranek and Newman, USA). 3:30 P.M. SESSION 4: INTERNET PAYMENTS Chair: Ravi Ganesan (Bell Atlantic, USA) Electronic Cash on the Internet, Stefan Brands (Centrum voor Wiskunde en informatica - CWI, The Netherlands). PANEL: Internet Payment Mechanisms - Requirements and Architecture Chair: Ravi Ganesan (Bell Atlantic, USA) Panelists: B. Clifford Neuman (Information Sciences Institute, USA), David Crocker (Brandenburg Consulting, USA), and others TBD 7:00 P.M. DINNER BANQUET FRIDAY, FEBRUARY 17 8:30 A.M. SESSION 5: SECURITY MONITORING TOOLS - PRACTICE AND EXPERIENCE Chair: Michael St. Johns (Advanced Research Projects Agency, USA) NERD: Network Event Recording Device: An Automated System for Network Anomaly Detection and Notification, David G. Simmons and Ronald Wilkins (Los Alamos National Laboratory, USA). An Overview of SNIF: A Tool for Surveying Network Information Flow, Jim Alves-Foss (University of Idaho, USA). Distributed Audit Trail Analysis, Abdelaziz Mounji, Baudouin Le Charlier, Denis Zampunieris and Naji Habra (Facultes Universitaires de Namur - FUNDP, Belgium). 10:30 A.M. SESSION 6: AUTHENTICATION AND AUTHORIZATION Chair: B. Clifford Neuman (Information Sciences Institute, USA) SESAME V2 Public Key and Authorisation Extensions to Kerberos, Piers McMahon (ICL, United Kingdom). Yaksha: Augmenting Kerberos with Public Key Cryptography, Ravi Ganesan (Bell Atlantic, USA). GSS-API Security for ONC RPC, Barry Jaspan (OpenVision Technologies, USA). 1:30 P.M. SESSION 7: MECHANISMS OF IDENTITY - THE CERTIFICATE INFRASTRUCTURE Chair: Hilarie Orman (University of Arizona, USA) A Certificate Management System: Structure, Functions and Protocols, Nada Kapidzic and Alan Davidson (Stockholm University & Royal Institute of Technology, Sweden). PEMToolKit: Building a Top-Down Certification Hierarchy for PEM from the Bottom Up, Alireza Bahreman (Bellcore, USA). A New Approach to the X.509 Framework: Allowing a Global Authentication Infrastructure Without a Global Trust Model, Suzan Mendes (TS-E3X - Research and Development Center, France) and Christian Huitema (INRIA, France). 3:30 P.M. SESSION 8: PANEL: SECURITY ISSUES FOR MOSAIC AND THE WORLD WIDE WEB Chair: Fred Avolio (Trusted Information Systems, USA) Panelists: Peter J. Churchyard (Trusted Information Systems, USA), Allan M. Schiffman (Enterprise Integration Technologies, USA), and Bill Cheswick (AT&T Bell Laboratories, USA) GENERAL CHAIR James T. Ellis, CERT Coordination Center, Carnegie Mellon University PROGRAM CO-CHAIRS David M. Balenson, Trusted Information Systems Robert W. Shirey, The MITRE Corporation FOR MORE INFORMATION, contact Gloria Carrier by phone at (703)-883-4508 or via email to gcarrier@mitre.org.
Please report problems with the web pages to the maintainer