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 few of you have received a UUCP message through "cbosgd" that intended to demonstrate that systems are not really very secure and that it is easy to bypass moderation on supposedly moderated news groups. (The message in question was written as a response to someone who thought that this might be difficult!) The existence of that message should not surprise any readers of RISKS, who by now have no trouble grasping the fact that there is no such thing as complete security. However, the message was sent not through RISKS@CSL but through one of our innumerable redistribution points (and thus was received by only a very small fraction of all RISKS readers). The possibility of doing that should not be a surprise, particularly in that most local redistribution centers have been explicitly set up to be automatic forwarders rather than requiring manual intervention. A long time ago Dave Parnas objected to having his position papers on Star Wars serialized in Soft-Eng@MIT-XX and circulated via netmail, partly because there are no guarantees that the received message was actually authentic. (Crypto checksums could be used, although they create a new set of vulnerabilities.) Sooner or later someone will indeed post a bogus message to the entire RISKS group, with fake authorship and bypassing my moderation; I will then have to point out that I stated in RISKS-5.4 (and earlier, as well) that it can of course be done. (I have tried to use TOPS-20 as sensibly as possible to make such immoderation nontrivial, but I cannot seal off that possibility altogether.) Besides, I would like to believe that the RISKS community consists mostly of socially conscious and thoughtful individuals, interested in learning and growing in awareness. Careful RISKS readers must by now realize that I am probably the last person in the world who would say that something is really secure — I know that NOTHING is, including the interposition (or imposition?) of RISKS moderation. I simply must rely on your sensitivity not to mount attacks. We will soon have to switch to a UNIX system on a Sun workstation as the RISKS source, and at that point I would otherwise have to abandon all hope of moderation. PGN
(From the University of Iowa "fyi", 12 June 1987, p.2, in its entirety. Contributed by Ray Ford, whose interspersals are in square brackets.) Telephone tidbits [The Passive Aspect:] No answer University telephone users should be advised that when a University telephone has been programmed for call forward busy/no answer, the caller will hear three rings before the unanswered phone switches to its forwarded number. If that number is busy, however, the caller will not get a busy signal but will continue to hear the ringing signal. This is a problem with the software for the system, according to the office of telecommunications, for which there is no apparent solution. [The Aggressive Aspect:] Nothing in common The full-feature electronic telephones called D-Terms now in use on the University system are not compatible with Northwestern Bell or any other telephone system. Serious mishap, including explosion and fire, can occur if these telephones are connected to the wrong system.
Here is an interesting example of how a malicious host could cause considerable interruption to the ARPANET: Subject: Bogus ROOT domain server on ARPAnet [PGN Excerpting Service] Date: Mon, 08 Jun 87 22:40:46 -0500 From: Paul Richards <email@example.com> Tonight, we had what I'd call a major failure on the ARPA domain name system. A system at NORTHWESTERN.ARPA, [10.4.0.94], started advertising itself as a root domain name server, with the consequences that we stopped being able to locate any domain names at all.... Paul Richards University of Illinois at Urbaba-Champaign; Computer Science firstname.lastname@example.org, +217 333-3536
Last week the local utility company was training the Customer Support Reps (CSR) on the new procedures for emergency outages, such as during a storm. There were several people from different areas in the company, all at the main site. One of the screens on the computer terminal used for handling the emergency problems calls for the name of a printer to print the report. One of the people involved could only remember the name of the printer in the main operations for the company. Needless to say, there were several hurried phones calls after a utility company crew and police arrived at the "scene of the downed power lines" to find no problem existing. Fortunately, the name of the CSR is on report, so they were able to track down the person that way, and find out the false alarm. A little while later the operations room called back and asked if they had sent out a gas crew an hour before.
We experienced serious file system losses on many of the VAX UNIX systems this weekend beginning early in the morning on Saturday 6/20. At that time, a new system file which controls the disk purge operation was distributed and failed on all of the VAX systems which received it. On all but three machines this operation was aborted after removing a substantial number of its system files but before any private files were affected. These machines were returned to service upon restoration of their system files during the weekend. The following machines: SPEECH2.CS.CMU.EDU SAM.CS.CMU.EDU ME.RI.CMU.EDU each also lost a large part of one of their private file partitions. These file partitions are in the process of being restored from tape backups and the machines should be back in at least limited service by 1400 Monday, 6/22. Normally, the particular disk purge operation in question would have recursively removed all files in /usr/preserve that were more than a week old. However, on Saturday morning the mode of failure resulted in the attempted recursive removal beginning at / of all files which were more than a week old on each affected system. Machines with (to our knowledge) only system files removed were: PH1.SPEECH.CS.CMU.EDU FAS.RI.CMU.EDU GNOME.CS.CMU.EDU G.CS.CMU.EDU THEORY.CS.CMU.EDU UNH.CS.CMU.EDU ROVER.RI.CMU.EDU ISL1.RI.CMU.EDU IUS1.CS.CMU.EDU IUS2.CS.CMU.EDU SPEECH1.CS.CMU.EDU CIVE.RI.CMU.EDU Finally, a number of the VAX workstations were also affected. Problems have been corrected and all system files restored on: LAB.AGORA EDJ.ARCHONS EMC.CS EP.FAC MRT.MACH PIE5.MACH A.NL AMADEUS.PRODIGY DRAKON.RESDOC F.SPEECH G.SPEECH Y.SPEECH SPEECH3 NDIFF.VLSI D.SPEECH Some workstations where a problem is suspected were inaccessible and have not yet been checked and/or corrected. We will attempt to track down and if necessary correct problems with these systems on Monday. You may also contact the Operator at x2607 to report a problem if your machine appears to be in this category, So far as we know, no private files on any workstation examined so far were removed and over all only VAX mainframe and workstation systems were affected. At this point, while we know what went wrong and where, we still do not completely know why. We do apologize for any inconvenience this failure has caused.
Please report problems with the web pages to the maintainer