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: email@example.com 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: firstname.lastname@example.org 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 email@example.com
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 firstname.lastname@example.org. 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 email@example.com.
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 "firstname.lastname@example.org"; you will receive a response from an automated listserv system. To submit contributions, send to "email@example.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 firstname.lastname@example.org and administrative requests to email@example.com. 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 (126.96.36.199) 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 maintainerTop