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 2.5-year-old boy and his dog wandered off from their home block in Blacktown, near Sydney, but apparently neither of them could figure out how to get home again. The dog wore a tag indicating that he had a microchip implanted by the Australian Animal Registry, which led to identification of the dog's owners, who — happily — were the boy's parents. [From a clipping from the Sydney Morning Herald, 14 Oct 1993, front page, sent to RISKS by Cameron McLaren in Watson's Bay, Australia. This item provides a nice technology-related success story. Little Arf Anony?]
A couple of weeks ago a SNET (Local telco) fiber optic cable was found to have been "melted" near where it crosses the Housatanic River. This degraded in-state long distance service and caused the 911 services in several towns, possibly to the New York border (the paper never said) to fail. My brother is a network maven at a local bank. He got some more information: The papers reported the cable was "melted". The cable was several feet under ground; evidence of a campfire was reported. Must have been one Hell of a campfire! The telco is certainly not telling all!
The report on the Primary protection System for the UK Sizewell B nuclear reactor, from the Nuclear Installations Inspectorate to the Advisory Council on the Safety of Nuclear Installations, is available for two pounds sterling from Computer Weekly, a trade weekly. The report is classified "confidential to members" but the newspaper is selling it "to promote well informed discussion". The report has provoked some controversy in the UK since it was leaked a few weeks ago, because it contains some surprises about the results of the verification activities. If you want to read a well-written, technical report on the design and verification of a large, real-world safety-critical software system, send your two pounds to Computer Weekly, Sizewell Report, Quadrant House, The Quadrant, Sutton, Surrey SM2 5AS. Then tell RISKS what you think. Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. Tel: +44-225-444700. Email: mct@praxis.co.uk Fax: +44-225-465205
In RISKS-15.11, we saw reports (in NY Times, etc.) that Mr. Bruce Blair, a top US nuclear expert, alleged that the Russians have a Doomsday Device, a computerized system that could automatically launch nuclear strikes even when the Russian leadship is all wiped out. Not noted in RISKS (and also not noted in the San Francisco Chronicle report I saw) are the following two important points (I got these from The Manchester Guardian Weekly, Oct.17, 1993, p.6): (1) Blair wrote this in a book, "The Logic of Accidental Nuclear War". (2) He also pointed out that the US has things quite similar. For example, the Trident submarines commanders can launch a nuclear strike even when they have lost contact with the US and if they *believe* a nuclear conflict has started. Someone with access to the book could give us a more complete picture? Li GONG Email: gong@csl.sri.com Tel: 415-859-3232 Fax: 415-859-2844 SRI International, Computer Science Lab, Menlo Park, California 94025, USA
There has been concern expressed that when we all stop consuming the same mass
media, our shared sense of reality will unravel, with a RISK of bad
consequences for social cohesion in general.
That's one way of looking at it.
But consider also that if the technological revolution succeeds in remaking
the very nature of the media, from one-way mass transmissions to something
more like a community, however many "channels" it may be fragmented into, we
all stand to gain more than we lose.
I would like to cite a passage by Jean Baudrillard, critiquing the send-only
nature of the mass media. When you think of future media, don't think of home
banking and 500 channels of Home Shopping and Gomer Pyle USMC, don't even stop
to think of personalized morning newspapers, think of genuinely interactive
media where "viewers" (as we would now call them, for lack of a better term)
are aware of and can respond to each other — every channel an encounter.
"The mass media are anti-mediatory and intransitive. They fabricate
non-communication — this is what characterizes them, if one agrees to define
communication as an exchange, as a reciprocal space of speech and a response,
and thus of a *responsibility* (not a psychological or moral responsibility,
but a personal, mutual correlation in exchange). We must understand
communication as something other than the simple transmission-reception of a
message, whether or not the latter is considered reversible thru feedback.
Now, the totality of the existing architecture of the media founds itself on
the latter definition: they are always what prevents response, making all
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
processes of exchange impossible (except in the various forms of response
*simulation*, themselves integrated in the transmission process, thus leaving
the unilateral nature of the communication intact). This is the real
abstraction of the media. [from "Towards a Political Economy of the Sign"]
Fred Baube (tm), GU/MSFS/88 baube@optiplan.fi
RISKS recently included a discussion of the increasing use by car rental
agencies of computer queries of motor vehicle department databases in order
to deny car rentals to bad drivers. At least one writer suggested that a law
to make any collectors of such data responsible for errors would help keep the
error rate under control. It's easy to see this as (a) yet another item on
the list of databases that will go wrong because databases *always* go wrong;
(b) yet another risk and inconvenience that will be imposed on everyone by the
evil users of databases; (c) yet another thing that needs regulation. But
it's not that simple. Decisions about databases, from their creation to their
maintenance and use, are not purely technical decisions. They are made in a
social and legal context, and are affected by a complex set of circumstances.
A "quick legal fix" is as unlikely to help as a "quick technical fix".
There's a background to the rental company decisions. Many states have passed
laws that make the owner of a vehicle responsible for any damage done with
that vehicle. This includes car rental companies. If a car rental company in
New York rents a car to Joe Dangerous, and Joe hits Sid Sorry badly injuring
him, not only can Sid sue Joe - likely a pointless exercise, as Joe has no
assets so is "judgement proof" - but he can also sue the rental company. It
makes no difference that the rental company knew nothing about Joe's past
driving record; they own the car, they can be held accountable.
In New York, about a year or so ago, after what they claimed were large
losses, several of the larger companies announced very large surcharges on
cars rented at airports to drivers who lived in certain zipcodes. Needless to
say, the zipcodes involved are populated largely by poorer, often minority,
residents.
Remember that in judging the risk associated with an action, one must also
consider the available alternatives. Screening based on actual driving
records, errors and all, is a HUGE improvement. It's quite true that the
relatively well-to-do, probably mainly white, readers of RISKS have much more
chance of being denied a rental car due to an error in the records in the new
system than they did under the older system, which in effect spread the errors
uniformly over a less vocal population - or at least a population we are
unlikely to hear much from on this list. Still, it seems like a much better
trade-off from a social policy point of view.
Finally, on the matter of using lawsuits to curb actions we don't like: This
whole mess is an illustration of the complexities. Actions have consequences,
often undesirable ones. It's almost impossible for someone under 25 to rent a
car in the US today: They are considered uninsurable at any acceptable rate by
the rental companies. The surcharges effectively locked out the poor.
Checking of driver's records theoretically locks out those who are really bad
drivers - but the criteria used are arbitrary. Two moving violations in the
last 3 years? Sorry, no car for you. If you make a business risky enough, it
will either vanish or simply become so expensive that it might as well have.
— Jerry
Recently, I asked for information on Usenet, but wanted to remain anonymous, so I used an anonymous remailer to post. Most people have seen anonymous postings, and some people have probably replied to them. What many people probably never think about is the following text at the end of every post (that you will see at the end of my post): > Due to the double-blind, any mail replies to this message will be anonymized, > and an anonymous id will be allocated automatically. You have been warned. This means that if Bill replies to my anonymous posting, it will go through the remailer and become anonymized. If Bill has sent an anonymous message before, I will receive mail from him with his (permanent) anonymous id. If he puts in his signature at the end of his mail (which I always do when replying to a stranger), he will be giving me his anonymous id with his "real" id. I can then save this information in a database and cross-reference it with any anonymous postings. In fact, I have been doing just that. I use the "Insidious Big Brother Database" (bbdb) from within emacs, and it automatically inserts email senders into my database, and marks all net-news headers from people in my database. I do this just because I'm curious, not malicious. My database is encrypted, so only I can read it. I could be evil, though. I could post flame-bait in newsgroups like alt.sexual.abuse.recovery, save all the information from people that flame me, and then post the cross-references to alt.rush.limbaugh. Or I could do worse. Be careful to whom you reply. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To find out more about the anon service, send mail to help@anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin@anon.penet.fi.
Periodically I will remind you of TWO useful digests related to privacy, both
of which are siphoning off some of the material that would otherwise appear in
RISKS, but which should be read by those of you vitally interested in privacy
problems. RISKS will continue to carry general discussions in which risks to
privacy are a concern.
* The PRIVACY Forum Digest (PFD) is run by Lauren Weinstein. He manages it as
a rather selectively moderated digest, somewhat akin to RISKS; it spans the
full range of both technological and non-technological privacy-related issues
(with an emphasis on the former). For information regarding the PRIVACY
Forum, please send the exact line:
information privacy
as the BODY of a message to "privacy-request@vortex.com"; you will receive
a response from an automated listserv system. To submit contributions,
send to "privacy@vortex.com".
* The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is
run by Dennis G. Rears. It is gatewayed to the USENET newsgroup
comp.society.privacy. It is a relatively open (i.e., less tightly moderated)
forum, and was established to provide a forum for discussion on the
effect of technology on privacy. All too often technology is way ahead of
the law and society as it presents us with new devices and applications.
Technology can enhance and detract from privacy. Submissions should go to
comp-privacy@pica.army.mil and administrative requests to
comp-privacy-request@pica.army.mil.
There is clearly much potential for overlap between the two digests, although
contributions tend not to appear in both places. If you are very short of time
and can scan only one, you might want to try the former. If you are interested
in ongoing detailed discussions, try the latter. Otherwise, it may well be
appropriate for you to read both, depending on the strength of your interests
and time available.
PGN
The CERT Advisory that follows my message is serious stuff. I tend not to run CERT postings in RISKS, for many of a variety of reasons (e.g., their already-wide distribution, or narrow focus, or sensitivity), but this one seemed particularly relevant to the bigger picture, which is that system and network security stinks in most systems, particularly those on the Internet. Numerous sites have been increasingly experiencing breakins. In addition to the problems described in the CERT Advisory, many systems have recently had passwords captured from outside intruders using promiscuous-mode Ethernet tapping. This has resulted in the compromise of both incoming and outgoing passwords used for FTPs and TELNETs, for example. Some of these passwords have even been posted for use by others. It is long past high time for system vendors and system administrators to get serious about system/network security. Perhaps the CERT message will serve as yet another reminder, although I have little confidence in things improving very rapidly. PGN]
CA-93:15 CERT Advisory
October 21, 1993
/usr/lib/sendmail, /bin/tar, and /dev/audio Vulnerabilities
The CERT Coordination Center has learned of several vulnerabilities
affecting Sun Microsystems, Inc. (Sun) operating systems. Three
separate vulnerabilities are described in this advisory. The first
and third vulnerabilities affect all versions of SunOS 4.1.x and all
versions of Solaris 2.x. The second affects all systems running any
version of Solaris 2.x (but does not affect SunOS 4.1.x systems).
Patches can be obtained from local Sun Answer Centers worldwide as
well as through anonymous FTP from the ftp.uu.net (192.48.96.9) system
in the /systems/sun/sun-dist directory. In Europe, these patches are
available from ftp.eu.net in the /sun/fixes directory.
Information concerning specific patches is outlined below. Please note
that Sun sometimes updates patch files. If you find that the checksum
is different, please contact Sun.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I. /usr/lib/sendmail Vulnerability
This vulnerability affects all versions of SunOS 4.1.x including
4.1.1, 4.1.2, 4.1.3, 4.1.3c, and all versions of Solaris 2.x
including Solaris 2.1 (SunOS 5.1) and Solaris 2.2 (SunOS 5.2).
Sun is preparing a version of this patch for Solaris 2.3 but no
patch ID is available at this time.
** This vulnerability is being actively exploited and we strongly
recommend that sites take immediate and corrective action. **
A. Description
A vulnerability exists in /usr/lib/sendmail such that remote
users may gain access to affected systems.
B. Impact
Unauthorized access to affected systems may occur.
C. Solution
1. Obtain and install the appropriate patch following the
instructions included with the patch.
System Patch ID Filename BSD Solaris
Checksum Checksum
------ -------- --------------- --------- -----------
SunOS 4.1.x 100377-07 100377-07.tar.Z 36122 586 11735 1171
Solaris 2.1 100840-03 100840-03.tar.Z 01153 194 39753 388
Solaris 2.2 101077-03 101077-03.tar.Z 49343 177 63311 353
The checksums shown above are from the BSD-based checksum
(on 4.1.x, /bin/sum; on Solaris, /usr/ucb/sum) and from the SVR4
version that Sun has released with Solaris (/usr/bin/sum).
II. Solaris 2.x /bin/tar Vulnerability
This vulnerability exists in all versions of Solaris 2.x including
Solaris 2.1 and Solaris 2.2. Information about patches for current
versions of Solaris is described below. Sun is preparing a patch
for the upcoming Solaris 2.3 release. The patch ID will be 101327-01,
and it will be available as soon as Solaris 2.3 is shipped.
This vulnerability does not exist in SunOS 4.1.x systems.
A. Description
A security vulnerability exists in /bin/tar such that tarfiles
created using this utility may incorporate portions of the
/etc/passwd file.
B. Impact
Usernames and other information from /etc/passwd and /etc/group
may be disclosed. However, since Solaris 2.x uses shadow passwords,
encrypted passwords should not appear in /etc/passwd and therefore
should not be disclosed by this vulnerability.
C. Solution
We recommend that all affected sites take the following steps
to secure their systems.
1. Obtain and install the appropriate patch following the
instructions included with the patch.
System Patch ID Filename BSD Solaris
Checksum Checksum
------ -------- --------------- --------- -----------
Solaris 2.1 100975-02 100975-02.tar.Z 37034 374 13460 747
Solaris 2.2 101301-01 101301-01.tar.Z 22089 390 4703 779
The checksums shown above are from the BSD-based checksum
(on 4.1.x, /bin/sum; on Solaris, /usr/ucb/sum) and from the SVR4
version that Sun has released with Solaris 2.x (/usr/bin/sum).
2. If your site is not using shadow passwords, we recommend
that all passwords be changed, especially those for
sensitive accounts such as root.
3. Depending upon the sensitivity of the information contained
in the /etc/passwd file, sites may wish to replace existing
tar files where this is possible. Restoring an existing
archive file, and then producing a new tarfile with the
patched tar, will result in a clean archive file.
III. /dev/audio Vulnerability
This vulnerability affects all Sun systems with microphones. This
includes all versions of SunOS 4.1.x including 4.1.1, 4.1.2, 4.1.3,
4.1.3c, and all versions of Solaris 2.x including Solaris 2.1
(SunOS 5.1) and Solaris 2.2 (SunOS 5.2). Sun is addressing this
problem in Solaris 2.3.
A. Description
/dev/audio is set to a default mode of 666. There is also no
indication to the user of the system that the microphone is on.
B. Impact
Any user with access to the system can eavesdrop on conversations
held in the vicinity of the microphone.
C. Solution
To prevent unauthorized listening with the microphone, the
permissions of the audio data device (/dev/audio) should allow
only the user logged in on the console of the machine to read
/dev/audio. To prevent unauthorized changes in playback and record
settings, the permissions on /dev/audioctl should be similarly
changed.
*** Any site seriously concerned about the security risks
associated with the microphone should either switch off the
microphone, or unplug the microphone to prevent unauthorized
listening. ***
1. Restricting access on 4.x systems
Use fbtab(5) to restrict the access to these devices. See the
man page for more information about this procedure.
2. Restricting access on Solaris 2.x systems
To restrict access to these devices to a specific users, the
permissions on the device files must be manually changed.
As root:
# chmod 600 /dev/audio
# chown
Please report problems with the web pages to the maintainer
x
Top