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…
(The emu was late?) Tons of produce rotted. *The New York Times* 8 Jul 1998 has a picture (but no story) of many baggage containers that could not be sent from the newly opened Hong Kong airport, which had to be trucked over to the old Kai Tak airport. According to an item contributed by Daniel Graifer, the problem was attributed to a "complete breakdown" of the inbound cargo-handling system, including the loss of all cargo records. There were also lots of passenger delays and automated baggage-handling delays. Of course, everything reportedly had worked perfectly in the earlier tests. PGN
At about 13:00 on 11 Jul 1998, one of the busiest days in the year for Schiphol, the Amsterdam Airport, a computer malfunction stopped just about all air operations. According to the Dutch newspapers, some malfunction in the Triple A (AAA) system in air-traffic control blanked all screens, forcing the airport to put all traffic 'on hold'. It took about 30 minutes to get the system back up, and the rest of the day to clear the resulting mess. According to a spokesperson, "You can't use full capacity at once, you have to build that up." The Triple A system has been in use since 1 Jun 1998. Some more interesting quote that appeared in the newspaper: "Stories about ripped-apart cables are nonsense. The defect has been fixed, and we're not afraid it will happen again." [At least two risks in this quote: what do you tell your customers, and what do you mean, you're not afraid it will happen again?]
After 130 reported injuries due to gratuitous deployment of automobile airbags, General Motors and is recalling almost one million cars (1996 and 1997 Chevy Cavaliers and Pontiac Sunfires, and 1995 Cadillac DeVilles, Concours, Sevilles, and Eldorados). The Cavaliers and Sunfires have a sensor calibration problem that enables the air bags to inflate even under normal conditions on paved roads (perhaps an object bouncing up against the underside); the fix involves a little software reprogramming. The Cadillac air bags can deploy when there is moisture on the floor under the driver's seat, where the computer is located. A fix might involve waterproofing the computer box. [Source: AP item, 14 July 1998, PGN Abstracting] [Cadillac year typo fixed in archive copy. PGN]
In response to a widespread Japanese annoyance with other folks' mobile phones, Japanese entrepreneurs are marketing mobile jamming devices that can be used to silence those other folks. Because "regulators are concerned that such equipment could be misused", there are proposals to limit the use of the jamming devices to areas in which the phones could cause significant disturbances — such as movies, restaurants, and offices. (There are now 30 million mobile phones in Japan, one for every three people.) [Source: an article by Jonathan Watts in *The Guardian*, Scripps Howard News Service, 31 Jul 1998; PGN Stark Abstracting. Perhaps the jammers can deploy air bags?]
A Norwegian weather research rocket was mistaken for an American Trident ballistic missile in 1995. This was due to "the poor state of the [Russian] early warning systems." After the missile was spotted, a ten-minute countdown began toward a retaliatory strike on the US. The Strategic Rocket Forces were commanded to get ready for the next order, which would have been the launch order. [http://www.the-times.co.uk/news/pages/tim/98/07/13/timfgnrus01001.html?1124027 jpw very stark abstracting] John Wilson — jowilson@mtu.edu http://www.ed.mtu.edu/~jowilson/
Subsequent to the 19 May 1998 failure of the PanAmSat Galaxy IV HS601 Hughes satellite (RISKS-19.75-78,81,84), Hughes Electronics Corp. is also investigating two further malfunctions of HS601 satellites: * On 13 June 1998, the primary control processor of Galaxy VII failed, causing service problems for several hours for several cable-television networks. * On 4 July 1998, a spacecraft control processor failed aboard a satellite used to beam broadcasts to 3.7 million U.S. subscribers of DirecTV, the 185-channel direct-broadcast satellite TV service also owned by Hughes. In both cases, they were able to switch to a backup processor. [Sources: Reuters and Wall Street Journal, 9 Jul 1998, courtesy of Joan Brewer; PGN Abstracting]
Proposal to Make Fake IDs a Federal Offense By Declan McCullagh (declan@well.com) TIME.com / The Netly News, July 10, 1998 http://cgi.pathfinder.com/netly/article/0,2334,13979,00.html Remember when your underage friend ginned up that fake driver's license to go bar-hopping? Soon it may be a federal crime, punishable by serious fines and up to 15 years in the slammer. The Senate Judiciary Committee yesterday unanimously approved the "Identity Theft and Assumption Deterrence Act," a clunkily named bill that bans obtaining, possessing or using ID "other than that issued lawfully for the use of the possessor." [Remainder snipped.]
Cisco Backs Backdoor for Internet Wiretaps By Declan McCullagh (declan@well.com) [TIME.com / The Netly News 14 Jul 1998] http://cgi.pathfinder.com/netly/article/0,2334,14025,00.html Yesterday Cisco Systems announced a new plan to include "private doorbells" in its routers. The company says it's a great way to protect everyone's personal information on-line. So why are privacy groups crying foul? The approach made public yesterday by 13 of the largest technology firms will lead to an Internet that's easily wiretappable — it's the on-line equivalent of the reviled Digital Telephony (CALEA) law planned for the phone system. [...remainder snipped...]
In my ongoing role of being the naive* contrarian .... I'm concerned about all the Y2K discussion that focuses on prevention and little, if any, discussions of contingency plans. This represents a basic misunderstanding of how to deal effectively technology. I use the term "ballistic automation" for the clockwork-like model of automation in which one sets up all the rules and the system just runs without ongoing intervention and tweaking. In any system, there will be surprises and failures. While prevention is great, it is never complete. Instead one must prepare for failures. We must assume that there will be pervasive Y2K failures. The question is how do we survive and recover from them. Such planning has a higher value than Y2K prevention in that they basis for resilience that can deal with failures in general and, as a side benefit, provides better security since security breaches are simply failures. And Y2K is only one of many problems. There are many limited-size fields including other clocks (like the Unix one due to expire in 2037?) Systems do not deal with events that are unanticipated and have difficulty with those anticipated but not experienced. One simple example the response zip code changes. Read http://www.boston.com/dailyglobe/globehtml/193/ Post_office_delivers_new_codes.htm for more on the zip code changes in the Boston area. It took years for phone systems to learn to deal with area code changes and generalized area codes. But no one has heard of a zip code change. When I provide my new zip code on e-forms, it gets rejected by systems that do checking. Even mail from the Post Office itself uses the old zip code. Not only is the zip code changing but it will be recycled within a year or so! Hopefully, unlike the phone network, I'll still be able to get mail in the future since the Post Office does have some resilience in that it tries to handle failures with manual intervention (for now). But the more general principles of systems design need to percolate from what we've learned in designing systems into more the more general awareness of design issues. The zip code system, for example, was designed without leaving extra zip codes for future growth! While on the topic of the Post Office, there was another article <http://www.globe.com/dailyglobe/globehtml/193/ Errant_mail_delivery_brings_bagful_.htm> about the consequences of unreliable delivery. The concept of end to end vs link level reliability is something we've learned in the design of computer systems <http://www.reed.com/Papers/EndtoEnd.html>. Again, this experience needs to feed back into low tech systems. There are indeed risks of technology. But there are also risks of nontechnology. We must understand the risks but shouldn't be naive to assume that we can choose a risk-free path. And we must learn that we only anticipate some changes and need to "shake out" systems periodically. Just like we've learned that value of forest fires, Y2K might help in clearing out the underbrush. * I'm not really that naive, but a nonnaive discussion that goes into all the issues would be too long and boring for this forum.
The Reuter's article, portions of which Mr. Davidson posted, is an inaccurate characterization of the work and the outcome of the Technical Advisory Committee to Develop a Federal Information Processing Standard for the Federal Key Management Infrastructure (TACDFIPSFKMI). The committee did not set about to "design a federal computer security system that includes "back doors.'" Rather, the committee worked to develop a FIPS that would be used to evaluate the security functionality, assurance, and interoperability of key recovery systems. The document is quite policy neutral, addressing only technical aspects of evaluating such systems, not necessarily endorsing their use. It also is technology neutral, not favoring any particular key recovery technique. It is analogous to FIPS 140-1, the security evaluation criteria for cryptographic modules. To say that the committee "failed" is an oversimplification. We did not complete the FIPS and we advised the secretary that the document, in it's current form, was not ready for public review, the next phase in the FIPS development process. Since we stopped work in the middle of the document review process, we knew there were internal inconsistencies that needed to be resolved. However, our experience with the review process suggests that these problems can be resolved. In the letter, the committee noted that it had made significant progress in its efforts and that committee members were willing to continue work on the document. Many expressed a belief that the document could be successfully completed. Steve Kent, Chair, TACDFIPSFKMI
It is incorrect to refer to all mobile code using the term "applet". It is also incorrect to lump Java together with ActiveX — they have vastly different security potentials. Moreover, this announcement is confusing viruses with anything that travels. In fact, the Consortium appears to be quite ambitious, in that mobile code basically includes anything that causes something to happen at a remote site — the code does not actually have to travel to have the mobile effect. The following are all examples of "mobile code" under this definition: CD-ROM zip drive Lisp code Java applet Word document agent software browser plugin postscript file removable storage ActiveX components articles posted to newsgroups any number of scripting languages attached e-mail components (MIME) floppy disk (demo disks you receive in the post) someone over the phone asking you to run a program ... (the list goes on and on) It is great that the anti-virus vendors are committed to address all these problems. Some rudimentary questions will be, how many of these do not consider security, which has hopeless security, and which has the best security architecture so should be the least to worry about. Li Gong, Java Software Division, Sun Microsystems
I would think about it this way. If I were to put a box in my front yard with a sign that said free information, and in it I accidentally put my tax return, how could I blame someone for reading it. It is my fault for making the mistake. I feel the same way about web sites. If they serve it, I can read it, period. If they do not want me to read it, they should not serve it. I feel that by installing a web server the webmaster is responsible for the content which it serves. If I am able to get the server to give me information that was not intended to be served that it is not my fault. For example, some sites on the net serve image databases, such as stock photography. Often the images will be given sequential names, such as k014.jpg, k015.jpg, etc. Frequently the sites will have several examples on the web page from the image database. If I then make sequential requests to the web server for files which were not linked to from the page, such as k001.jpg, k002.jpg, etc., and the web server gives them to me then clearly the webmaster needs to rethink how the web site is organized. I don't think that it is my fault for requesting, then subsequently retrieving the images. I wrote a 55 line perl program which does just this. It makes requests to a webserver for a sequential list of filenames, and if it gets the expected response ( eg not "404 not found" ), then it saves the file. Am I hacking or am I optimizing my web surfing time through automation? I like to feel that I am saving time. Michael Hogsett
I've found that one of the most effective filters in my KILL file for reading newsgroups is one that requires all subject lines to have at least a single lower case character. Any message whose subject is in all caps is 90% likely to be spam, and 10% likely to be from someone who thinks is message is much more important then the rest of us do. Unfortunately, the one kink in this is reading comp.risks, which posts all of its subject lines in all caps. I hope this isn't telling us something. ;)
Thanks to Ben's inspired prodding, I have changed the Subject: line of this issue (and future issues as well) so that the success rate of Ben's filter might increase a little). I suggested to Ben that if spamsters read his RISKS posting, his filter might no longer be as effective, but Ben thought it was very unlikely that spammers actually might *read* anything in RISKS. PGN
BKMAXSEC.RVW 980501 "Maximum Security", Anonymous, 1997, 1-57521-268-4, U$49.99/C$70.95/UK#46.95 %A Anonymous %C 201 W. 103rd Street, Indianapolis, IN 46290 %D 1997 %E Mark Taber newtech_mgr@sams.mcp.com %G 1-57521-268-4 %I Macmillan Computer Publishing (MCP) %O U$49.99/C$70.95/UK#46.95 800-858-7674 http://www.mcp.com %P 885 p. + CD-ROM %T "Maximum Security" Rather loudly promoted on the net these days, the major selling point of this book is that it was written "by an experienced hacker." Supposedly one who spent some time as a guest of Uncle Sam for fiddling bank machines. (Some of what we are told about the author does not fit with the contents of the book, but then, as an old professional paranoid, I may be unduly suspicious.) Leaving aside questions of morality and definitions of the term "hacker," let us merely observe that these people are the gnostics. They are the devotees of the hidden, esoteric, and arcane knowledge. Such knowledge, of course, is cheapened and weakened by being revealed. Which may explain a certain reticence on a number of points in the book. The introduction makes this mindset clear: Anonymous assumes that if you will not work diligently at his direction you do not deserve to secure your system. One can almost feel his glee at the expectation that thousands of sysadmins around the world will be wracking their brains and flooding Usenet with discussions of the significance of his clues to the vital encrypted message he has hidden on the CD-ROM. This does, of course, presume that his direction, and the contents of the book, warrant the effort to try and guess his riddle. Part one might be characterized as a social background to security. Chapter one is essentially an extension of the introduction, continuing to try to convince the reader that the book is worthwhile. But it also states that the author wishes to raise the awareness of security in the general public. I rather doubt that this will be the book to do so: the average user will be put off by both the size and the subtitle's emphasis on Internet sites and networks, neither of which the average user will run. The (very verbose) sales pitch continues in chapter two with rather generic promises of the goodies offered to all manner of readers, and a list of chapters to come. (Of course, nudge, nudge, wink, wink, some unethical people might use this information for cracking, nudge, nudge, but none of *us* upstanding people would do that, right? wink, wink) Having been rather careless with the term "hacker" up to this point, chapter three belatedly attempts to distinguish between hackers and crackers. It doesn't succeed very well, being a pretty faint-hearted try. Chapter four lists a number of security penetrations in an bid to prove that anyone can be attacked. Part two moves into more of a technical background to security. Chapter five looks at the complexity of current network systems and other factors militating against safety. A brief introduction to the TCP/IP protocol suite is given in chapter six. Chapter seven gives some random material on the Internet, programming, and UNIX. A variety of Internet problems are briefly mentioned in chapter eight. Part three looks at a number of the more common security penetration tools. Chapters nine through fourteen discuss scanners, password crackers, trojans, password sniffers, identity tools, and malicious software respectively. Advice on how to deal with these problems varies in depth, but generally is not extensive. As only one example, the author does recommend that Web browsers be set to alert the user when a cookie is being set, but fails to give the slightest indication of how this is to be accomplished. The section on viruses is the book in miniature: not necessarily *all* wrong, but overly verbose, lacking in insight, and missing those points that would really be helpful to the computer user or manager. Part four reviews a number of operating system platforms. Chapter fifteen presents the concept of vulnerabilities (termed as "holes"). In spite of the fact that MS-DOS, Windows 3.x, and Windows 95 have no appreciable security, chapter sixteen lists a large number of security penetration programs for them. (It also has a rather odd reference demonstrating that the author does not actually understand how the CMOS password functions work.) Chapter seventeen does contain a collection of the more common suggestions for securing a UNIX box. Tools for breaking Novell NetWare are displayed in chapter eighteen. Cracking tools for VMS are listed in chapter nineteen. Chapter twenty has both cracking and some protection software for the Mac. The installation of the Plan 9 operating system is discussed in chapter twenty one. Part five gives some advice on what to go after when you crack a system. Chapter twenty two suggests that root access is a suitable target. Chapter twenty three points out that it is easier to crack a system with partial access or inside information. Consultants seem to be the topic of chapter twenty four. Part six gives information on how to penetrate a system from outside. Chapter twenty five looks at gathering information about the target. Rather obvious statements about levels of attack are made in chapter twenty six. Chapter twenty seven is a simple review of packet filtering firewalls. IP spoofing is discussed in chapter twenty eight. Telnet attacks cover a wide range, so it is surprising that chapter twenty nine is so short. Chapter thirty looks at loopholes in Web page programming. Part seven, chapter thirty one, reviews legal aspects, and for once even mentions laws outside the US. Basically, there is a whole lot of partial information here. It is a handy list of security related Web sites, but made less useful by the bulked out verbiage between the listings. In addition, it is rather plain to see that there is far greater emphasis on cracking than on protection. (After all, how vital is it to securing your system to know the algorithm for generating fake Microsoft software registration keys?) All you teenage-mutant-cyberscofflaw-wannabes might be disappointed, though: the information is almost never complete. copyright Robert M. Slade, 1998 BKMAXSEC.RVW 980501
BKWNTSCG.RVW 980513 "Windows NT Security Guide", Stephen A. Sutton, 1997, 0-201-41969-6, U$29.95/C$41.00 %A Stephen A. Sutton sutton@trustedsystems.com %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 1997 %G 0-201-41969-6 %I Addison-Wesley Publishing Co. %O U$29.95/C$41.00 416-447-5101 fax: 416-443-0948 bkexpress@aw.com %P 373 p. %T "Windows NT Security Guide" Part one deals with issues of interest to users. Chapter one is a conceptual introduction to security and the NT system. The material is informal. This makes it easy to read, but also sacrifices completeness. Sutton's idiosyncratic structure is weak in certain areas; for example, reliability. The content is also lavish in its praise of Microsoft and NT, and seemingly unwilling to admit to any weak areas or flaws. Accounts, and the domain model, and reviewed in chapter two. (Illustrations are heavily used, and could be helpful were it not for the fact that so many have serious errors.) The working environment, in chapter three, holds a rather random assortment of features but concentrates on the NT security window, rather mystically referred to as the "Trusted Path." (Both this term and "Trusted Computer Base" are specific referents of the "Trusted Computer System Evaluation Criteria" of the US Department of Defense, better known as the "Orange Book". Neither term is used in the specific manner defined by the Orange Book.) The structure of the presentation seems to be intent on showing off, frequently querying the user before having provided the answer. (On the other hand, one formal exercise asks whether the user should enter a password into a specific request box on the screen, and immediately tells you that NT does not use that request box.) Chapter four goes into a lot of detail on ACLs (Access Control Lists) but, in common with all too many security books, does not present a completely clear picture of effective rights in the case of combinations of permissions. A number of situations where the same user name can be handled differently are looked at in chapter five. Part two involves administrative tasks. Chapter six covers the mechanics of domain administration quite well, but the actual planning is not dealt with in depth. Management of accounts is the topic of chapter seven. Auditing and logging is covered in fair detail in chapter eight. Although chapter nine is nominally about the Internet and intranets, most of the space is dedicated to general discussions of encryption. Details of algorithms are minimal, and a number of the topics covered have only tangential relevance to NT. Chapter ten is a grab bag of topics including the Registry, system policies, and printers. The "Trusted Computing Base," in chapter eleven, seems to refer to computer hardware and software assets, but the protection of these assets is not well explained. (One of the author's major fears seems to be viruses, but despite a great many mentions there is little realistic information about them in the book.) Chapter twelve closes off with a checklist summary of section titles from the book to this point. Part three is a single chapter, on assessment of NT security. Much of this chapter is dedicated to proving that NT does not need to conform to the "Orange Book" levels. The stated intent of the book is to provide security information both to users of Windows NT, and to network administrators. In reality, users would need "cookbook" style recommendations that could be put into practice immediately, and which are generally missing from the book. Administrators need a more complete and well rounded approach to the topic, particularly addressing vulnerabilities in NT itself (such as the built-in and well known standard accounts). For those with no background in security the book provides a little knowledge. However, note the proverbial danger of a little knowledge, particularly in cases where overconfidence can lead to disaster. copyright Robert M. Slade, 1998 BKWNTSCG.RVW 980513
Please report problems with the web pages to the maintainer