[risks] Risks Digest 22.07

From: RISKS List Owner (riskoat_private)
Date: Sat May 18 2002 - 16:16:34 PDT

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

    RISKS-LIST: Risks-Forum Digest  Saturday 18 May 2002  Volume 22 : Issue 07
    
       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/22.07.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    
      Contents:
    Apple Computer's hidden spam filtering (Derek K. Miller)
    Apple: break your new PC with a copy-protected CD, it's not our fault
      (Charles Arthur via Dave Farber)
    Shipping the Big Iron: a computer-related risk! (Mike Hogsett)
    UK govt wants to make "e-filing" compulsory for taxes (David Cantrell)
    Verisign doesn't encrypt credit-card info (Daniel Norton)
    Making a list, checking it never (Adam Shostack)
    Re: The Console Buffer Knows... (Dick Mills)
    Re: GNU is not UNIX (Theodore Ts'o, Dimitri Maziuk)
    More on Klez (Bob Morrell, Paul Mech)
    Abridged info on RISKS (comp.risks)
    
    ----------------------------------------------------------------------
    
    Date: Thu, 9 May 2002 10:46:54 -0700
    From: "Derek K. Miller" <dkmillerat_private>
    Subject: Apple Computer's hidden spam filtering
    
    According to a recent report at the Mac-focused news site MacInTouch, Apple
    Computer places surreptitious spam filters on the free POP3/IMAP mac.com
    e-mail addresses it provides to Mac OS computer users.
    
    <http://www.macintouch.com/applemailfiltering.html>
    
    Apple does not advertise its filtering, does not reveal how it works, and
    provides no way to turn it off or adjust its parameters.
    
    The risk is clear: spam filtering is far from perfect, and Apple's is no
    exception. It both lets through actual spam and rejects some legitimate
    mail, including (so far) a number of postings from e-mail lists that mac.com
    users have explicitly subscribed to. Worse, the messages are bounced back to
    the sender, but the recipient has no way of knowing anything is missing
    unless he or she is expecting something in particular. The only way the Mac
    user community found out about the filtering was when list administrators
    whose messages had been bounced contacted Apple to find out what was wrong.
    
    The problem is particularly acute for those who use mac.com as their primary
    or only e-mail address, since there is rarely any way for mistakenly blocked
    "spammers" to contact them to let them know anything's wrong. Users have no
    way of knowing how much mail they may have missed.
    
    The approach is also puzzling, since spam protection is usually a benefit
    ISPs and e-mail providers like to promote to their users. And in most
    instances they provide the option to deactivate or adjust it too.
    
    Derek K. Miller - dkmillerat_private, Writer, Editor, Web Guy, Drummer, Dad
    Vancouver, BC, Canada  | http://www.penmachine.com
    
    ------------------------------
    
    Date: Fri, 10 May 2002 15:44:02 +0100
    From: "Charles Arthur, The Independent" <carthurat_private>
    Subject: Apple: break your new PC with a copy-protected CD, it's not our fault
    
      [From Dave Farber's IP,
        http://www.interesting-people.org/archives/interesting-people/]
    
    An interesting little endnote in
    http://kbase.info.apple.com/cgi-bin/WebObjects/kbase.woa/wa/query
      ?searchMode=Expert&type=id&val=KC.106882
    (Apple tech note 106882)
    which is mostly about how to get out one of those copy-protected CDs, e.g.,
    Shakira's "Laundry Service" if you put it in your Mac and the thing goes
    gray screen on you.
    
    Lots of stuff about poke this and prod that. And at the end, a note which I
    translate to mean "Hey, nothing to do with us, you did the equivalent of
    sticking a fork in the toaster":
    
    "CD audio discs that incorporate copyright protection technologies do not
    adhere to published Compact Disc standards. Apple designs its CD drives to
    support media that conforms to such standards. Apple computers are not
    designed to support copyright protected media that do not conform to such
    standards.  Therefore, any attempt to use non standard discs with Apple CD
    drives will be considered a misapplication of the product.  Under the terms
    of Apple's One-Year Limited Warranty, AppleCare Protection Plan, or other
    AppleCare agreement any misapplication of the product is excluded from
    Apple's repair coverage. Because the Apple product is functioning correctly
    according to its design specifications, any fee assessed by an Apple
    Authorized Service Provider or Apple for repair service will not be Apple's
    responsibility."
    
    Interesting. So whose fault is it? The user's, one must surmise. But I
    foresee some more sticky labels - perhaps ADMIN ADVISORY - INCLUDES
    EXPLICIT WARRANTY BREAKING DATA
    
    ------------------------------
    
    Date: Fri, 10 May 2002 15:04:17 -0700
    From: Mike Hogsett <hogsettat_private>
    Subject: Shipping the Big Iron: a computer-related risk!
    
    We recently arranged with Sun for them to lend us one of their larger
    systems, a Sun Fire 4800.  The machine has 208Gbytes RAM & 12 CPUs.  Not a
    cheap machine.  It is mounted within its own 72" tall cabinet.  It is
    shipped in a wood crate which is approximately 3' wide by 4' deep by 8'
    fall.  Gross weight is about 900 pounds.
    
    Since their warehouse is just across the San Francisco Bay from us, they
    contracted with a local carrier to ship it to us.  The machine was picked up
    from their warehouse, placed into the truck, and arrived at our receiving
    department a few hours later.
    
    When the driver and our receiving personnel opened the trailer door, the
    crate was lying on its side, although it had been upright when it left the
    warehouse.  The driver stated that he had heard a loud bang after making a
    turn and had thought he may have blown a tire.
    
    On the crate there were several shock sensors and tilt sensors, only one of
    which had tripped (the one which was face up when it was on its side).
    There were also instructions telling us what to do if these sensors had been
    tripped.
    
    The instructions told us to accept shipment but to inspect for damage and
    call the carrier.  We did accept shipment but did not open the crate to
    inspect for damage.  We contacted our representative at Sun for advice.
    
    Our representative is having a replacement shipped to us and the unit which
    is here now will be picked up and sent back.
    
    I was quite surprised that the crate was not strapped in and tied down tight
    given how narrow, tall, and heavy this crate was, not to mention the value
    of its contents.
    
    Michael Hogsett
    
    ------------------------------
    
    Date: Fri, 10 May 2002 18:38:14 +0100
    From: David Cantrell <davidat_private>
    Subject: UK govt wants to make "e-filing" compulsory for taxes
    
    This is taken from *Metro*, a [...] free tabloid distributed on trains and
    tubes in the London area.  The same story appears in *The Register* and
    elsewhere:
    
      E-mail taxman or face UKP3,000 fine, by Sarah Getty
      
      Companies and individuals will be fined up to UKP3000 if they fail to file
      tax figures via the Internet, it emerged yesterday.  Measures proposed in
      the government's new Finance Bill mean that so-called 'e-filing' of
      payroll information will be phased in for larger businesses in the next
      few years.
      
      By 2010, all employers will be required to submit tax forms online.
      But accountants fear elderly and disabled people who employ carers, or
      people who use nannies, will be caught up in the legislation if they pay
      through a payroll system.  ...  He also objected to the way the Bill is
      framed, which means little parliamentary scrutiny will be required is the
      Inland Revenue or Treasury wants to extend the powers of the Bill...
    
    The RISKS are obvious, both in terms of accessibility of this online
    filing system, but also the growing trend for legislation by regulation,
    thus allowing ministers to bypass parliament.
    
    David Cantrell   http://www.cantrell.org.uk/david
    
    ------------------------------
    
    Date: Thu, 09 May 2002 07:45:16 -0400
    From: Daniel Norton <Danielat_private>
    Subject: Verisign doesn't encrypt credit-card info
    
    Their slogan is "The Value of Trust", but why trust an organization that
    doesn't protect credit-card data when you sign up for a "Code Signing
    Digital ID?"
    
    The actual URL is too long for inclusion here, but it's the link at the
    end of this page that reads "Code Signing Digital ID for Microsoft
    Authenticode" (above where it reads "US $400.00 annually"):
    
      http://digitalid.verisign.com/developer/ms_pick.htm
    
    Fill out the form and include your credit-card number below where it reads
    "All enrollment and credit-card information is transmitted securely using
    the Secure Sockets Layer (SSL) protocol and VeriSign Server IDs."  But also
    note the absence of any "secure" indicator on your web browser.
    
    Press "Accept" and all form data is submitted in plain text to Verisign.
    
    ::slaps forehead::
    
    The RISKS lesson?  Don't trust anyone just because they say "Trust me."
    
    ------------------------------
    
    Date: Fri, 10 May 2002 11:48:31 -0400
    From: Adam Shostack <adamat_private>
    Subject: Making a list, checking it never
    
    Risks of mis-identification, arrest, etc, from law enforcement databases are
    well documented.  The new, secret terrorism databases are starting to repeat
    these mistakes, as documented in a New Yorker article on a 70 year old black
    woman (Johnnie Thomas) is in a set of FBI databases, because "John Thomas
    Christopher" was an alias used by Christian Michael Longo, once on the FBI
    top ten most wanted list.  Unfortunately for Johnnie Thomas, even the fact
    that Mr. Longo is in jail in Oregon hasn't removed her name from the
    computers, and the New Yorker article documents her (so far unsuccessful)
    attempts to clear her name.
    http://www.newyorker.com/talk/content/?020513ta_talk_mcnamer
    
    The application of fair information practices; allowing people to
    know what data is stored about them, to access and correct records,
    etc, is often brushed aside for law enforcement claims that the data
    must remain secret.  Does anyone know if these databases are the 
    the Expanded Computer Assisted Passenger Screening Program, or
    something else?
    
    ------------------------------
    
    Date: Thu, 9 May 2002 16:14:29 -0400
    From: Dick Mills <dmillsat_private>
    Subject: Re: The Console Buffer Knows... (Bergman, RISKS-22.06)
    
    > However, I think that there's a RISK when someone uses an apparently 
    > "dumb" device with no intrinsic "history" to connect to another device 
    > (the switch) with no command history, and yet there's a record of every 
    > screen preserved weeks later.
    
    True; but when we examine the totality of the risks archives, and Mr.
    Neumann's book it becomes clear that the number of security pitfalls in
    computer use are so great in number, that even the most experienced and
    vigilant among us can't avoid making fools of ourselves fairly often.
    
    My conclusion is that meaningful security comes only with the military
    approach of physically limiting access to computers and networks of
    computers containing secure information. Everything short of that has to be
    considered half measures and evidence that the information owner isn't
    really serious about security.
    
    For the vast majority of the computing community that is not willing to take
    measures as extreme as the military does, the implication is that we must
    design our systems and procedures and set our expectations on the
    presumption that our work is not secure and can never be secure.  At least
    in my humble opinion.
    
    ------------------------------
    
    Date: Thu, 9 May 2002 12:22:59 -0400
    From: "Theodore Ts'o" <tytsoat_private>
    Subject: Re: GNU is not UNIX (Maziuk, RISKS-22.06)
    
    Dimitri's rant contains a number of inaccuracies as well as misconceptions
    or myths.  [It also had a typo in the subject line that has been fixed in
    the archives for search purposes.  It also provoked a lot of responses, some
    of which are interspersed by me within Ted's comments here.  PGN]
    
    First of all, with regards to Stallman's rants about "LiGNUx", this is a
    very long and often debated point.  To claim that it has a good technical
    reason is very much stretching the argument.  At its base it is
    fundamentally a social/political question, and it's all about the FSF trying
    to take credit for a very popular OS movement.  Stallman himself freely
    admits that the reason why he tried to rename the operating system was to
    try to draw Linux Users (many of whom are primarily pragmatists who use it
    because it's best for what they want to do, and not for any kind of
    political reason) into embracing his particular political agenda with
    respect to Copyleft and the FSF's definition of "Free Software".
    
    Dimitri claims that "Linux" has lots of GNU software in it, when in point of
    fact, even the most highly inflated figure claimed by the FSF is 28% of a
    typical Linux distribution, and for some distributions, (for example SuSE)
    the percentage of FSF code compared to other Open Source code is far, far
    less.  There are of course many other arguments and counter-arguments ---
    including the FSF's contention that the XFree86 code should be counted as
    GNU software because the FSF would have included it in their vision of a GNU
    system --- never mind the fact that XFree86 wasn't written by the FSF and
    isn't even distributed under the GPL.  ("Any code is GNU if I say it is!")
    However, the arguments start losing technical and logical and even
    rhetorical integrity quite quickly, and I won't waste the RISKS reader's
    time with any more of it.
    
    (It also should be noted that while Dimitri claims that BSD is not GNU, *BSD
    systems also uses the GNU toolchain, and many other pieces of GNU software;
    so where's the clear technical distinction between when something is GNU and
    when something isn't?)
    
    Secondly, with respect to Linux the killall command, it should be noted that
    first of all, contrary to Dimitri's assertion, IRIX's killall does allow the
    "killall -HUP inetd" construction; as does NetBSD, OpenBSD, and Linux.  So
    to say that this is unique to Linux is quite incorrect.  Furthermore, Irix,
    Linux, and OpenBSD killall implementations are all independent, and do not
    derive from the same source; the authors of each of them consciously made
    the same design decision.  "Killall" as a program which kills all process
    and which does not take an argument is actually a System V'ism; it was never
    in BSD 4.3 or Version 7 Unix.  [Dik Winter and Anton Ertl noted that Irix
    killall also is able to accept a processname and thus behaves like Linux
    killall.  Anton Ertl and Toby Cabot both noted that Linux's killall is not
    GNU, it is from Werner Almesberger's psmisc package (and that is specific to
    the Linux /proc filesystem).  
    
    > Back in 1975 professionals designed an OS called Unix. Being professionals,
    > they realised the need for certain design principles.  Such as splitting a
    > task into a number of smaller subtasks and designing a separate tool to
    > handle each subtask (that does one thing, and does it well) [0].
    
    [Kragen Sitaker noted that Unix began in 1969, not 1975.  True.  Ken
    Thompson was on our Bell Labs Multics team until 1969, and Oleg Broytman
    noted that Unix was designed *for* professionals (and primarily for their
    own use!).  PGN]
    
    This design principle is oft quoted, but rarely in its entirety.  The
    *other* half of the Unix design principal was to observe what combinations
    of commands were frequently used, and optimize those.  So for example,
    although you could search files looking for a particular pattern by using
    /bin/ed's "g/<re>/p" command, it was used often enough that it was worth
    while for the Bell Labs "professionals" to create the command "grep".
    
    If only the first part of the Unix minimalist design principle was all there
    was to it, there would be no need for the grep command.  Heck, there would
    be no need for the System V "killall" command --- it would be possible to
    implement it via smaller sub-components, so by what rights should it exist?
    Indeed, the System V "killall" command is used so rarely (only by the
    shutdown scripts), that arguably, it shouldn't exist at all, even using the
    argument which justifies the existence of grep.  It's only used in one
    instance, so there's no justification for optimizing it or packaging it as a
    stand-alone command.
    
    In addition, the reason why people get into trouble when trying to run
    "killall -HUP inetd" on a Solaris machine is because the Solaris version
    doesn't check the arguments it was passed; a well designed and robust
    program should check the validity of its arguments, and fail if they are not
    what was expected --- and this includes the presence of arguments when none
    are supported.
    
    For this reason, since the System V killall is such a useless,
    unjustifiable, badly implemented botch of an idea --- let me defend the
    honor of the "1975 professionals" which Dimitri invoked by stating that
    killall was not their fault.  It was the fault of the people at AT&T who
    among other things, gave us abominations such as System V streams.  [To
    amplify that, Peter van Hooft notes that there was no killall in Version 7,
    and Anton Ertl did similarly.  PGN]
    
    So to the extent that the Linux, *BSD, and Irix maintainers all decided to
    ignore this "prior art" in favor of something much more useful, this was a
    Good Thing.  After all, "killall -HUP inetd" is far more useful and commonly
    used that it's worth being able to do this rather forcing the system
    administrator to type:
    
    	kill -HUP `ps ax | grep inetd | awk '{print $1}'`
    
    Don't you think?
    
    > As software becomes more complex, it requires more sophisticated build
    > tools.  More and more open source software is being developed using GNU
    > compilers and build tools, and it is becoming dependent on them. The result?
    > -- While portability at the level of each compilation unit is still
    > maintained, the whole thing is not portable anymore. It fails to build on
    > non-GNU systems [2].
    
    This is an old problem, and it's not unique to GNU or Linux --- remember
    back in the days of BSD 4.3, and Henry Spencer's 10th Commandment of his
    "Ten Commandments of Unix"?
    
      "10.  Thou shalt forswear, renounce, and abjure the vile heresy which
      claimeth that ``All the world's a VAX'', and have no commerce with the
      benighted heathens who cling to this barbarous belief, that the days of
      thy program may be long even though the days of thy current machine be
      short."
    
    The annotated version http://www.lysator.liu.se/c/ten-commandments.html
    points out that an updated version of this heresy would be "All the world's
    a Sun".  In the years before Linux became ascendent, I remember having to
    work with lots of programs available on the Internet which only worked on
    Solaris machines, and didn't compile or run correctly on Ultrix or OSF/1
    machines.  This is not a new issue; your claim that this is somehow unique
    to GNU/Linux systems is simply not fair nor historically accurate.
    
    The main problem is that most of the bug-fixing takes place on those
    platforms which are most easily available no matter what it was.  Back in
    the day when the development community had plenty of VAX systems running BSD
    4.3, guess what most programs were optimized for?  And back when most people
    with Internet access were running SunOS, guess what most programs were most
    likely to run under?
    
    Sun is actually partially at fault here, actually, at least with respect to
    the problem you stated of many programs assuming the use of the GCC and the
    GNU toolchain.  Back when Sun stupidly started charging for their C compiler
    as a separate, optional package, and never looked back, many people switched
    to using the GNU toolchain, and never looked back.  Given that GCC is
    available for Solaris, the incentive to making packages portable to the
    native tool chain is simply much, much less.  (But hey, if it's so important
    to you, the whole point of Open Source software is that you can fix the
    problem yourself, and contribute the changes back to the maintainer.)
    
    >And since GNU compiler and build tools are unable to produce 64-bit
    >code on Solaris, the libraries, and all software that uses them must
    >be built as 32-bit binaries. Now, why did I pay for that 64-bit
    >hardware, again?
    
    Actually, that last is a very good question.  Unless you needed the address
    space the 64-bit provides, in most cases there is no advantage to compiling
    programs to run in 64-bit mode.  Indeed, to the extent that the pointers and
    integers take up more space, programs can actually run more slowly and take
    up more memory unnecessarily when you compile them as 64-bit binaries.
    Given that most of the Open Source programs you want to run probably don't
    need the 64-bit address space (very few programs, other than scientific
    computation and database engines do), the fact that you're compiling GNOME
    or Gnumeric in 32-bit mode is probably the right thing; it's certainly not a
    problem.  [Anthony W. Youngman notes that linux ran on SPARC in full 64-bit
    mode long before Solaris did.  PGN]
    
    > GNU project in particular did a great service to software community by
    > promoting and popularizing free software. It also did a great disservice by
    > turning the whole thing into a political issue, and pretty much ignoring the
    > need for competence and expertise on the part of software developers.
    > Instead of sound software engineering, we now have "Free Speech"
    > flag-waving [3].
    
    First of all, many members of the Linux development community don't pay much
    attention to the FSF's political agenda.  (This is the whole reason for the
    "Open Source" vs. "Free Software" terminological debate, which in turn
    inspired Stallman to try to claim Linux as his own by trying to rename it to
    LiGNUx"; as I said, this is not a technical issue, but a political one ---
    and many, many people in the Linux world do not subscribe to the FSF
    political agenda.)
    
    Secondly, it's very much unfair to make such a huge generalization; many
    open source software packages are written or maintained by professionals,
    and it shows.  Some of it isn't.  In general, software which works gets
    used.  Software which doesn't, doesn't get used.  People don't choose to use
    Linux because of the FSF's political agenda; they use Linux (or FreeBSD, or
    MacOSX) because it does what they need it to do; because it crashes less
    often than Windows; because they are able to "look under the hood" and fix
    themselves if necessary, instead of being at the mercy of vendor who might
    or might not deign to fix a bug which is critically affecting your business.
    
    Open Source software may not be perfect, but then again, no commercially
    available operating system which is available at reasonable prices is
    perfect, or even close to perfect.  The stories in RISKS have proven this
    over and over again.
    
      [RISKS received numerous counter-rants (NOTE: ``counterrants'' might seem
      like count-errants, as in knight-errants), including admonitions to your
      moderator for running Dimitri's rant in the first place.  But the mere
      existence of his rant suggests that some education is needed, and
      hopefully Ted's message has provided some.  I have interspersed a few
      of the comments received as they apply above.  PGN]
    
    ------------------------------
    
    Date: Thu, 9 May 2002 13:06:18 -0500
    From: Dimitri Maziuk <dmaziukat_private>
    Subject: Re: GNU is not UNIX (T'so, RISKS-22.07)
    
      [Dimitri's own counter-counter-rant is excerpted here by PGN.]
    
    Most software licenses that I bothered to read expressly disclaim "any
    warranty as to suitability or fitness for any purpose". To me, that spells
    "crap".
    
    Commercial developers are at least [implicitly] honest: they're here to make
    money. If they can make money from crap, more power to them.
    
    When crap is being pushed as the best thing since sliced bread because it's
    "Free as in Beer" (or "Speech", or whatever) (read: "it makes some nerd with
    zero social skills feel good about himself"), well, forgive me if all I feel
    about that is disdain.
    
    I'm a great believer in Open Source, Public Science, and sharing of
    ideas. But you know what? -- my job is to keep software up and running. I
    don't care if it pays someone's bills, or if it suits someone's political
    agenda. All I care about is that it works.
    
    And in my experience software that works is software written by clueful
    developers -- professionals, experts, -- be that Wietse Venema, Linus
    Torvalds, or Borland language design team.
    
    None of which has anything to with the fact that GNU is Not Unix, and as
    more people come to grown-up Unices from GNU background, screw-ups like the
    one with killall will become more and more common.
    
    PS. As for 64-bit hardware, here's a hint: if you have SPARC
    Solaris 7 or 8, run this script:
     #!/bin/bash
     if [ $((2048*1024*1024)) -lt 0 ] ; then echo "Your bash has Alzheimer's" ; fi
    and see what it says. And if you have any shell scripts that e.g. 
    monitor RAM or disk usage, better go check them really carefully.
    
    ------------------------------
    
    Date: Thu, 9 May 2002 12:18:12 -0400
    From: "Bob Morrell" <bmorrellat_private>
    Subject: More on Klez (Re: Slade, RISKS-22.05)
    
    Rob Slade's comments on Klez was a useful summary of the broader aspects 
    of this recent worm.
    
    I agree that the unusual lack of publicity on this worm is puzzling and
    problematic. However, the much more disruptive aspect of this worm which
    Mr. Slade mentioned has been Klez's penchent for sending e-mail in other
    people's name.
    
    Person A, gets the virus, and his computer sends an infected e-mail to
    person B in the name of person C. At this point several things can happen,
    all of which cost the users (and their Network admins oodles of time).
    
    The most common is that person B sends an angry e-mail to person C (whom
    they often do not know) or worse, to person C's business/domain.  Non
    computer system admins want to know what person C is doing (and their
    questions are more pointed when Klez uses a sexually suggestive subject
    header). They look suspiciously at C, and at C's LAN admin, who had
    certified that C's computer was patched and had adequate virus
    protection. Explaining the complexities of this worm to less than computer
    literate admins often takes two or three attempts, and even then I think
    some of them still think they should ding someone.
    
    Person B has a server based e-mail viral scanner and sends a notification of
    failure to deliver to C, who flips out, believing their computer is
    infected. Again, the complexities of this worm are hard to communicate, and
    much time is wasted trying to explain, and all the assurances you have given
    them about how up to date an secure their computer is (and why it is worth
    all the time and effort you put into antiviral and patches) suffer a
    credibility hit. User C may even try to contact B's domain seeking an
    explanation (and more time is wasted on all sides).
    
    This is in effect, a new form of identity theft, and the time wasted in
    orientation (what is going on?) and repairing perceptions and reputations
    can be substantial.
    
    The risk? Too many e-mail users still believe that 'from' header, unaware
    how easy it is to fake. As Klez forces them to understand this, they almost
    certainly will over-react, which ultimately will undermine the efforts to
    make digital signatures and online validation more common.
    
    Bob Morrell, Cancer Center, http://home.triad.rr.com/bmorrell/
    
    ------------------------------
    
    Date: Thu, 09 May 2002 01:47:17 -0400
    From: Bitwolf Programming <mp0283at_private>
    Subject: Re: More on Klez (Re: Slade, RISKS-22.05)
    
    I have a minor addition to Rob Slade's observations and comments.  Though
    not vulnerable myself to Klez, I've had to deal with infections on a number
    of e-mail lists.  To my experience, the Return-Path header generally
    contains the infected person's address, or enough of a clue that you can
    narrow down the listmember[0] who _might_ be infected.  Given that this is
    malware, there is a RISK in relying on it, but for the moment it does
    provide clues useful in identifying and alerting folks with infected
    machines.
    
    Paul Mech
    
    [0] Many folks on an e-mail list will have other people from the list
    bookmarked.  Thus some of the malware's forgeries will fool some lists into
    accepting it's spawn.
    
    ------------------------------
    
    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.
       .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 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.07
    ************************
    



    This archive was generated by hypermail 2b30 : Sat May 18 2002 - 17:43:57 PDT