[risks] Risks Digest 21.77

From: RISKS List Owner (riskoat_private)
Date: Wed Nov 21 2001 - 12:56:05 PST

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

    RISKS-LIST: Risks-Forum Digest  Weds 21 November 2001  Volume 21 : Issue 77
    
       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 <URL:http://catless.ncl.ac.uk/Risks/21.77.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    
      Contents:
    FBI targets suspects' PCs with spy virus (NewsScan)
    A tell-all that ZD would rather ignore (Declan McCullagh via Monty Solomon)
    Risks with automated counting of ballot papers: Australia (Chris Maltby)
    Evolution, Thermodynamics, and Software Bugs (William Colburn)
    Re: Programming error scrambles election results (Paul Terwilliger,
      Ralph Barone, Richard Stein, Edward Reid, Bob Dubery)
    Re: Researchers probe Net's 'dark address space' (Scott Peterson)
    Fun with automated car washes, or the importance of interface design 
      (Aaron M. Ucko)
    Re: Feds make record counterfeit software seizure (Denis Haskin)
    Re: Glitch in iTunes Deletes Drives (Paul Ward, Geyser Admin)
    Re: Sweden's public radio reportedly bans SETI... (Nick Brown)
    Re: Telephone Area Code (Patrick O'Beirne)
    Re: Google freely giving out ... (Rebecca Wright)
    Re: DoS attack on Mac OS9 (David Cake)
    Abridged info on RISKS (comp.risks)
    
    ----------------------------------------------------------------------
    
    Date: Wed, 21 Nov 2001 07:32:53 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: FBI targets suspects' PCs with spy virus
    
    The FBI is working on software that could insert a computer virus into a
    suspect's computer capable of reading encrypted data.  The software, known
    as "Magic Lantern," installs "keylogging" software that can capture
    keystrokes typed on a computer.  The virus can be sent via e-mail.  Once on
    the targeted PC, it waits for a suspect to launch the Pretty Good Privacy
    encryption program and then logs the passphrase used to start the program,
    essentially giving agents access to the keys needed to decrypt files.  The
    Magic Lantern software is part of the FBI's "Enhanced Carnivore Project
    Plan," which operates under the umbrella project name of Cyber Knight.
    Electronic Privacy Information Center attorney David Sobel says privacy
    issues arise when keylogging results in "overly broad" searches, since it
    would be possible to observe every keystroke typed by the suspect, even if a
    court order specified only encryption keys.  The FBI has already used a
    less-sophisticated version of the software to build the high-profile
    racketeering case against Nicodemo Scarfo, but had to manually turn the
    system on and off in order to comply with the court order.  [MSNBC/Wall
    Street Journal 21 Nov 2001; NewsScan Daily, 21 November 2001]
      http://interactive.wsj.com/articles/SB10062942834030720.htm (sub req'd)
    
      [Insertion by e-mail probably works well for Microsoft software, which is
      prone to that kind of attack.  Various reports suggest that Magic Lantern
      can also plant itself by penetrating systems.  Penetrability of supposedly
      secure systems has long been noted here, with further risks resulting from
      a weak system that is directly networked to supposedly more secure systems
      (especially if done with single-sign-on authentication).  This may not be
      a case where one good (LAN-)turn deserves another.  PGN]
    
    ------------------------------
    
    Date: Tue, 20 Nov 2001 08:39:52 -0500
    From: Monty Solomon <montyat_private>
    Subject: A tell-all that ZD would rather ignore
    
    Declan McCullagh, Wired News, 20 Nov 2001
     
    If you subscribe to any of Ziff-Davis' computer magazines, you may want to
    double-check your credit-card bill next month.  Ziff-Davis Media, which
    publishes such popular tech titles such as Yahoo Internet Life and PC
    Magazine, accidentally posted the personal information of about 12,500
    magazine subscribers on its website.  On 19 Nov 2001, ZD removed the data,
    which included hundreds of credit-card numbers, and said its engineers had
    taken steps to prevent additional security leaks.
      http://www.wired.com/news/ebiz/0,1272,48525,00.html
    
    ------------------------------
    
    Date: Tue, 20 Nov 2001 16:00:10 +1100
    From: Chris Maltby <chrisat_private>
    Subject: Risks with automated counting of ballot papers: Australia
    
    As RISKS readers may be aware there was a national election in Australia on
    10 Nov 2001.  Australian electoral procedures have many features which US
    readers in particular would find unusual, but perhaps the most surprising of
    all is the method used to elect Senators for each of the states.
    
    A preferential voting system is used (a complete order of preference must be
    shown) and those candidates who receive a quota (a proportion based on the
    number of positions to be filled) are elected. Any votes surplus to quotas
    are redistributed at reduced value, and least preferred candidates are
    excluded until all positions are filled. The interested can refer to
    http://www.aec.gov.au/pubs/factfiles/factsheet7.htm or the truly masochistic
    to the legislation which specifies the counting method.
     http://scaleplus.law.gov.au/html/pasteact/0/57/0/PA003450.htm
    
    In a normal half-senate election, 6 senators are elected, meaning that a the
    quota value is about 14.3% -- within the bounds of possibility for smaller
    parties.
    
    With a trend toward an increased number of candidates, a simplification was
    introduced in the late 1980s whereby political parties could nominate a
    preference "ticket" and the voter can choose the party ticket by voting in
    boxes above a thick line which divides the ballot paper. Alternatively the
    voter can number all the squares below the line (65 in all in the recent
    election in New South Wales).  Since its introduction, the number of voters
    using the above the line method has grown at each election and was above 95%
    in 2001.
    
    The increase in ticket voting has made feasible the automated "scrutiny" or
    determination of the result, and the Electoral Act was amended before the
    1998 election to permit this. All that is needed is for the 3-5% of below
    the line papers to have their order of preference captured, the total number
    of voters who selected each of the tickets and then the legislated method
    can be applied and the result determined "instantly" instead of taking
    several weeks by the manual method. The taxpayer wins if the time taken to
    input the ballots is shorter than the time taken by the manual procedure...
    
    But the risk is in the accountability. In a manual election, each of the
    candidates is entitled to appoint an observer (scrutineer) who may check for
    irregularities in the process.  It may be mind numbingly boring, but it is
    feasible.
    
    The automatic system is much more difficult. The legislation permits the
    scrutineer access only to a record of:
     * the preferences on the ballot-papers ... stored in the computer; and
     * the ballot-papers that ... are transferred at each count; and
     * the progress of the count of the votes, at each count.
    
    Note that the source code of the software which determines the result nor
    its operating environment are explicitly not available for scrutiny, meaning
    that each scrutineer must be able to reproduce the process independently to
    sufficient accuracy to detect errors or fraud (refer to the legislation link
    above).  Also the scrutineer(s) must attempt to observe the accuracy of
    hundreds of data entry staff as they enter the ballots at full speed.
    
    As the result can be affected by cascading differences triggered by tiny
    numbers of votes changing the order of exclusions, it's probably only a
    matter of time before there is a very interesting case in the Court of
    Disputed Returns.
    
    ------------------------------
    
    Date: Mon, 19 Nov 2001 13:25:00 -0700
    From: "Schlake ( William Colburn )" <schlakeat_private>
    Subject: Evolution, Thermodynamics, and Software Bugs 
    
    (Re: Programming error scrambles election results (RISKS-21.74)
    
    There is an interesting paper I recently read.  It shows that biological
    evolution is just like debugging.  Selective pressure, such as poison
    (debugging), on a biological system will kill as few members as possible to
    keep the system stable.  Software bugs are the same way.  Debugging is a
    selective pressure (selected by the debugger to meet their expectations) and
    will remove as few software bugs as possible.
    
    See "Murphy's law, the fitness of evolving species, and the limits of
    software reliabilty", at:
      http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/babtr.pdf
    
    The authors webpage is at:
      http://www.cl.cam.ac.uk/~rja14/
    
    ------------------------------
    
    Date: Mon, 19 Nov 2001 15:56:13 -0500
    From: Paul Terwilliger <paultat_private>
    Subject: Re: Programming error scrambles election results (RISKS-21.75)
    
    Both Mr. Marson and Mr. Kos, in their comments about the San Bernardino
    election problem, make a common mistake.
    
    There is programming, and there is programming.
    
    "Programming" an election is not writing software.  It is akin to
    programming a VCR.  In other words, entering data to describe the layout of
    the ballot.  Sometimes vendors do this, sometimes county employees do.
    
    (Even though I do not know which particular vendor's equipment was used, all
    are alike in this regard.)
    
    Does this make testing unnecessary?  Of course not.  But let's make sure we
    understand where the failure was.
    
    Paul Terwilliger, Sequoia Voting Systems, Inc.
    
    ------------------------------
    
    Date: Mon, 19 Nov 2001 14:08:47 -0800
    From: "Barone, Ralph" <Ralph.Baroneat_private>
    Subject: Re: Programming error scrambles election results (Marson, RISKS-21.74)
    
    I believe that in order to truly test a piece of software, at least two
    testers are needed.  The first would be somebody with a complete enough
    understanding of the problem that he/she could have coded the program
    themselves.  This person would review the code for logical errors,
    robustness of algorithms, etc...  The second tester would be a person with
    minimal knowledge of the system (representative of the least trained person
    ever likely to operate the system).  This person will unwittingly test all
    the user interface and data checking assumptions made by the original
    programmer.
    
    ------------------------------
    
    Date: Mon, 19 Nov 2001 16:13:00 -0800
    From: Richard Stein <rsteinat_private>
    Subject: Re: Programming error scrambles election results (Marson, RISKS-21.74)
    
    If you want to know the cost of quality, prepare to purchase it!  
    
    A 'real' software test engineer, one who is exceptionally knowledgeable of
    the fundamental technology mechanisms residing at the core of modern
    products (like threads, synchronization, scheduling, signals, process
    tracing, message passing, VM, etc.) is mighty, mighty rare and plenty
    expensive.
    
    Certain cultural and educational barriers forestall the creation of many.
    Peer ostracism, managerial indifference, and professional lassitude often
    conspire against this career choice.
    
    The best folks prefer product engineering (aka 'development'). Hell, a good
    test engineer must continuously author and develop test assets well ahead of
    any product engineering activity.  In the past 7 years, I have authored in
    excess of 400Kstatements of PERL/C/C++ comprising thousands of individual
    functional test assets and dozens of reliability evaluations.  I know kernel
    hacks who have struggled for months to find a 1 line race condition fix
    arising from a wimpy program.
    
    Creating non-deterministic product evaluations that compel races, corrupt
    data, generate deadlock, cause resource leakage, panic, coredump, or other
    fatal conditions is more of an art than a method.  No matter how stupid or
    non-sensical an input, a product must remain deterministic and
    self-consistent (this is the famous user-is-an-idiot postulate).
    
    Deterministic evaluations consume substantial test engineering cycles: all
    those inputs, a little product logic, and assertions of output takes many
    keystrokes.  Such exhaustive measurement is often the only means to show
    program feature and function correctness.  What I'd give to out-think Alan
    Turing on this issue!
    
    Many for-profit organizations do not really understand that test engineers
    author intellectual property too: IP the customer does not purchase, but
    what they experience as a consequence of test asset quality ; If the test
    assets stink, the product stinks.
    
    That's what test engineers do -- function as editors (as in newspaper
    publications) to raise product IP quality.  To be successful, test engineers
    must embody the worst customers in the world, and the best friend a product
    can have.  The only acceptable customer feedback is a purchase, not a
    complaint.
    
    How does proactive test engineering compare to a 'nuclear' customer support
    hotline post-release?  Its hard to query corpses -- especially dot-bombs.
    If management believes any warm body will suffice to successfully and
    thoroughly evaluate 1Mline+ C++ software toxic wastedumps, dig up a corpse
    from a cemetery and apply a space-heater, but don't hire a button pusher.
    
    We all know its far cheaper to fix bugs in the system before release, and
    even easier/cheaper when in the earliest SDLC phases.  But testing and other
    means to ensure quality are often short-changed because of disciplinary
    failure and organizational, ethical lapses -- covert institutionalized
    violence.
    
    Richard M. Stein, StudioCentral Test Engineering Contractor  650-933-7391
    
    ------------------------------
    
    Date: Tue, 20 Nov 2001 10:50:03 -0500
    From: Edward Reid <edwardat_private>
    Subject: Re: Programming error scrambles election results (RISKS-21.75)
    
    Takes a lot more than understanding the problem, etc.. The person who really
    understands the problem is generally only going to enter expected, correct
    data for the problem domain. The programmer tends to be limited by the
    expectations of the program, the skilled user by the expectations of the
    problem domain. Good testing is a different skill. If you want a program to
    be ready for prime time, get it tested by someone skilled in testing. Of
    course the tester must know something about the problem domain, and testing
    by both the programmer and the skilled user are valuable too.  But testing
    is a skill in itself.
    
    ------------------------------
    
    Date: Tue, 20 Nov 2001 07:37:47 +0200
    From: "Bob Dubery" <bduberyat_private>
    Subject: Re: Programming error scrambles election results (Kos, RISKS-21.75)
    
    > nobody (not even I! ;) can be relied on to find their own bugs.
    
    And also there is less chance of them LEARNING from their bugs - so the
    "method" behind the bug tends to propagate.
    
    I had been arguing about the existence of a bug with two programmers from
    another dept in the IT organisation that I work for.
    
    Eventually I got to take a peek at the code in which - according to me - the
    bug had to exist. I found it in minutes. The programmer concerned had
    written code that ignored a lock in the database with the result that
    updates were sometimes "lost" if two instances of the code were running
    simultaneously.
    
    When I showed the programmer (a junior person) who wrote the code the bug
    and explained it she quickly grasped the flaw in her logic and went off to
    check several other bits of work she'd done to see if she had reproduced the
    bug. She now also understands a particular aspect of her job and the
    language she works with better than she used to.
    
    A test in a multi-user scenario and/or a code review would have quickly
    uncovered a bug that caused some acrimony and a loss of money - and would
    have resulted in a programmer who had had improved their craft.
    
    One of the RISKs of not having code reviews and good test procedures in
    place is that inexperienced junior programmers will become poorly
    experienced senior programmers and the bugs will propagate.
    
    ------------------------------
    
    Date: Mon, 19 Nov 2001 14:29:19 -0800
    From: Scott Peterson <scottp4at_private>
    Subject: Re: Researchers probe Net's 'dark address space' (Poulsen, R-21.75)
    
    I'd suggest that a large part of this is due to explicit blocking of IP 
    ranges by system administrators.  This could either be local blocks or 
    published lists like MAPS or SPEWS.  Getting on SPEWS, for example will 
    make about 30% of the Internet unreachable if you get listed.
    
    Also, for cable modems, I'd think a  large part of this is the arrogance, 
    unresponsiveness and incompetence of the administrators of the cable 
    networks, especially @home.  They've gotten into lots of local block lists 
    because they won't shut off abusers or even respond to complaints.
    
    ------------------------------
    
    Date: 19 Nov 2001 21:53:57 -0500
    From: "Aaron M. Ucko" <amuat_private>
    Subject: Fun with automated car washes, or the importance of interface design
    
    My wife and I had an unexpected adventure when we went to get our car washed
    at a gas station the other day.  (I am withholding the name of the chain to
    protect the not-so-innocent, and because it is probably not the only culprit
    anyway.)
    
    First, some background: the system is fully automated, and offers three
    levels of operation.  (The cheapest doesn't even dry the car, and the most
    expensive includes tire scrubbing and other frills.)  Because we had
    recently gotten the car used, we decided to go for "The Works."  Also, the
    station offers a discount with the purchase of 8 gallons or more of gas; in
    order to get this discount, you need to buy a code for the machine with your
    gas.
    
    Anyway, the first problem we encountered came about when ordering: the
    display at the pump told us to press 1, 2, or 3 to select a cycle, but did
    not specify which was which.  Assuming that it went from cheapest to most
    expensive, we pressed 3, only to be told that we had selected the basic
    cycle.  Fortunately, it asked for confirmation, so we went back and selected
    1 instead.
    
    Next, we drove up to the car wash (which involved waiting in line for a
    little while, waited for the previous driver to finish, punched in our code
    (for "The Works"), and drove into the machine.  It started to wash our car,
    but then stopped in the middle of the cycle -- with a little barrier
    effectively preventing us from driving out the other side.  (We could
    probably have driven over it if we had pressed hard enough on the gas, but
    it didn't seem like a great idea.)  The machine appeared to be completely
    dead; the screen which normally displays something like "enter," "exit," or
    "washing" was blank.
    
    Experimentally, we backed up slightly, at which point the machine told us to
    drive forward again; when we were back in the target position, it started
    all over -- with a basic cycle, which it at least finished properly.  At
    that point, we drove out unhindered and went to complain to the management.
    We convinced them to give us a new code for "The Works", and returned to the
    back of the car-wash line.
    
    When we got back inside the machine, it stopped at the same point as before.
    This time, we just gave up and waited for something to happen; after a few
    minutes, the attendant came out (at the behest of the driver behind us), and
    motioned that we should again drive backwards for a moment and then back
    forwards to the target position.  This maneuver again caused the machine to
    restart -- this time with what appeared to be a "deluxe" cycle.  Since that
    cycle included the remainder of the things we wanted, we decided that it was
    good enough and that we had wasted enough time there, and so simply drove
    off.
    
    Our hypothesis is that both times, the drivers behind us had confused the
    machine by entering their codes before we were done -- an action which the
    interface allows, and even appears to encourage[1] -- and that each time we
    backed up, it restarted with the cycle the next driver had ordered.
    
    The risks?
      * Poorly presented menus can lead to undesired selections.
      * Badly designed machines can trap their users.  (Note that in this
        case, a Big Red Button would not have sufficed, since it was not
        entirely clear that the machine might not suddenly restart and
        injure whoever got out of the car to push it.)
      * Systems that prompt for input before they are ready for it can
        fail unpleasantly.
    
    [1] After telling one driver to enter, it immediately prompts for another code.
    
    Aaron M. Ucko, KB1CJC <amuat_private> (finger amuat_private)
    
      [Nonatomic transactions can be quite explosive.  PGN]
    
    ------------------------------
    
    Date: Mon, 19 Nov 2001 17:24:49 -0500
    From: Denis Haskin <Denisat_private>
    Subject: Re: Feds make record counterfeit software seizure (RISKS-21.75)
    
    Um, perhaps I'm being naive, but it's not clear to me what the "risks to the
    public in computers and related systems" is in this case.  Sure, there's a
    risk that consumers may be buying software that's not legit, but is there an
    allegation that the software is flawed in some way?  Isn't this sort of like
    buying a Rolex on a NY street corner?
    
    ------------------------------
    
    Date: 12 Nov 2001 12:20:39 -0500
    From: paswardat_private
    Subject: Re: Glitch in iTunes Deletes Drives (Solomon, RISKS-21.74)
    
    NO!  The problem was _NOT_ that some "bleary-eyed coder" missed a couple of
    quotes.  The problem was that Apple's process for reviewing software prior
    to shipping to catch the _inevitable_ syntactically correct but semantically
    flawed code was broken.  And broken badly if such a obvious error could 
    slide through undetected.
    
    paulward (DrGS)
    
    ------------------------------
    
    Date: Mon, 12 Nov 2001 11:39:04 -0800
    From: Geyser News Server Admin <news-adminat_private>
    Subject: Re: Glitch in iTunes Deletes Drives (RISKS-21.74)
    
    Before the Mac haters out there take any glee from this incident, a
    clarification is important.
    
    What was left out was the reason why the quotes are important-- On the Mac,
    file and directory and disk names can and do contain spaces. With the new
    Unix-based OSX, long-time mac users are discovering the hard way that spaces
    are used as delimiters in scripts and in parsing, so filenames containing
    spaces can have unintended results. Most Unix code samples and docs assume
    that no one ever puts spaces in their file names, so the samples never show
    quotes being used, and some docs don't mention this need either.
    
    Just about every programmer making the Mac switch from OS 9 to 10 finds 
    this out the hard way, just not as publicly and catastrophically.
    
    The risk-- changing the underlying behavior of familiar software, and 
    not being aware of all the assumptions behind that underlying behavior.
    
    ------------------------------
    
    Date: Mon, 12 Nov 2001 09:15:43 +0100
    From: BROWN Nick <Nick.BROWNat_private>
    Subject: Re: Sweden's public radio reportedly bans SETI... (RISKS-21.74)
    
    I agree that it's unlikely that the US military needs extra Swedish PC
    computing power to plot missile trajectories, but the Swedes have been here
    before.  In the mid-90s the Swedish parliament and other government offices
    acquired Lotus Notes, and one factor in their choice was the "secure"
    encryption it provided.  Until they found out that the CIA had a master key.
    So the line between "conspiracy theory" and "justifiable paranoia" is
    perhaps blurred in this case.
    
    There is also the RISK that in running any code from SETI@home, you are
    trusting SETI's site not to be hackable by someone who might want to run
    some other code on your computer.  If someone put a replacement client in
    there which trashed your hard disk at a given date/time, I suspect the
    worldwide damage would put the "ILoveYou" worm to shame.
    
    ------------------------------
    
    Date: Mon, 12 Nov 2001 09:16:35 +0000
    From: "Patrick O'Beirne" <pobeirneat_private>
    Subject: Re: Telephone Area Code (Hecht, RISKS-21.74)
    
    > I can't find a way, in the *import* function, to define these numbers as
    > "text" so that Excel will leave them alone upon import.  Sigh.
    
    Text Import Wizard step 1 - choose fixed/delimited
    Step 2 - column breaks
    Step 3 is where you set the column format - choose Text for IP addresses
    
    http://www.sysmod.com/spreads.htm
    Patrick O'Beirne B.Sc. M.A. FICS
    
    ------------------------------
    
    Date: Tue, 20 Nov 2001 17:37:45 -0500 (EST)
    From: Rebecca Wright <rwrightat_private>
    Subject: Re: Google freely giving out ... (Re: Ziglar, RISKS-21.75)
    
    Listings can (at least now) be removed using a form found at
    http://www.google.com/help/pbremoval.html, which was linked to from the
    "More phonebook listings" on my Google telephone listing.  This form itself
    is not without risks.  First, they require (off-line) authentication only
    for removal of business sites, so individuals can have their listings
    removed by others even if they would prefer to have their listings remain.
    Second, your communication with Google about your phone listing can actually
    help them establish its correctness (and they ask for your e-mail address
    too), so depending on your trust level in Google to handle your personal
    information, you might consider it better to remain silent than to
    voluntarily give them verified information about yourself.
    
      [RISKS received a Google-plex of e-mail on this subject.  
      This information is widely available on the Internet, on CD-ROM,
      etc.  Thanks to all who responded.  PGN]
    
    ------------------------------
    
    Date: Mon, 12 Nov 2001 13:31:52 +0800
    From: David Cake <daveat_private>
    Subject: Re: DoS attack on Mac OS9 (Gat, RISKS-21.73)
    
    >Sure, you can change passwords if you have physical access to the machine.
    >You can also boot any Mac with a MacOS 9 CD and completely circumvent all
    >protection.
    
    Firmware security can make it much more difficult to boot from a MacOS 9 CD
    (or any other bootable CD), and avoids some similar simple methods of
    circumventing password authentication (booting in single user
    mode). Firmware security is a recent, and poorly documented, addition to the
    Macintosh that is not present on all models, and on many machines will
    require a firmware update. It is a significant protection against the
    casual, Macintosh capable but not truly expert, attacker, and is thus
    probably a good idea for situations such as unattended kiosks or laboratory
    machines. It cannot, however, be completely relied on.
    
    There are two methods to bypass firmware security.  One is a reasonable and
    prudent method - if you change the RAM in the machine, it also resets the
    firmware security. Perhaps there will be unintended consequences from those
    are unaware of this poorly documented side effect, but it is necessary that
    there be some means of disabling the feature to prevent machines being
    rendered unbootable, and it is appropriate that it be some feature that
    requires access to the internals of the machine for a reasonable amount of
    time. If you are in a situation where firmware security is an issue, you
    should also be implementing physical security (Apple generally makes it easy
    to secure access to the case with a padlock or similar on most models).
    
    Unfortunately, there exists a weakness in the implementation of the firmware
    security that enables the dedicated attacker to discover the Open Firmware
    password and thus bypass this protection, and a program to exploit this
    vulnerability is available.
    http://www.securemac.com/openfirmwarepasswordprotection.php
    
    Luckily, it runs only under Mac OS 9, so Mac OS X machines are relatively
    safe (it does not run under Classic), but this cannot be relied upon, as the
    same underlying vulnerability exists and it is simply a matter of someone
    writing code to exploit it.
    
    Apple does appear to be gradually increasing the amount of 
    security, and  definitely appear to be treating security on Mac OS X 
    as a serious issue. Unfortunately, there are still some weaknesses 
    that have been discovered.
    
    David Cake (Macintosh and Unix consultant), Difference Engineering
    
    ------------------------------
    
    Date: 12 Feb 2001 (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 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.
       .MIL users should contact <risks-requestat_private> (Dennis Rears).
       .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 20" for volume 20]
     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 21.77
    ************************
    



    This archive was generated by hypermail 2b30 : Wed Nov 21 2001 - 14:13:53 PST