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…
Two rats crawled through an underground cable conduit into a cabinet of power switching gear adjacent to the Stanford University cogeneration plant, and caused an explosion that cut off power to the Stanford area beginning around 7:30pm on Thursday evening, 10 Oct 1996, and continuing until 3:30pm Friday afternoon. The BBN Planet hub (Internet Point of Presence, or PoP) at the Stanford University Data Center remained in operation for a few hours on standby battery power, but then gave out around 9pm Thursday; it came back up around 4:30pm, an hour after Stanford restored power. To name just a few, Bay-Area BARNet users at Stanford, U.C. Berkeley, Apple, Sun, Hewlett-Packard, Lawrence Livermore (partially), and SRI were cut off from the Internet. The *Los Angeles Times* and *San Francisco Chronicle* on-line sites were also off the air. Because I had no Internet access yesterday, I held up RISKS-18.52 — thus enabling me to include this item adding to our RISKS archives collection of rodent-induced outages. (Long-time readers recall that SRI alone has contributed four fresh-fried squirrels resulting in power outages.) [Sources: On-line messages and a front-page *San Francisco Chronicle*, 12 Oct 1996 item] Evidently, the horse is out of the BARNet, and the rats found the weak lynx. They sure put a ro-dent in the day for many BayAreans. Perhaps your mouse will click on a tale of its own. At any rate, this is just one more saga in the weak-link-in-the-infrastructure department. But I'm surprised that power-system technology has not found a way to develop rodent-tolerant circuits. [With SysAdmins and others pacing the halls at SRI waiting for whatever, Doug Moran remarked that keeping around a few fresh-frozen electrofried rodents is allegedly standard practice for purveyors of power; it is then very easy to have a fallback alibi when no other cause can be found.]
Punch-card ballots have been responsible for the uncertainty about the result of the Democratic Primary for the 10th Congressional District of Massachusetts. The election was held on 17 Sep 1996. The official count was not released until two days later. Philip Johnston was said to have defeated William Delahunt by 266 votes out of 49,371 ballots cast. Delahunt called for a recount, citing some 1000 punch-card ballots that were counted as blanks by the mechanical vote counter. On 2 Oct, the results of the recount were announced that showed Johnston the winner by 175 ballots. During the recount, the questioned ballots were examined by a human election official. The legal standard requires that the intent of the voter should govern the vote count. Thus if a ballot is not punched through, but is indented, then a vote should be counted. Delahunt took the dispute to state court. A state court judge examined 956 ballots in chambers and ruled that only about 50 were actually blank. On 4 Oct, the judge declared Delahunt the winner by 108 votes. On 8 Oct, the Massachusetts Supreme Court upheld the decision, giving Delahunt less than a month to gear up for the general election. It will be interesting to see what changes will be made for the general election. Punch-card ballots are used by 35 municipalities in Massachusetts (including mine). Hopefully there will be more education of voters to be sure that they completely punch out the perforation when they vote. Dave Tarabar SystemSoft Corp. 2 Vision Drive Natick, MA 01760 508 647-2952 dtarabar@systemsoft.com [This separates the "cent huit"[*] from the chaff (I'm punchy today)! [* I seldom explain my obscurer puns, but this one is 108 au francais.] PGN]
Are you being flooded with spams and scams the way I have been? (With address variations on both my own account and RISKS, I often get at least FOUR copies of a given spam.) The National Consumer League has issued a list of the top five types of Internet scams, based on complaints reported to Internet Fraud Watch. On top are (1) pyramid scams, such as Fortuna Alliance L.L.C. conning folks into paying $250 to $1750 by promising them $5000 per month when others enrolled. Next in line are (2) bogus Internet-related services, (3) misleading equipment sellers, (4) fraudulent business opportunities, and (5) work-at-home offers. The Internet Fraud Watch can be reached in the U.S. at 1-800-876-7060 <nfic@internetMCI.com> <http://www.fraud.org>. [Source: *San Francisco Chronicle*, 10 Oct 1996, B3.] Avoid a pyramid-life crisis. Don't be a sucker. Caveat emptor.
The smartcard security weakness [to interference phenomena] reported by Bellcore [Boneh/DeMillo/Lipton, noted in RISKS-18.50] is well-known in the TV-hacking community; power and clock glitches can be used to read out the memory contents of a number of smartcards. The typical modus operandi is to attack a loop in the card's software that reads out a series of memory addresses to the serial port. If a glitch can be found that causes the loop-variable decrement instruction to be wrongly decoded, then the entire contents of memory may be output. Ross [Stay tuned for a paper by Ross and Markus Kuhn of Purdue's COAST Lab that they will present at the Usenix Electronic Commerce conference in November. Note that the A-K techniques for analyzing the attack results are completely different from those of B-D-L, but the triggering events can be similar. PGN]
A new report by RTCA Inc., a nonprofit group that advises the airline industry, recommends tougher restrictions on the use of portable electronic devices during "all critical phases of flight." Some experts are even calling for a complete ban on all devices during flight. Currently, the Federal Aviation Administration leaves that decision up to individual airlines. In addition, the report recommends a total ban on all devices that transmit radio waves, such as a pager that automatically acknowledges receipt of a message by sending one back, or a laptop equipped with a wireless modem. Studies have shown that some of the strongest electromagnetic fields come from laptop computers, as the shielding that protects against unintended radio emissions tends to deteriorate over time. A laptop with a 90-Mhz microprocessor can leak radiation at that frequency as well as at higher, so-called harmonic frequencies, interfering with a plane's navigation and communications capabilities. (*Business Week*, 14 Oct 1996, p90)
BKPRUISC.RVW 960619 "Practical UNIX and Internet Security", Simson Garfinkel/Gene Spafford, 1996, 1-56592-148-8, U$39.95/C$56.95 %A Simson Garfinkel simsong@next.cambridge.ma.us simsong@gnu.ai.mit.edu %A Gene Spafford spaf@cs.purdue.edu %C 103 Morris Street, Suite A, Sebastopol, CA 95472 %D 1996 %G 1-56592-148-8 %I O'Reilly & Associates, Inc. %O U$39.95/C$56.95 800-998-9938 707-829-0515 fax: 707-829-0104 nuts@ora.com %P 1004 %T "Practical UNIX and Internet Security" The title is certainly apt. This book is definitely practical, and if your job involves system security, at whatever level, this book belongs on your desk. The expansion of the title is no mere attempt to gain market share: this edition is twice the size of the old one. The book is well planned and comprehensive. While the emphasis and examples are from the UNIX operating system and Internet protocols, background information is given on related (and important) topics such as modems and physical security. The writing and examples are clear and understandable, and should present no problems to the intelligent novice, but the additional material ensures that there is value here even for the UNIX guru. The six "parts" of the work (plus a set of appendices) present logical divisions of the topic. "Computer Security Basics" begins with an introductory chapter defining computer security, an operating system and UNIX. It continues with a discussion of policy and guideline considerations. Part two deals with the responsibility of the user. The chapters deal with the defence of accounts and the protection of data through users and passwords; user accounts, "groups" and the "superuser"; and details of the UNIX file system. Part three looks at the system side of security, with attention to backups, integrity, auditing, malicious software, and physical and personnel security. Part four covers communications aspects. This is highly important considering the strengths of UNIX in communications, the use of UNIX machines as bridges between other proprietary systems, and the participation of UNIX systems in the Internet. Chapters are devoted to modems, UUCP, TCP/IP, and Kerberos. Part five could be seen as an extension, dealing with advanced network security topics such as firewalls. The sixth section begins to move away from strictly technical aspects, and starts to deal with your response to "security incidents". This may seem, to some, either irrelevant or defeatist. However, it points out an important attitude to have with respect to security: assume that, at some point, you are going to fail--and be prepared. The chapters here are no less practical than the foregoing, detailing the discovery of break-ins, denial of service attacks, and the (U.S.) legal aspects of security. (I appreciate the authors' forthrightness at this point: the chapter is entitled "Computer Security and U.S. Law", and doesn't assume one legal system fits all.) A updating and expansion of a comprehensive and dependable classic in the security field copyright Robert M. Slade, 1993, 1996 BKPRUISC.RVW 960619 Vancouver ROBERTS@decus.ca | "Do you get guns with your Institute for rslade@vanisl.decus.ca | gun magazines? No. Research into rslade@vcn.bc.ca | Do you get viruses with your User Rob_Slade@mindlink.bc.ca| virus magazines? Yes." Security Canada V7K 2G6 | - Kevin Marcus
Most folks know that on a Novell network the user is prompted to change their password every so often for security purposes. CC:Mail on the other hand is a password eternal system unless of course the user is not so irresponsible to never change it on their own volition. The Novell/CC:Mail double password system can be a fairly secure way to insure your mail account privacy. A trick to access the cc:mail accounts of all the local network users, bypassing the Novell login password follows. Login as you normally would using your own account. Go to the N: directory prompt and edit the hidden file "cc-mail.bat" to delete your user name. Save it and logout. Now login again and go to the n: prompt. This time when you type "cc-mail" you are presented with a universal login screen. Type in the users account name that you want to read. You are then asked for a password which in this case is usually a very easy guess. The usual last name, wife, dog, kids, job title, nickname, works in the majority of cases. The sense of security that the initial Novell login password gives is enough to cause most people to pick really lame cc:mail passwords. What is REALLY funny is that the easiest accounts to hack at our company were the managers and supervisors accounts.
I recently downloaded a Macintosh shareware game from a reasonably trustworthy Web site. After playing it for a while, I decided it was worthwhile to pay the shareware fee. This particular software author (all names omitted to avoid unfairly painting anyone as a bad guy) included a small utility program that allows the user to fill out an on-screen form and print up an invoice for registration. Imagine my surprise when, upon launching this registration utility, I found my email address already listed in the appropriate field! , Many Mac Internet applications used with dial-up accounts either can (or in some cases, must) use a freeware control panel called ConfigPPP. I imagine that this is where the registration utility got my email address. ConfigPPP stores information about servers, user names and, if the user so chooses, account passwords in a central location. These can be automatically polled by savvy Internet applications, thus making setup of each application simpler. Since the relevant computer is my home machine and used only by me, I had stored my PPP dollop account password in order to save a little time each time I log on. When I printed up the shareware registration document, there were numerous lines of bar code printed at the bottom. These bar codes had what they ostensibly meant printed out in plain text beneath each line; however, there was no way I could confirm this was the information that the codes actually contained. For all I knew, they could easily contain my password. While I doubt very much that the shareware author in this case has done such a thing, it sure got me thinking about other potential security breaches. For instance, I imagine that it would be possible for a JAVA applet to poll ConfigPPP, pull out stored user names and passwords and send them off somewhere. I have since deleted my password from ConfigPPP. Other Mac users may want to reconsider storing passwords on their "secure" computers as well. --Carl Maniscalco, San Diego, CA--
This one is gleaned from reading news.admin.net-abuse.misc over the last week. The Microsoft Network has a user with username "abuse" who now has a full mailbox. It's full of complaints by Internet users at large about junk mail from other users at msn.com. Apart from the denial-of-service consequences for this user, it also means MSN's administrators are not getting abuse complaints (unless the poor user is dutifully forwarding them all). Bottom line: an unfortunate interaction of a newly-established de-facto standard (abuse@domain.com for compaints about domain.com users) with an unlikely (although explainable) choice of username. Nick Rothwell, CASSIEL http://www.cassiel.com
Fire Island is a summer resort on a barrier beach off the south
shore of Long Island. During the summer the various communities on the
island have seasonal post offices that receive their mail from the mainland
post office in Bay Shore (or Bayshore .. but that is another story), NY.
The seasonal post offices do not have individual ZIP codes or ZIP+4
extensions assigned to them. They are all assigned the same 11706 ZIP code
of the Bay Shore post office. That office sorts the mail addressed to the
various Fire Island communities and sends it on to the appropriate places.
Unfortuantely, when one tries to order something for delivery to a
specific community on Fire Island, the "clever" software at the mail order
vendor notices that the community specified is not the same as that for the
ZIP code (Bay Shore) and helpfully changes it. Once the package arrives in
Bay Shore, there is no way to determine to which of the several Fire Island
communities it should be delivered. Even when I specify that my community
must be manually entered and checked, it appears that the software either
cannot be overridden or, if manually overridden once, wins in the second
round.
I have taken to entering the name of my Fire Island community as the
second line of my address after my street address much as one would an
apartment number. This redundancy usually works but is at best a clumsy
solution to the problem. And, of course, it is of no use whatever to
seasonal renters who merely specify their name, address, community and ZIP
code — and are not in the phone book.
We just had a special form of "return to sender". In order to obtain some of the benefits alloted to us according to Dutch law, we had to fill in some forms, put the forms in a pre-printed envelope, enter our address at the backside and put it in a mailbox. Much to our surprise the letter came back a few days later without any notice as to why it came back. Some study reveiled the reason. The Dutch PTT prints in orange the "zip"-code as a bar-code on an envelope, in this case the code was printed on the backside, and apparently encoded our "zip"-code, so the person who did the "zip"-coding apparently had reversed the envelope after cancelling the stamp. Nobody in the remaining chain until delivery had seen what was happening. This immediately created a new problem: how to get those forms to the institution where they were meant to go to on time? Time was short, and they only accept forms with the pre-printed envelopes and they had only a postbox address. Putting the envelope in the mailbox again might have many different results, return to sender again, delivered with postage due (the stamps were already canceled, and the institution does not accept letters that are not properly stamped), or whatever. Well, the letter was handed in person at the post office, they heavily crossed out the orange printed barcode, notices were put on the envelope saying "this is the sender" and "this is the addressee". And no, we have not yet received it back. We hope it was on time. dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131 home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Back in the days when I was giving dBASE seminars, I used the "stripped leading zero" as a reason to make fields for U.S. ZIP codes character type rather than numeric. At one such seminar in Boston (where 02215 is a common ZIP code), a participant noted that they'd sent their mailing list to a Texas company for processing and it had come back with four digit ZIP codes. Said participant now understood the problem better. Apparently some branches of the U.K. postal service don't. tony.lima@toadhall.com (Tony Lima)
Steve Belle pointed out to me that the B757 was introduced in January 1983, not 1993. Thanks to Steve for catching the inadvertent typo. Yes, the B757 flew for nearly 13 years with its unblemished accident record. Peter Ladkin [I fixed the typo in the FTP.SRI.COM archive copy. PGN]
Preliminary Call For Papers [Edited for RISKS]
10th IEEE Computer Security Foundations Workshop
June 10-12, 1997
Rockport, Massachusetts, USA
Sponsored by the IEEE Computer Society
This workshop series brings together researchers in computer science to
examine foundational issues in computer security. We are interested both in
papers that describe new results in the theories of computer security and in
papers and panels that explore open questions and raise fundamental concerns
about existing theories.
Possible topics include, but are not limited to:
access control authentication data and system integrity
database security network security distributed systems security
security protocols security models formal methods for security
as well as foundational issues relating to other critical system properties
and in emerging areas such as mobile computing and executable content.
Submission deadline: 7 Feb 1997
For further information contact:
General Chair Program Chair Publications Chair
Jonathan Millen Simon Foley Joshua Guttman
The MITRE Corporation Dept of Computer Science The MITRE Corporation
Burlington Road, University College 202 Burlington Road
Bedford, MA 01730-1420, USA Cork, Ireland Bedford, MA 01730-1420, USA
+1 617-271-3580 +353 21 902929 +1 617-271-2654
jkm@mitre.org s.foley@cs.ucc.ie guttman@mitre.org
More online information at <URL:http://www.jcompsec.mews.org/csfw.html>.
Please report problems with the web pages to the maintainer