[risks] Risks Digest 23.20

From: RISKS List Owner (risko@private)
Date: Wed Feb 25 2004 - 18:47:41 PST

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

    RISKS-LIST: Risks-Forum Digest  Weds 25 February 2004  Volume 23 : Issue 20
    
       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://www.risks.org as
      http://catless.ncl.ac.uk/Risks/23.20.html
    The current issue can be found at
      http://www.csl.sri.com/users/risko/risks.txt
    
      Contents: [Backlogged]
    King/Drew patient monitors shut off following 2 deaths (Sheri Alpert)
    Bug in Windows-operated toilet system (Wendy M. Grossman)
    Physical security of electronic voting terminals (Tobin Fricke)
    Chipmakers race to plug the buffer overflow problem (NewsScan)
    Buffer overflows and Multics? (Tom Van Vleck)
    An old filtering problem, but worth repeating (Drew Dean)
    Anti-captcha technique (Lindsay Marshall)
    Further misdirected on-line trip planning (Mark Brader)
    Conspiracy Theory: mortgage scams (NewsScan)
    Osama Bin Laden is not on the no-fly list? (Peter Wayner)
    MS Java Virtual Machine issue (Ferdinand John Reinke)
    Garage-door openings by aircraft (John Slimick, Kevin G. Rhoads)
    Re: Garage-door openers (Peter B. Ladkin)
    Re: Garage-door openers by Sputnik (Steve Bellovin)
    Re: Drunk unlocks police car with own key (Adam Laurie)
    Abridged info on RISKS (comp.risks)
    
    ----------------------------------------------------------------------
    
    Date: Thu, 11 Sep 2003 21:39:00 -0500 (EST)
    From: Sheri Alpert <salpert@private>
    Subject: King/Drew patient monitors shut off following 2 deaths
    
    On 10 Sep 2003, Tracy Weber and Charles Ornstein reported in the *Los
    Angeles Times* that the Martin Luther King Jr./Drew Medical Center was
    disconnecting a new $411,000 patient-monitoring system, after the deaths of
    two patients for whom alarms failed to alert nurses that urgent attention
    was needed in the summer of 2003.  [PGN-ed]
      http://www.latimes.com/news/local/la-me-kingdrew10sep10,1,3521718.story
    
    ------------------------------
    
    Date: Sat, 21 Feb 2004 11:01:12 +0000
    From: "Wendy M. Grossman" <wendyg@private>
    Subject: Bug in Windows-operated toilet system
    
    I was at a press conference on Thursday with PalmSource at One Aldwych,
    which is one of those hyper-modern London hotels.  One of its features is a
    airplane-style vacuum-operated toilet system.  One of the Palm execs told me
    that while they were staying at the hotel this system failed, and any time
    they wanted to use the bathroom or take a shower they had to call the
    reception desk and get escorted to the corporate headquarters in the
    building next door to use the facilities there.  For a couple of *days*.
    
    It transpires that the entire plumbing system is run by a Windows-based
    computer system and whatever went wrong with it was so obscure that they had
    to get a technician from the company that supplied it on a plane down from
    Scotland to fix it and reboot.
    
    The Blue Screen of Sewage?
    
      [There's a "Sucker" Borne Every Evacuation!  PGN]
    
    ------------------------------
    
    Date: Wed, 25 Feb 2004 14:32:17 -0800
    From: Tobin Fricke <tobin@private>
    Subject: Physical security of electronic voting terminals
    
    A cart of Diebold electronic voting machines was delivered today to the
    common room of this Berkeley, CA boarding house, which will be a polling
    place on Tuesday's primary election.  The machines are on a cart which is
    wrapped in plastic wrap (the same as the stuff we use in the kitchen). A few
    cable locks (bicycle locks, it seems) provide the appearance of physical
    security, but they aren't threaded through each machine. Moreover, someone
    fiddling with the cable locks, I am told, announced after less than a minute
    of fiddling that he had found the three-digit combination to be the same
    small integer repeated three times.
    
    One wonders whether paper ballots would be handled differently, how the
    terminals are stored between elections, what checks are done for tampering
    before the use of the terminals, and what physical security features are
    built into them.
    
    ------------------------------
    
    Date: Mon, 23 Feb 2004 08:56:20 -0700
    From: "NewsScan" <newsscan@private>
    Subject: Chipmakers race to plug the buffer overflow problem
    
    The next generation of microprocessors will plug the gaps that have resulted
    in "buffer overflow" vulnerabilities, causing Microsoft to issue repeated
    "critical security alerts." The buffer section of computer memory stores a
    finite amount of data. To exploit the flaw, hackers cause more data to be
    sent to the buffer than it can hold, forcing it to overflow into the next
    chunk of buffer memory, where they then deposit their malicious code. This
    leaves the computer open to attack, as demonstrated by the devastating
    Slammer and Blaster worm invasions in 2003. "Buffer overflows are the
    largest class of software vulnerabilities that lead to security flaws," says
    the head of one security company. The new chips will be designed to block
    this avenue of attack, although security experts predict that determined
    hackers will find other ways to insert computer viruses -- for example, by
    making a program jump to a subsection of its own code at the wrong time,
    perhaps to open a data port to a hacker.  [*New Scientist*, 22 Feb 2004;
    NewsScan Daily, 23 Feb 2004]
      http://www.newscientist.com/news/news.jsp?id=ns99994696
    
      [Historical reminder: In 1965, the Multics hardware (GE then Honeywell
      645) provided segmented, paged, ring-structured hardware enabled the
      software to achieved measures of security that are not common today.  The
      combination of hardware, the PL/I language subset, the language runtime
      environment, the stack discipline (non-executable, which cut way down on
      overflows; also, the stack grew to higher addresses, making the overflow
      of a buffer unlikely to clobber the return address in the stack frame),
      and good software engineering discipline helped prevent most buffer
      overflows in Multics.  See Tom Van Vleck's subsequent message, as well as
      his Web site, multicians.org.  PGN]
    
    ------------------------------
    
    Date: Mon, 23 Feb 2004 16:23:45 -0500
    From: Tom Van Vleck <thvv@private>
    Subject: Buffer overflows and Multics?
    
    To make a big deal out of providing the 40-year-old feature of marking a
    region of memory non executable is kind of sad.  Multicians look at each
    other and make the rubbing-sticks-together gesture.
    
    It seems to me that the marketing guys and the popular press writers don't
    understand the feature, the need for the feature, or what the feature will
    and won't accomplish.
    
    It's not magic.  It fixes some common problems, leaving other problems
    untouched.  It's not a substitute for defensive coding and proper management
    of storage; all it means is that if there is a mistake, it is more work for
    an attacker to exploit it.
    
    As Paul Karger points out, when attackers are frustrated by one measure,
    they don't abandon their attacks.  They keep looking for other holes.  A fix
    like this, applied by itself, will lead to a new equilibrium between
    attackers and defenders, maybe favoring one or the other, but the game will
    remain the same.
    
    Closing one open barn door is good, but it needs to be complemented by a
    systematic approach to enumeration of openings, and a method of closing the
    openings by architectural design that applies to all openings.  So I was
    taught by my leaders on the Multics project, including Corby, Bob Morris,
    Jerry Saltzer, Ted Glaser, PGN, and many more.
    
    ------------------------------
    
    Date: Tue, 24 Feb 2004 12:13:49 -0800 (PST)
    From: Drew Dean <ddean@private>
    Subject: An old filtering problem, but worth repeating
    
    Mike Cassidy has a column in the *San Jose Mercury News* on 24 Feb 2004
    entitled "Sending e-mail can be a struggle if your name has a 4-letter
    word."  A Scottish gentleman named Craig C*ckburn (generally pronounced
    Coburn) had all too difficult a time receiving his e-mail.  It turns out
    that Mr. C*ckburn's job title is "senior IT application speci*list", which
    also has problems due to the word "speci*list" containing the substring
    "ci*lis" (when used as a proper noun, a Vi*gra competitor).
    
    Not new, but increasingly painful for many people.
    
      http://www.mercurynews.com/mld/mercurynews/business/8026783.htm
    
    Drew Dean, SRI International
    
    PS: How many spam filters will barf on this message?  Or will PGN edit it?
    
      [Indeed.  I took mercy on Drew's message and have tried to avoid 
      the expected filters.  Note other words such as "multiraci*alism",
      "soci*lism", "commerci*lism", and even "commerci*lise" (British),
      also get trashed, not to mention words in other languages.
      (The asterisks above are easily interpreted as the letter "o" or "a".)
      *@#$%*!  <expletive deleted>  PGN]
    
    ------------------------------
    
    Date: Fri, 20 Feb 2004 13:26:37 -0000
    From: "Lindsay Marshall" <Lindsay.Marshall@private>
    Subject: Anti-captcha technique
    
    I don't remember seeing a posting about the suggested anti-captcha technique
    that was discussed recently on slashdot. A "captcha" is the (horrible) name
    used to describe the distorted graphics referred to by Thomas Harrington in
    RISKS-23.29. The (completely brilliant) idea is that every time spammers
    have to deal with such an image they bring it up on the screen of someone
    who is looking for free porn and pretend that they are doing a check. The
    user will respond and the answer gets forwarded back up the line. The
    /. discussion is at
    http://yro.slashdot.org/article.pl?sid=04/01/28/1344207&mode=flat,
    the original Boing-Boing posting is at
    http://boingboing.net/2004_01_01_archive.html#107525288693964966
    
    Very hard to beat human ingenuity.
    
    ------------------------------
    
    Date: Mon, 23 Feb 2004 13:49:09 -0500 (EST)
    From: msb@private (Mark Brader)
    Subject: Further misdirected on-line trip planning
    
    [Adapted from alt.fan.cecil-adams (by PGN, who adds that Mark contributed
    two similar items to RISKS-20.62, with a follow-up by Chris Smith in
    RISKS-20.63)]
    
    Phil Jern" <pjern1@private>:
      Somewhere around here I have driving directions that I printed out a few
      years ago that showed 4,900-odd miles for a trip from New Jersey to Atlanta
      that included 2 borders crossings in and out of Canada.
    
    Bill Kinkaid <billkinkaid@private>
      The transit system here has a trip planner feature on their Web site
      (translink.bc.ca). You key in where you want to start, where you want
      to wind up and when, and it tells you which buses to take and when to
      get them. A few times in off-hour periods (say Sunday morning) it's
      given me some very bizarre routings where I can look at the map and
      say "I get on this bus here and get off it there, just tell me when".
      Telling me to go from Marpole to Coquitlam via South Delta and Surrey
      Centre, f'rinstance.
    
    Mike Brandt <MyLastName@private>
      In the early days of Amtrak's online trip planner, I asked it about trains
      from Portland (Oregon) to Seattle. There are several trains each day that
      make this 3.5 hour trip. The first choice on the route planner's list was
      Portland -> Chicago -> LA -> Seattle, taking about a week, and passing
      through Portland again 3.5 hours before arriving in Seattle.
    
    ------------------------------
    
    Date: Thu, 19 Feb 2004 09:19:51 -0700
    From: "NewsScan" <newsscan@private>
    Subject: Conspiracy Theory: mortgage scams
    
    Lawsuits filed yesterday by AOL and Earthlink accuse individuals and
    companies of running spam networks. The AOL suit alleges a conspiracy
    between three Floridians and two Americans living in Thailand to route
    mortgage-scam solicitations to AOL customers and to defeat AOL's spam
    filters through a company called Connor-Miller Software Inc. Earthlink is
    accusing 16 individuals and companies in Florida, California, Tennessee and
    Michigan of operating a multi-state spam operation that has sent more than a
    quarter of a billion e-mail messages promoting herbal supplements,  Vi*gra
    and adult dating services and of using stolen identity documents to open
    Earthlink Internet accounts that were used to transmit the spam. The
    attorney who represents the Florida defendants in the AOL lawsuit argues
    that his clients are innocent of spamming: "They set up a network, just like
    AOL is a network."  [*The Washington Post*, 18 Feb 2004; NewsScan Daily, 19
    Feb 2004]
    http://www.washingtonpost.com/wp-dyn/articles/A52951-2004Feb18.html
    
    ------------------------------
    
    Date: Fri, 20 Feb 2004 07:44:05 -0500
    From: Peter Wayner <pcw@private>
    Subject: Osama Bin Laden is not on the no-fly list?
    
    "According to airline-security documents obtained by this magazine, the name
    Osama bin Laden was punched into the computer by an airline official and,
    remarkably, that name was cleared at the security checkpoint all passengers
    must pass through before being issued a boarding pass. "
      http://www.wnd.com/news/article.asp?ARTICLE_ID=37167
    
      Seems like a very general RISK. Some Turing machines just don't halt if
      they don't find the right name.
    
    ------------------------------
    
    Date: Mon, 23 Feb 2004 11:21:22 -0500
    From: "Reinke @ A" <Reinke@private>
    Subject: MS Java Virtual Machine issue
    
    Are you familiar with the MS Java Virtual Machine (MSJVM) issue?  After
    September 30th 2004, Microsoft will no longer be able to support this
    technology.  As a result, customers who have the MSJVM installed after this
    date will be vulnerable to potential attacks that will attempt to exploit
    this technology. This problem is compounded by the fact that Microsoft will
    no longer be able to provide software updates or patches to the MSJVM. This
    issue is not just a concern for organizations that use Java, but will also
    impact anyone who has the MSJVM installed. More alarming, many organizations
    aren't even aware that they have MSJVM installed.   [...]
    
    Ferdinand John Reinke, Consultant, 3 Tyne Court, Kendall Park, NJ 08824
    
    ------------------------------
    
    Date: Wed, 18 Feb 2004 22:14:26 -0500 (EST)
    From: John Slimick <slimick@private>
    Subject: Garage-door openings by aircraft (Re: RISKS-23.19)
    
    Sometime in the late Sixties when my wife and I were living on Arbor Road in
    Menlo Park (not far from SRI), I was standing outside close to my landlord's
    garage when a lumbering four-engine jet liner passed overhead, possibly a
    little lower than usual. As it passed overhead, the garage door began to
    open (it had one of the earlier remote openers). After the plane passed, I
    went over and closed the door.
    
    When I asked about it to other, more knowledgeable people, I was told that
    the aircraft transponder was the culprit, and the phenomenon was not unknown
    in the Bay area.
    
    ------------------------------
    
    Date: Mon, 23 Feb 2004 11:04:18 -0500
    From: "Kevin G. Rhoads" <Kevin.Rhoads@private>
    Subject: Garage-door openings by aircraft (Re: RISKS-23.19)
    
    We had a house with a 1970-ish vintage garage door opener.  Many of these
    used frequencies that were "shared" with certain aviation uses.
    
    Whenever our house was in the approach path to Boston/Logan the door would
    get triggered easily two to three times a day.  When the jets were not being
    approach-routed over us, it rarely happened -- only once that I remember.  I
    simply disabled the remote receiver.
    
    Using a single frequency with no keying as a trigger is like using a one-pin
    lock, or a 1 character password.
    
    I don't think that needs any further explanation in the RISKs forum.
    
    ------------------------------
    
    Date: Thu, 19 Feb 2004 08:41:01 +0100
    From: "Peter B. Ladkin" <ladkin@private-bielefeld.de>
    Subject: Re: Garage-door openers (RISKS-23.19)
    
    Cases of garage doors opening uncommanded through radio-frequency
    interference are not urban legends, although I don't know specifically about
    Sputnik.
    
    In 1981, I briefly owned a house on Arlington Avenue in Kensington, CA, with
    an automatic door. I slept often in the room over the garage. When there was
    a storm in the Bay Area, SFO sometimes used Rwy 19 for landings, instead of
    the usual 27L/R. The initial approach was radar vectors, and many aircraft
    used to fly over the Berkeley Hills. I recall that a number of times when
    aircraft flew over in the early morning, I heard the garage door open. (It
    piqued both my curiosity and my sense of security, so I remember going to
    some effort to figure out possible correlations. The aircraft were the only
    one that I recall. Police radios could have been another - the police
    station was just up the road and cars used Arlington Avenue all the
    time. But I recall ruling that out.)  That was the only time of which I am
    aware at which the door opened uncommanded. I don't know when the garage
    door was installed. The house was some 20-30 years old then, as I recall.
    
    I didn't know much about avionics at the time, so I didn't confirm it
    through technical details.
    
    I seem to recall mentioning something about this in Risks at some point.
    
    An urban legend with which I am directly familiar concerns mobile phones on
    gas station forecourts igniting fuel fires. I wrote about it in "An Example
    of Everyday Technical Risk Analysis". I analysed the principles on which at
    least one authority seemed to base its regulatory stance, and pointed out
    that they were very different from a technical risk analysis.  For example,
    the UK regulators based their official position on the fact that mobile
    phones are RF devices, and there were regulations governing use of RF
    devices in the presence of flammable substance, although a correspondent at
    HSE suggested that the possibility of external short circuits, caused say
    when someone drops a phone while using it, would be a natural concern (I
    pointed out that this was precluded by the physical design of phones that I
    had looked at).
    
    There is a postscript. My sister reported to me in 2002 that local gas
    stations put up notices saying that due to then-recent incidents of phone
    use setting off fires, mobile phone use was "not permitted". She asked the
    station attendant, and got no precise information. I inquired at the UK
    Health and Safety Executive, and Simon Brown told me that the more recent
    reports had been investigated and HSE had concluded that there was no
    substance to them.
    
    Then, end of 2003, there were reports of "exploding" mobile phones. The New
    Scientist was interested (although I do not know what if anything they
    published). Nokia had issued a statement about it, in which they said that
    some third-party replacement batteries had been shown to be defective. I saw
    a German public television program about it. It interviewed a man to whom it
    had happened (as his car was passing under the mail Amsterdam-Köln train
    line at Dinslaken), showed pictures of his phone, showed his hospital
    admittance record (his arm/hand was mildly burnt), interviewed labs who had
    investigated such incidents, and showed lab technicians provoking such an
    explosion. Pretty substantial stuff, no legend. It can happen.
    
    Apparently, some third-party replacement battery providers do not have
    adequate quality control and the short circuit protection mechanisms
    on the batteries they sell may be as ineffective as the batteries are
    defective. A battery which internally short-circuits can explode in
    exactly this way. The program explicitly recommended not using
    inexpensive batteries from manufacturers/suppliers that were not well-known
    (I recall it stopped short of advising people only to use original
    equipment, although some interviewees recommended that.)
    
    Of course, this may happen irrespective of whether the phone is in use, or
    even of whether it is switched on, although I imagine both situations raise
    the chances that a defective battery will internally short-circuit.  So it
    may well be that there are now good grounds for the adage "don't use your
    phone on gas station forecourts", but based on the possibility of internal
    shorts, rather than on their status as RF devices, or on the possibility of
    external shorts. And better to keep it away from the fumes altogether; not
    in your pocket or handbag, but in the car with the windows shut. If you have
    a non-original battery, that is.
    
    A colleague pointed out that car batteries are in principle susceptible to
    the same process, and there are plenty of inexpensive car batteries around,
    but no one is recommending or requiring that drivers remove or disconnect
    their car batteries before driving on to a forecourt. Of course, if they
    did, they couldn't......
    
    Peter B. Ladkin, Professor of Computer Networks and Distributed Systems,
    Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany
    
    ------------------------------
    
    Date: Thu, 19 Feb 2004 10:06:24 -0500
    From: Steve Bellovin <smb@private>
    Subject: Re: Garage-door openers by Sputnik (RISKS-23.19)
    
    I flat-out don't believe the sputnik connection -- the signal strength from
    orbit would have been extremely low.
    
    I haven't been able to find hard numbers, but here are some back of the 
    (SMTP?) envelope calculations.
    
    Sputnik's perigee was 215 km (sources given below).  Assume that a garage
    door opener's range is 21.5 m; if the satellite has comparable transmission
    efficiency and power and an (assumed) inverse square signal drop-off, we're
    dealing with a 10^-8 difference in power.
    
    Of course, Sputnik's transmitter was more powerful.  I haven't been able to
    find any data on that, but we can bound it.  Sputnik massed 83 kg.  Assume
    that its entire mass was batteries -- clearly, that's an overestimate -- and
    assume that a vintage 1957 garage door transmitter had 83 grams of battery
    (probably too low).  That gives a 10^3 improvement in maximum transmitter
    power.  We can be very generous and assume a 10^2 factor for better
    batteries, better transmitters, etc., but we're still left with a signal
    strength deficit of 10^3.  Sure, Sputnik had better antennas than the garage
    door opener, but the receiving antennas are constant.  I don't see how this
    adds up.
    
    I should add that battery weight and power capacity was a major concern for
    the designers; furthermore, the antennas were omnidirectional.
    
    I may be off-base here, and I'll let people with more knowledge of radio
    calculate further -- but to me, this just doesn't add up.
    
    Sources:
    
    http://www.hq.nasa.gov/office/pao/History/sputnik/14.html
    http://www.hq.nasa.gov/office/pao/History/sputnik/russ3.html
    http://nssdc.gsfc.nasa.gov/database/MasterCatalog?sc=1957-001B
    http://nssdc.gsfc.nasa.gov/nmc/tmp/1957-001B-traj.html
    
    Steve Bellovin, http://www.research.att.com/~smb
    
    ------------------------------
    
    Date: Fri, 06 Feb 2004 14:41:23 +0000
    From: Adam Laurie <adam@private>
    Subject: Re: Drunk unlocks police car with own key
    
    I have had a couple of experiences with radio car remotes and have also
    recently been doing some research with older style IR remotes...
    
    Firstly, the radio remotes... on a recent business trip i got a call from my
    wife in which she described a situation when she got locked out of her car
    as the radio remote had stopped working. she could unlock the door with the
    physical key, but the remote had also disabled the ignition system so she
    could not start the car. she was at a shopping centre, it was early evening,
    getting dark, and she had 4 children (not all mine, i should point out! :)
    she had just picked up from school and was desperate to get home... when she
    called the garage they said it would take two hours to get out to
    her. clearly this was unacceptable in the circumstances, so they came up
    with another solution... the solution was to tell her the procedure for
    resetting the key. having reset the key, she then followed another procedure
    to resychronise the car. she did this and it all worked fine. when she
    described the procedure to me, it was clear that the process was completely
    insecure as it did not require physical access to the car (i.e. no ignition
    key or door key sequence was required). as it happened, a few days later, a
    friend was giving me a lift to the railway station and on the way he had to
    drop off a rental car. as we left it on the forecourt (it was late and the
    place was closed), i noticed he was using an identical remote to the one for
    my wife's car. i had mine with me so we decided to experiment... and yes,
    you are probably way ahead of me here... after performing the sequence, a
    dozen or so cars on the forecourt happily chunked their locks open and
    flashed their indicators to show that they had been reset! it would appear
    that sending a 'base' code from a freshly reset key caused the receivers on
    the cars to also reset and synchronise to my key. i didn't try starting any
    of them, as ThatWouldBeBad(tm), but being able to open the doors is risky
    enough.
    
    This caused me to wonder just how simple those codes were, and how hard they
    would be to brute force. not being an electronics/radio whizz, i was
    slightly stumped on how to intercept and analyse the signals, so i decided
    to first have a go at something simpler, for which such tools already
    existed, and which i suspect uses similar underlying protocols - i.e. infra
    red. the tool i used was LIRC (http://www.lirc.org/), which includes a nice
    graphical utility to show you the 'shape' of the signal.  zapping it with my
    garage door opener showed that they were using an 8 bit code (plus stop bits
    etc.), and the particular code for my garage door was 0xE3. lirc also has a
    learn facility, which produces config files in human readable form. the
    config for my learned remote looked like this:
    
       begin codes
    
            E3	0x00000000000000e3
    
    it was then a simple task to write a script which spat out the other 255 
    possible codes:
    
            00       0x0000000000000000
            01       0x0000000000000001
            02       0x0000000000000002
            etc.
    
    and another simple script to send every possible code. running the script
    successfully popped the garage door not only when it hit the expected 'e3'
    code, but also on another one (apparently the garage operators had installed
    a second parallel system as they could no longer get spare remotes for the
    old one). total time to try every code was under a minute.
    
    i have since used the same technique to discover 'hidden' menus on TVs
    (particularly useful in hotels with pay per view :), and suspect that there
    are lots of other similar applications out there waiting to be discovered...
    
    the risk here is that because the code is 'invisible' there is a tendency to
    make it simple. i have seen the same mistake in network connected security
    devices such as proximity card readers for door controls - the card itself
    is secure, but the command that ultimately gets sent over the wire to the
    locking mechanism is a simple ascii string, such as "O" for open.
    
    btw, if anyone has any ideas how i could convert the radio remote 
    signals to something i could analyse/replicate, please get in touch... i 
    have scanners/transceivers etc., but am completely clueless when it 
    comes to non digital stuff... :P
    
    Adam Laurie, A.L. Digital Ltd., The Stores, 2 Bath Road, London W4 1LT  UK
    +44 (20) 8742 0755  http://www.thebunker.net  http://www.aldigital.co.uk
    
    ------------------------------
    
    Date: 28 Jan 2004 (LAST-MODIFIED)
    From: RISKS-request@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-request@private> with one-line body
       subscribe [OR unsubscribe]
     which requires your ANSWERing confirmation to majordomo@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.Marshall@private>.
    => SPAM challenge-responses will not be honored.  Instead, use an alternative
     address from which you NEVER send mail!
    => The INFO file (submissions, default disclaimers, archive sites,
     copyright policy, PRIVACY digests, etc.) is also obtainable from
       http://www.CSL.sri.com/risksinfo.html
     The full info file may appear now and then in future issues.  *** All
     contributors are assumed to have read the full info file for guidelines. ***
    => SUBMISSIONS: to risks@private with meaningful SUBJECT: line.
     *** NEW: Including the string "notsp" at the beginning or end of the subject
     *** line will be very helpful in separating real contributions from spam.
     *** This attention-string may change, so watch this space now and then.
    => ARCHIVES: ftp://ftp.sri.com/risks [subdirectory i for earlier volume i]
     http://www.risks.org redirects you to the Lindsay Marshall's Newcastle archive
     http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue]
       Lindsay 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/ .
    ==> 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 23.20
    ************************
    



    This archive was generated by hypermail 2b30 : Wed Feb 25 2004 - 19:24:43 PST