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 <richards%shangrila.cs.uiuc.edu@a.cs.uiuc.edu>
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
richards@b.cs.uiuc.edu, +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