[risks] Risks Digest 22.64

From: RISKS List Owner (riskoat_private)
Date: Tue Mar 18 2003 - 15:34:23 PST

  • Next message: RISKS List Owner: "[risks] Risks Digest 22.65"

    RISKS-LIST: Risks-Forum Digest  Tuesday 18 March 2003  Volume 22 : Issue 64
    
       FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
       ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
    
    ***** See last item for further information, disclaimers, caveats, etc. *****
    This issue is archived at
      http://catless.ncl.ac.uk/Risks/22.64.html
    and by anonymous ftp at ftp.sri.com, cd risks .
    
      Contents:
    Apparently uncommanded rudder movement injures cruise passengers 
      (Steve Peterson)
    Jeppesen GPS navigation database corruption (Mickey Coggins)
    California outage causes prescription mix-up (Richard Cook)
    Glitch let gamblers beat machines (M Taylor)
    Haywire ATM spits out extra cash (Fuzzy Gorilla)
    Beware the spelling checker (NewsScan)
    David J. Aronson" <dja2003at_private>
    Recent worms punish bad passwords
    Profile of a virus writer (NewsScan)
    Search engines making sensitive information easy to locate (Richard Moore)
    Benetton clothes to include tracking chip (Monty Solomon)
    CASPIAN calls for immediate worldwide boycott of Benetton (Monty Solomon)
    Federated network identity (Brian Seborg)
    Re: Computer crashes threaten hospital operations (Jonathan Kamens)
    Re: Monster electricity bill (Don Gingrich)
    Human protocol failure (Dawn Cohen)
    The Workshop on Rapid Malcode: WORM (Robert K. Cunningham)
    Abridged info on RISKS (comp.risks)
    
    -------------------------------------------------------------------------
    
    Date: Mon, 17 Mar 2003 11:52:03 -0600
    From: Steve Peterson <steveat_private>
    Subject: Apparently uncommanded rudder movement injures cruise passengers
    
    I received an e-mail from relatives who are on a Holland America cruise
    around the tip of South America.  Last Thursday night, while they were
    eating dinner in the dining room, there was a sudden lurch and the ship went
    into a hard right turn, listing over at an estimated angle of 20 degrees.
    Every chair in the dining room toppled and people, dishes and food slid
    everywhere.  At least two people were injured in the laundry when clothes
    dryers topped on top of them.  The grand piano on the stage was flipped
    over.
    
    After about 5 minutes, the ship stopped turning.  Shortly after that, the
    captain came on the PA system and announced that, when they turned off the
    autopilot to enter the port at Buenos Aires, the rudder swung to the right
    and could not be "unstuck."  Over two hours elapsed after the incident,
    before the crew performed a count of the passengers.
    
    ------------------------------
    
    Date: Fri, 14 Mar 2003 17:53:25 +0100
    From: Mickey Coggins <risks-spam-alertat_private>
    Subject: Jeppesen GPS navigation database corruption
    
    I just got this from the AOPA (Aircraft Owners and Pilots Association),
    a truly outstanding organization, BTW.
    
      Jeppesen reports airspace boundary problems
     
      About 350 airspace boundaries contained in Jeppesen NavData are incorrect,
      the FAA has warned. The error occurred at Jeppesen after a software
      upgrade when information was pulled from a database containing 20,000
      airspace boundaries worldwide for the March NavData update, which takes
      effect March 20. Only a dozen are in the United States, including Chicago;
      Louisville, Kentucky; Fayetteville, North Carolina; Santa Ana, California;
      Las Vegas; Honolulu; Des Moines; and Oklahoma City. The error could cause
      pilot alerts to be given by GPS units too early or too late. Pilots are
      advised to use multiple sources of information, such as carrying paper
      charts (Jeppesen paper charts are unaffected by the problem), and
      contacting controlling agencies by radio to avoid airspace
      violations. Jeppesen has provided a searchable database of locations with
      airspace boundary errors on its Web site (
      http://www.aopa.org/epilot/redir.cfm?adid=1875 ). To search, click on the
      binocular icon and enter an airport identifier.  Jeppesen spokesman Mike
      Pound said the errors will be corrected "for the next possible release."
      The next release is scheduled for April 17.
    
    The risks are pretty obvious.  Today if you fly your tiny aircraft into
    restricted airspace in the USA, you can get shot down by agents of "The
    Department of Homeland Security".
    
    Many (most) pilots use this navigation data with their GPS as their primary
    source of navigation information worldwide.
    
    Please don't get me started on the absurdity of many of these airspace
    restrictions in the first place...
    
    ------------------------------
    
    Date: Tue, 18 Mar 2003 09:58:16 -0600
    From: "Richard Cook" <ri-cookat_private>
    Subject: California outage causes prescription mix-up
    
    Thousands of patients could have received the wrong prescription drugs after
    a power outage at Kaiser Permanente's computer center in Southern California
    knocked the pharmacy's labeling system out of sync -- printing the wrong
    labels on filled prescriptions.  There were no reports yet of patients
    suffering from adverse reactions.  About 4,700 patients from Fresno to the
    Oregon border were affected, including those ordering prescriptions by
    telephone.  After the error was discovered on 14 Mar 2003, hospital
    officials attempted to contact the affected patients, although by 17 Mar,
    152 remained uncontacted -- including those for whom they had only PO-box
    addresses.  [Source: Associated Press, 18 Mar 2003, PGN-ed; Also noted by
    Danny Burstein]
    
    ------------------------------
    
    Date: Thu, 13 Mar 2003 12:50:34 +0000
    From: M Taylor <mctaylorat_private>
    Subject: Glitch let gamblers beat machines
    
    Some Nova Scotia video lottery terminal (VLT) players found a way to beat
    machines last year, forcing the Atlantic Lottery Corp. to replace computer
    chips in about one-third of their 3,538 VLTs in Nova Scotia and
    Newfoundland.  About 20 locations appeared to have had the glitch exploited.
    ALC doesn't know how much it lost, but noted the maximum payout for a single
    spin is $500.  The problem was discovered in December 2002 after ALC
    received calls from retailers who noticed frequent high payouts, and from
    its own inspections.  Chips were replaced in January and February 2003.
    [Glitch let gamblers beat machines, *The Chronicle-Herald*, Nova Scotia, 
    8 Mar 2003; PGN-ed] 
      http://www.herald.ns.ca/
    
    M Taylor  http://www.mctaylor.com/
    
    ------------------------------
    
    Date: Fri, 14 Mar 2003 18:54:43 -0500
    From: "Fuzzy Gorilla" <fuzzygorillaat_private>
    Subject: Haywire ATM spits out extra cash
    
    Several bank customers in Fargo, North Dakota, had an automated teller
    machine disperse more cash than they had requested.  (They turned it in.)
    Apparently ``cold weather caused the ATM cash door to stick so some
    customers who wanted to withdraw money could not get it.  The door opened
    for other customers, who then wound up with their cash and the cash
    belonging to the previous customers.''  [Source: AP, 14 Mar 2003; PGN-ed]
      http://story.news.yahoo.com/news
      ?tmpl=story2&u=/ap/20030314/ap_on_fe_st/haywire_atm
    
    ------------------------------
    
    Date: Mon, 17 Mar 2003 09:42:19 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: Beware the spelling checker
    
    A study at the University of Pittsburgh reveals that the ubiquitous spelling
    checker software may be doing as much harm as good, when it comes to
    writing.  In the study, 33 undergraduate students were asked to proofread a
    one-page business letter -- half of them using Microsoft Word, with its
    spelling- and grammar-checking features and the other half using only their
    brains.  Without the software, students with higher SAT verbal scores made,
    on average, five errors, compared with 12.3 errors made by students with
    lower scores.  However, using the software, the two groups made about the
    same number of errors -- 16 vs 17.  Dennis Galletta, a professor of
    information systems at the Katz Business School, says people have come to
    rely on spelling-checker software too completely. "It's not a software
    problem, it's a behavior problem."  [AP 14 Mar 2003; NewsScan Daily, 17
    March 2003; slight PGN-ed]
      http://apnews.excite.com/article/20030314/D7POQ7R80.html
    
    ------------------------------
    
    Date: Tue, 11 Mar 2003 10:20:36 -0500
    From: "David J. Aronson" <dja2003at_private>
    Subject: Recent worms punish bad passwords
    
      A spike in Internet traffic caused by a worm over the weekend can be
      largely blamed on bad passwords and poor security practices, said security
      experts on Monday. The Deloder worm, which spreads by communicating with
      Windows computers that have file sharing enabled, may have spread to
      perhaps as many as 10,000 systems using a list of 86 passwords to break
      into computers running Microsoft Windows NT, 2000 and XP.  [Source: MSNBC]
        http://www.msnbc.com/news/883415.asp:
    
    The same article later says:
    
      The recent LovGate worm -- which appeared on the Internet two weeks ago --
      uses a list of 16 passwords as a secondary way to infect computers.
    
    Yet another RISK of bad password choices.  And before PGN says it: 
    Deloder attacked de losers!  B-)
    
    David J. Aronson, Software Engineer for hire in Washington DC area.
    See http://destined.to/program/ for online resume, references, etc.
    
    ------------------------------
    
    Date: Tue, 18 Mar 2003 09:03:24 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: Profile of a virus writer
    
    According to the UK's Sophos, one of the world's largest antivirus
    companies, about 1,000 viruses are created every month, and in almost all
    cases the perpetrators are computer-obsessed males between the ages of 14
    and 34. "They have a chronic lack of girlfriends, are usually socially
    inadequate and are drawn compulsively to write self-replicating codes. It's
    a form of original graffiti to them," says Sophos CEO Jan Hruska. Virus
    writers tend to explore known bugs in existing software or look for
    vulnerabilities in new versions in order to create and spread their
    infections, and Hruska notes that the next target for the virus writing
    community could be Microsoft's .Net platform for Web services. To boost the
    impact of their creations, virus writers also tend to share information to
    create variants of the same infection, such as the infamous Klez worm, which
    has been among the world's most prolific viruses in the last year.
    [Reuters/CNet News.com 18 Mar 2003; NewsScan Daily, 18 March 2003]
      http://news.com.com/2100-1002-993023.html?tag=fd_top
    
    ------------------------------
    
    Date: Thu, 13 Mar 2003 11:53:32 +0000
    From: Richard Moore <richat_private>
    Subject: Search engines making sensitive information easy to locate
    
    I work for a company that performs vulnerability assessment using tools such
    as the nessus security scanner. Yesterday I was searching for more
    information about one of the security holes in a report, and I came across
    someone else's report with the same hole. Looking a bit further, I noticed
    that searching for 'nessus report' I got a dozens of pages back.  Some of
    the pages returned were sample reports from companies like ours (or the
    nessus site itself), but others were from people who had left their reports
    in location visible to search engines.
    
    The danger here is obvious - do you really want to make a list of all your
    security holes visible to the world? Things are actually even worse than
    they first appear too, because engines like google cache the pages, so even
    if you delete them people can still access the information.
    
    ------------------------------
    
    Date: Wed, 12 Mar 2003 13:06:07 -0500
    From: Monty Solomon <montyat_private>
    Subject: Benetton clothes to include tracking chip
    
    Clothes sold at Benetton stores will soon contain microchip transmitters
    that allow the Italian retailer to track its garments from their point of
    manufacture to the moment they're sold in any of its 5,000 shops.
      [Source: Associated Press, 11 Mar 2003]
      http://news.lycos.com/news/story.asp?section=Business&storyId=673780
    
    Tag, You're It: What Your Clothes Say About You
    Clothing designer Benetton plans to weave radio frequency ID chips 
    into its garment tags. While Benetton is poised to save money by 
    tracking the clothes with RFID, it could also mean a loss of 
    customers' privacy.   [Source: Elisa Batista, wired.com]
      http://www.wired.com/news/wireless/0,1382,58006,00.html
    
    ------------------------------
    
    Date: Wed, 12 Mar 2003 18:53:33 -0500
    From: Monty Solomon <montyat_private>
    Subject: CASPIAN calls for immediate worldwide boycott of Benetton
    
    An American consumer privacy group has called for an immediate, worldwide
    nboycott of Benetton, following disclosures that the company has placed
    identification and tracking devices into its clothing products.  CASPIAN
    (Consumers Against Supermarket Privacy Invasion and Numbering) announced
    that it will oppose Benetton's plans to place Radio Frequency Identification
    (RFID) chips into clothing labels intended for the consumer market.
    
    For additional information, see Phillips/Benetton press release: 
      http://biz.yahoo.com/bw/030311/115697_1.htm
    
    Forbes article illustrating remote inventorying of shoppers' clothing
    (As reproduced on Alien Technology's Web site)
      http://www.alientechnology.com/news/The_Internet_of_Things.htm
    
    CASPIAN overview of privacy concerns associated with RFID technology:
      http://www.nocards.org/AutoID/overview.shtml
    
    ------------------------------
    
    Date: Tue, 18 Mar 2003 17:57:55 -0500
    From: "brian-h seborg" <brian.seborgat_private>
    Subject: Federated network identity
    
    One of the "Holy Grails" of networking has long been the concept of single
    sign-on.  For those not familiar with the term, it refers to the ability for
    a user to authenticate once to some authentication server and then to have
    access to many different systems in a secure but unimpeded manner.  Kerberos
    includes the concept of single sign-on within its framework as does DCE.
    X.509 certificates and associated PKI also hold forth the concept of
    single-sign-on through the use of certificates that are issued by a trusted
    issuing authority, and can be presented as a means of authenticating the
    user.  More recently, Microsoft has come up with a Web-based identity in
    their Microsoft Passport standard.  A competing standard to Microsoft
    Passport is that being put forth by the Liberty Alliance Project.  In all of
    the standards above, there is the concept of users having a set of
    attributes or credentials associated with their authenticated identity.
    These credentials can be used to determine whether or not users should have
    access to certain systems, and, further, to determine the level of access.
    The attributes can also include such things as age verification, credit card
    information, address, etc. that could be used with on-line merchants for
    purchase or other purposes.  However, as this concept has matured, there is
    now the thought that users would be able to have (Microsoft Passport and
    Liberty Alliance), a single federated network identity, and that the user
    would have some control over what information he would be willing to share
    with different communities (e.g., a user could have a work profile
    associated with his ID that would provide certain salient information to
    work related computers and a home profile that would provide potentially
    different information to computers that the same user accesses from home).
    The ability to have such a federated network identity would, if it could be
    administered in a secure fashion, enable any Web site or Web application
    that accepted the federated identity (once authenticated by an identity
    provider) to have a clear idea of whom they are dealing with.  In other
    words, rather than Joe Smith connecting to a site as Joe Smith, JSmith,
    Jdog, etc. and appearing to be one or multiple users, he would be Joe Smith
    always.  Now, as you can imagine, the ability of Joe to be able to determine
    what information he wants to share with different sites would be important.
    For example, Joe may be quite willing to share his full name, mailing
    address, and credit card number with an on-line store, but only be willing
    to share his age with a porn site that may be allowing free tours to
    prospective customers who can provide age verification.  The problem is,
    that, as we have seen with the misuse of social security numbers by other
    than the Social Security Administration in the U.S., we can expect to see
    sites demanding more information than they legitimately need in order to
    allow access.  So, this places the burden (and perhaps rightly so) on the
    individual to make sure that he makes good choices as to what information he
    is willing to share with each community.  This may be quite a bit to expect
    of someone who is not technically savvy enough to understand the
    ramifications of these choices.  This risk can be mitigated to an extent by
    looking to a third party to help an individual reduce some of this risk.
    For example, if I connect to a portal provided by my bank and the bank
    performs the identity verification to ensure that I am who I say I am, then
    I may assume that any vendors that look to the bank to verify my identity
    and associated credentials have, themselves, been scrutinized by the bank
    and determined to be trustworthy at least to the extent that they have
    privacy policies that are similar to that of the banks so that information
    provided to them is treated with the same care as that provided to the bank.
    Unfortunately, I think this is contrary to reality.  So, the point is, be
    very suspicious of Microsoft Passport or of the Liberty Alliance Project, or
    any other group who is trying to create the equivalent of a universal ID.
    While I think that they have some very good ideas, and are trying to create
    a federated network identity with the best of intentions, there is much that
    is not being covered that may call for not only study by consumer groups,
    but for legislation and additional infrastructure.  Even then, I would still
    want to be able to anonymously surf the Web the same way I anonymously enter
    stores at the mall, knowing that I can walk in, look around and even
    purchase something without the store knowing who I am.
    
    ------------------------------
    
    Date: Tue, 11 Mar 2003 13:04:29 -0500
    From: Jonathan Kamens <jikat_private>
    Subject: Re: Computer crashes threaten hospital operations (Solomon, R-22.62)
    
    As far as I could tell from the article, what happened at Beth Israel
    Deaconess in November 2002 [year fixed in RISKS ARCHIVES. PGN-oops] was not
    a "computer crash."  That's one of the terms that journalists use when they
    either don't understand what went wrong or are trying to dumb it down for
    the semi-literate masses.
    
    Quoting from *The Boston Globe* article, "The computer crash at Beth Israel
    occurred when a research [sic] flooded the network with large quantities of
    data, causing the strained system to slow drastically.... networks must have
    sufficient bandwidth and modern routing systems, and should allow for
    portions to be shut down without the system becoming disabled."
    
    In other words, the network didn't have enough bandwidth to handle the
    traffic being thrown at it, there was no infrastructure in place for
    limiting the amount of bandwidth used by individual computers or
    applications, there was no infrastructure in place for monitoring bandwidth
    in real-time to detect anomalies and trace them to their sources, and there
    was no infrastructure in place for reactively locating high bandwidth
    consumers.
    
    For all of these things to be missing in a mission-critical network is
    shocking (and that's why the articles about it were written), but not
    terribly surprising.  Beth Israel Deaconess has been in dire financial
    straits for several years; I doubt they pay high enough salaries to attract
    the best and brightest IT professionals, people who understand the
    importance of constructing a robust network and how to go about doing it.  I
    also doubt they've budgeted enough money to be able to afford the proper
    infrastructure; perhaps, after last November's outage, that will change.
    
    ------------------------------
    
    Date: Fri, 14 Mar 2003 07:43:05 +1100
    From: gingrich <gingrichat_private>
    Subject: Re: Monster electricity bill (RISKS-22.61-62)
    
    I can comment in some detail about a similar situation.
    
    I worked for what was the State Electricity Commission of Victoria
    (Australia) in the early 1990s.  A new customer billing system was
    implemented which, among other things included a "special" interface for
    senior billing officers in each local office that bypassed most of the
    sanity checks in the system, and allowed the sanity checks to be
    over-ridden, if necessary.
    
    The electricity meter was replaced for a customer and this was not correctly
    recorded.  Then when the next, regularly scheduled meter reading was entered
    into the system, it looked as if the meter had gone from a low value to an
    even lower value.  This resulted in an enormous bill, a significant
    percentage (about 10%, from memory) of total sales for the district.
    
    The system asked for confirmation, but the operator (an ordinary data entry
    clerk, not the supervisor) thoughtlessly confirmed the entry.  Since it was
    "special" mode the transaction was confirmed.
    
    The customer received a bill for several million Australian dollars.
    
    The risks?
    
    Creating data entry screens with the power to gratuitously over-ride the
    sanity checks for the data that are built into the system.
    
    Is this really a direct problem with the computer system?  I'm not sure.  It
    is definitely a problem with the interaction between the computer system and
    the organisational systems designed to use the computer system.
    
    The real lesson is that there is a need to recognise that computer systems
    do not exist in isolation, and that giving the power to over-ride the system
    to ordinary users is a bad idea.
    
    Don Gingrich   gingrichat_private    School of CSIT, RMIT Melbourne, Au
    
      [New meters and wrap-arounds are of course old problems.  For example, see
      RISKS-7.40 and RISKS-12.16.  PGN]
    
    ------------------------------
    
    Date: Tue, 11 Mar 2003 16:40:21 -0500
    From: "Dawn Cohen" <COHENDat_private>
    Subject: Human protocol failure
    
    I guess I'm a bit influenced by RISKS, and observed a disturbing
    (human-based) protocol failure last week in my daughter's after school care.
    I think it would come down to one of those system-boundary things.
    
    On a normal day, my daughter goes to school on the school bus, but after
    school, she attends an after school program physically located in the
    school, but administered by the local YWCA.  I pick her up from the school.
    Transfer of daughter among three parties: school bus -> school -> YWCA.
    
    Last week, we had one of those days that we were being threatened with a
    snowstorm (early news reports promised 3-6 inches by afternoon), and this
    being New Jersey, everyone panicked.
    
    Because there was ultimately no serious accumulation of snow, everything was
    business-as-usual for most of the day.  However, at 2:00, I got a phone call
    from the after school program, indicating that the program would not be
    available that afternoon, due to the snow, and that I should pick my
    daughter up.  I arrived at the school at 3:00, and was herded into the
    cafeteria, to wait with the other anxious and disoriented after school
    program parents, for the 3:10 dismissal.  At 3:10, children began filtering
    into the cafeteria, and parents collected their children and left.  10
    minutes later, half a dozen parents remained, and we were informed by a
    teacher that all of the non-bus children had been released.  She said that
    the Y had told the school to put all the after school program children onto
    the school bus.  At that point, I ran out, and with some difficulty located
    the school bus that my daughter comes to school on (which had luckily not
    pulled out, yet), and pulled her off the bus.
    
    System risks here:  
    1) The school accepts YWCA's word that it has informed all parents of
       the closure of the after-school program (what if the Y had not been able
       to reach me?)
    2) The school accepts YWCA's word that it has informed all of the
       parents of  what action will be taken (this failed in my case)
    3) The school releases my child to a 3rd party (the school bus) that does
       not have sufficient information for the situation.  The school has
       emergency contacts for me and alternative pick-up people, as does the
       afterschool program.  The school bus department does not have this
       information.  It was not clear what the bus driver would have done if I
       had not rescued my daughter.  I asked him what would have happened if he
       tried to drop my daughter at the house, with nobody at home, and it seems
       like their protocol is the most sensible: if there is no one to receive a
       child, radio the transportation department.  The department then calls
       the home (the only number they have for me), and if no one answers, take
       the child back to school.  If I want my neighbors to take my child, I
       have to supply a note to this effect.
    
    I don't know.  Maybe I'm just refusing to take off my RISKS glasses, here,
    but I think there's problems in the protocol with all three parties.  I've
    communicated with the Principal, who refuses to accept any responsibility.
    She asserts that the whole fault is with the Y, who should have informed me
    that my daughter would be sent home on the bus.  Personally, from reading
    RISKS, I think it is unacceptable to assume that communication was sent
    correctly to all parents.  The school explicitly demands at the beginning of
    the year a list of acceptable people to release my child to, and the school
    bus is not on this list.  I guess a better protocol would require the Y to
    provide minimal coverage at the school until such time as any parents who
    have not been successfully contacted arrive.  Also, I guess I'm going to
    have to suggest that the transportation department keep my emergency
    contacts list, too.
    
    ------------------------------
    
    Date: Tue, 18 Mar 2003 17:00:38 -0500
    From: "Robert K. Cunningham" <rkcat_private>
    Subject: Announcement:  The Workshop on Rapid Malcode: WORM
    
                 The Workshop on Rapid Malcode (WORM)
                 Workshop held in association with the
      10th ACM Conference on Computer and Communications Security,
                  October 27th, 2003   Washington D.C.
                          Call for Papers
    
    In the last several years, Internet-wide infectious epidemics have emerged
    as one of the leading threats to information security and service
    availability.  The vehicle for these outbreaks, malicious codes called
    "worms", leverage the combination of software monocultures and the
    uncontrolled Internet communication model to quickly compromise large
    numbers of hosts.  Current operational practices have not been able to
    manage these threats effectively and the research community is only now
    beginning to address this area. The goal of this workshop is to bring
    together ideas, understanding and experience bearing on the worm problem
    from a wide range of communities including academia, industry and the
    government.  We are soliciting papers from researchers and practitioners on
    subjects including, but not limited to:
    
        Modeling and analysis of propagation dynamics
        Automatic detection, characterization, and prediction
        Analysis of worm construction, current & future
        Propagation strategies (fast & obvious vs slow and stealthy)
        Reactive countermeasures
        Proactive defenses
        Threat assessment
        Forensic methods of attribution
        Significant operational experiences
    
    Paper submissions due 1 Jul 2003; submission instructions will appear at
      http://pisa.ucsd.edu/worm03/ 
    
    General Chair: Stuart Staniford, Silicon Defense
    Publicity Chair: Robert Cunningham, MIT Lincoln Lab
    Program Committee Chair: Stefan Savage, UC San Diego
    Program Committee Members: Robert Cunningham, MIT Lincoln Lab;
      Anup Ghosh, DARPA; David Moore, CAIDA/UC San Diego; 
      Carey Nachenberg, Symantec; Vern Paxson, ICIR/LBL; 
      Phil Porras, SRI; Jeff Rowe, UC Davis; Mike Skroch, Sandia; 
      Stuart Staniford, Silicon Defense; Don Towsley, UMassAmherst
    
    Dr. Robert K. Cunningham, Information Systems Technology Group
    MIT Lincoln Laboratory  http://www.ll.mit.edu/IST/
    
    ------------------------------
    
    Date: 29 Mar 2002 (LAST-MODIFIED)
    From: RISKS-requestat_private
    Subject: Abridged info on RISKS (comp.risks)
    
     The RISKS Forum is a MODERATED digest.  Its Usenet equivalent is comp.risks.
    => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
     if possible and convenient for you.  Alternatively, via majordomo,
     send e-mail requests to <risks-requestat_private> with one-line body
       subscribe [OR unsubscribe]
     which requires your ANSWERing confirmation to majordomoat_private .
     If Majordomo balks when you send your accept, please forward to risks.
     [If E-mail address differs from FROM:  subscribe "other-address <x@y>" ;
     this requires PGN's intervention -- but hinders spamming subscriptions, etc.]
     Lower-case only in address may get around a confirmation match glitch.
       INFO     [for unabridged version of RISKS information]
     There seems to be an occasional glitch in the confirmation process, in which
     case send mail to RISKS with a suitable SUBJECT and we'll do it manually.
       .UK users should contact <Lindsay.Marshallat_private>.
    => The INFO file (submissions, default disclaimers, archive sites,
     copyright policy, PRIVACY digests, etc.) is also obtainable from
     http://www.CSL.sri.com/risksinfo.html  ftp://www.CSL.sri.com/pub/risks.info
     The full info file will appear now and then in future issues.  *** All
     contributors are assumed to have read the full info file for guidelines. ***
    => SUBMISSIONS: to risksat_private with meaningful SUBJECT: line.
    => ARCHIVES are available: ftp://ftp.sri.com/risks or
     ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
       [volume-summary issues are in risks-*.00]
       [back volumes have their own subdirectories, e.g., "cd 21" for volume 21]
     http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
       Lindsay Marshall has also added to the Newcastle catless site a
       palmtop version of the most recent RISKS issue and a WAP version that
       works for many but not all telephones: http://catless.ncl.ac.uk/w/r
     http://the.wiretapped.net/security/info/textfiles/risks-digest/ .
     http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/
    ==> PGN's comprehensive historical Illustrative Risks summary of one liners:
        http://www.csl.sri.com/illustrative.html for browsing,
        http://www.csl.sri.com/illustrative.pdf or .ps for printing
    
    ------------------------------
    
    End of RISKS-FORUM Digest 22.64
    ************************
    



    This archive was generated by hypermail 2b30 : Tue Mar 18 2003 - 16:09:54 PST