The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 19 Issue 24

Wednesday 16 July 1997

Contents

o Errors in California's Megan's Law sex offender CD ROM
Karen Coyle
o Website on Spreadsheet Research
Ray Panko
o "*sex" County sites blocked
Frank Carey
o Jon-Benet Ramsay case "hackers" unmasked: dead battery
Bear R Giles
o Credit-card numbers stolen from the Web
Drew Dean
o Lewis satellite downlink jammed by car alarm
George Michaelson
o Aircraft and Passenger Electronics; FMS Nav Data
Peter B. Ladkin
o Mid-air collisions
Hal Lewis
o Faulty lavatory smoke detector lawsuit
Frank Carey
o High-technology toll road six months late in Ontario
George Swan
o "DA computer chief almost loses all to clever sabotage"
James H. Haynes
o Re: MD5 weakness and possible consequences
Bear R Giles
o DEC Alpha Bug?!?
Gregory F. March
o Manual compositing of reuters news on yahoo cocks up
George Michaelson
o Calendars
Andrew R Koenig
o Follow-up to backhoe attack on cable
Cliff Krieger
o Anti-spam technology
Simson L. Garfinkel
o List of known macro viruses
Klaus Brunnstein
o Web Security & Commerce, Garfinkel with Spafford
PGN
o 7th USENIX Security Symposium, Call for Papers
Avi Rubin
o Info on RISKS (comp.risks)

Errors in California's Megan's Law sex offender CD ROM

Karen Coyle <kec@dla.ucop.edu>
Wed, 02 Jul 1997 09:38:27 -0700
California issued a CD ROM to city and county police departments this week
that lists all registered "serious" sex offenders. The CD ROM is available
to the public at those departments, where they can look up sex offenders by
description, zip code, or other characteristics. However, like many
databases, this one has a few problems, as stated in the article in the San
Francisco Examiner, 2 Jul 1997:

Much of the information about San Francisco's high-risk offenders is out of
date.  ... "I'm sure that we have lots of people who are dead or have moved
away or are incarcerated," said Lt. Tom Bruton of the San Francisco Police
department.  ...  California Attorney General Dan Lungren has acknowledged
that the CD-ROM contains outdated or incomplete information on thousands of
the sex offenders.  About 40 percent of the state's convicted offenders have
not registered, he said. "

Karen Coyle University of California Library Automation
kec@dla.ucop.edu  http://www.dla.ucop.edu/~kec

  [The *San Francisco Chronicle*, 16 Jul 1997, Peninsula Edition, A13,
  has an article by Charlie Goodyear, in which Lungren acknowledges that 60
  to 65 percent of the address and ZIP information is incorrect.  Immediately
  after the CD-ROM was released on 1 July, they realized that juvenile
  records of four offenders had been included; new databases were
  created and mailed out.  Another revision is now being prepared.
  Incidentally, the existence of the database is driving some offenders
  underground.  PGN]


Website on Spreadsheet Research

"Ray Panko" <panko@busadm.cba.hawaii.edu>
Tue, 8 Jul 1997 17:29:14 -1000
In recent years, there has been a considerable amount of research on
spreadsheets, including error rates.  The Spreadsheet Research (SSR) website
summarizes data from field audits of more than 300 operational spreadsheets
and from experiments involving almost a thousand subjects ranging from
spreadsheet novices to long-time spreadsheet professionals.  The results are
pretty chilling.  Every study that has tried to measure spreadsheet error
rates has found them and has found them at levels that are deeply
disturbing.  The URL is:
  http://www.cba.hawaii.edu/panko/ssr/

Prof. Raymond R. Panko, College of Business Administration, Univ. of Hawaii
2404 Maile Way, Honolulu, HI 96822  (808) 956-5049  Panko@hawaii.edu


"*sex" County sites blocked

"Carey, F E (Frank), NCSIO" <fcarey@att.com>
Thu, 3 Jul 1997 10:17:35 -0400
Three New Jersey counties have found that information they put up on the
Internet is being blocked.  The Newark (NJ) Star Ledger reports that
screening tools (they specifically mention the AOL tool) block access to the
Sussex County Fair, Middlesex County College, Essex County College, and the
Essex County Clerk's office.  It should be obvious what's going on.  The
string "sex" triggers blocking of these sites.  A spokesman for Net Nanny
reportedly said that most problems occur when parents rely on the broadest
keywords possible, adding that "...some people don't read the manuals."

Frank Carey  f.e.carey@att.com


Jon-Benet Ramsay case "hackers" unmasked: dead battery (RISKS-19.23)

Bear R Giles <bear@indra.com>
Wed, 2 Jul 1997 15:40:17 -0600 (MDT)
The _Rocky Mountain News_ had an article on 28 Jun 1997 on the unmasking of
the "hacker" who invaded the high-security "war room" established by the
local Keystones and DA.

After fingerprinting the exterior and interior of the computers, our own
Inspector Clouseau ruled out the unusually severe weather we had that
weekend.  Sitting on the edge of tornado alley (and _in_ it, recently), we
can have extremely severe weather that causes power glitches, and three
other county computers were affected that weekend.

No, after exhaustive and undisclosed tests the CBI determined that the
computer suffered from... a dead CMOS battery.  The newspaper article
implied that the police actually had the audacity to name the battery as the
_culprit_ in the case, but I refuse to believe that they've extended the
Meese Doctrine (that suspects, by definition, are guilty) to inanimate
objects.  Then again, that would allow them to arrest the garrotte and
declare the case closed.

The strange twist (as if this case could get any stranger) is that the
police yelling "hacker, hacker!" may have encouraged someone to break
into the social services computer where data on JonBenet's brother is
stored.  The second case is still under investigation.

Bear Giles bear@indra.com

  [Also noted by Jonathan Corbet <corbet@atd.ucar.edu>, who commented
    "Anything can happen when you don't understand your hardware."
  and by Laura Stinson <lstinson@empathy.com>, who noted that
    "Excessive paranoia about hackers and inadequate paranoia about
    systems/hardware failure seems to be the hallmark of most bureaucratic
    organizations, and often leads to hasty--and inaccurate--causal
    judgements."
  PGN]


Credit-card numbers stolen from the Web

Drew Dean <ddean@boron.csl.sri.com>
Fri, 11 Jul 1997 16:31:11 -0700
Over 2,300 customers of Websites EPSN Sportszone and NBA.com [offspring of
Starwave] received anonymous e-mail that their credit card numbers had been
stolen.  Each message said, "You are the victim of a careless abuse of
privacy and security.  This is one of the worst implementations of security
we've seen."  -- indicating that the message was from ``an anonymous
organization seeking to make the Internet a safe place for the consumer to
do business,'' -- and included the last 8 digits of the recipient's
credit-card number.  However, no fraudulent misuse had been reported.
[Source: Web Customers Get Warning on Security, *San Francisco Chronicle*,
11 Jul 1997, C3, datelined Bellevue, WA via Associated Press.  PGN
Abstracting]

I don't know anything else, but I'll conjecture that the problem is not
related to cryptography.  Anyone want to take a bet on a bad CGI program?
Unfortunately, too many people, including the marketing departments of
Internet software vendors, tend to confuse cryptography with security.
Firewalls are of limited help as we make more and more things work on top of
HTTP, which we then allow to pass through the firewall.  Of course, really
fixing things would cost real money, and take real time, which no one has.
The problem with computers isn't that they allow new kinds of fraud (a
burglar could just as well go through an old-fashioned file cabinet), but
that the fraud can happen on a much larger scale, and much quicker.

Drew Dean


Lewis satellite downlink jammed by car alarm

George Michaelson <ggm@connect.com.au>
Fri, 4 Jul 1997 16:17:25 +1000 (EST)
>From Henry Spencer's *AVWeek&Space* digest on USENET

  Space news from April 21 *AW&ST*:
  Strong signal jamming the S-band downlink at the new control center
  for the Lewis satellite traced to faulty car alarm (!).

I liked the imagery, young dude rips off the Camaro, WHAM, suddenly half of
the narrowcasting for New Jersey dies...

George Michaelson, AAPT, 123 Eagle St, Brisbane QLD 4000
ggm@connect.com.au  +61 7 3834 9976  connect.com.au pty/ltd


Aircraft and Passenger Electronics; FMS Nav Data

"Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de>
Sun, 13 Jul 1997 19:25:57 +0200
There has been some further discussion recently amongst aviation
professionals on possible electromagnetic interference with aircraft systems
from passenger electronics [PGN, RISKS-18.47; Ladkin, RISKS-19.48
]. Concerned RISKS readers might like to read two recent surveys on the
possible phenomenon:
Albert Helfrick's article, `Avionics and Portable Electronics:
Trouble in the Air?', originally published in Avionics News Magazine
and available under the Bluecoat Public Reports list at
 http://bluecoat.eurocontrol.fr under URL
 http://bluecoat.eurocontrol.fr/reports/Helfrick_96_PED.pdf
(Acrobat PDF format, 453K); and a short article I wrote,
`Electromagnetic Interference with Aircraft Systems: why worry?'
(HTML, 46K), available through my compendium, `Computer-Related
Incidents with Commercial Aircraft', section `Do Passenger Electronics
Interfere with Aircraft Systems?' at http://www.rvs.uni-bielefeld.de

The final report on the Cali accident (Ladkin, RISKS-18.10) cited as one of
four `contributing factors' to the accident that the Flight Management
System navigational information used a different naming convention from that
published in (paper) charts. Recommendations 1 and 7 (of 17) to the FAA
address the navigation-database issue, as does Recommendation 3 (of 3) to
the International Civil Aviation Organization: `3. Establish a single
standard worldwide that provides an [sic] unified criteria for the providers
of electronic navigational databases used in Flight Management Systems.'
Shawn Coyle of Transport Canada, Safety and Security, has written a working
paper in which he identifies a serious problem arising from the lack of
standards for industry use in flight management systems of authoritative
navigational data. Coyle's paper gives eight examples of circumstances in
which there is incompatibility between an FMS's use of navigational data for
an approach, and the regulation approach profile itself.  Coyle's paper,
Aircraft On-Board Navigation Data Integrity - A Serious Problem, is also
available on the Bluecoat Public Reports list at URL
http://bluecoat.eurocontrol.fr/reports/Coyle_97_Nav_Database.pdf (Acrobat
PDF format, 453K).

Peter Ladkin


Mid-air collisions

hal lewis <hlewis@physics.ucsb.edu>
Tue, 01 Jul 1997 21:34:48 -0700
I posted something on this forum in RISKS-19.11 to the effect that the
current air-traffic-control system is illogical, and increases the incidence
of mid-air collisions by constricting the available airspace to that which
can be easily controlled. In return, I got a moderate level of flame mail,
whose common denominator, some making the point with more vigor and ill will
than others, was that I was unfair to the FAA. (Some did point out that the
FAA is moving in the direction of free flight, but my fifty years of
watching the FAA and its predecessor have prevented me from holding my
breath.)

The current issue of Risk Analysis (April 1997) contains an article by
someone who has done a Monte Carlo analysis on the mid-air collision
question, and has concluded that the present system increases the collision
probability by a factor of four, over random flying. I have not studied the
paper, and therefore can't vouch for the methodology, but it is there for
those seriously interested in the question.

Hal Lewis


Faulty lavatory smoke detector lawsuit

"Carey, F E (Frank), NCSIO" <fcarey@att.com>
Thu, 3 Jul 1997 10:22:30 -0400
The news on 3 Jul 1997 included an account of an Air France cabin attendant
who dragged a passenger out of the plane's lavatory with his pants down and,
in front of all the passengers, accused him of smoking in the lavatory.  The
passenger protested that he does not smoke and is responding with a
multi-million dollar law suit.  A faulty smoke detector is assumed.

Frank Carey  f.e.carey@att.com


High-technology toll road six months late in Ontario

George Swan 7547 <gswan@globalserve.net>
Fri, 11 Jul 1997 16:04:35 -0400 (EDT)
There is a column in the *Globe and Mail*, 11 Jul 1997, about a new highway
completed across the north of Toronto Ontario.  Toll roads were unknown here
in Ontario.  Private industry was invited to tender proposals.  The
provincial government specified a system for collecting the tolls that would
obviate the need for cars to stop to make payments.  Frequent travellers
would rent a transponder for $2 C per month.  Occasional travellers who
don't have a transponder would pay a $1 C surcharge per trip in addition to
the regular distance fee.  Their travel would be tracked by digital cameras
that would snap pictures of their license plates.  Travellers would get a
bill in the mail.

Terence Corcoran's article says the toll system has been promised
to have been a few weeks away from readiness for six months.  So
far it has cost twice as much to develop as estimated.

Currently travellers are using the road for free.

The message for RISKS readers?  Just another demon child borne from
the courtship of boastful hype and wishful thinking.


"DA computer chief almost loses all to clever sabotage"

"James H. Haynes" <haynes@cats.ucsc.edu>
Tue, 8 Jul 1997 20:26:52 -0700
I'm reading this Associated Press story datelined San Francisco in a paper
published in Arkansas.  Says Ralph Minow who runs a family support computer
system for San Mateo County District Attorney.  System crashed in March
1996.  Says his assistant Paul Schmidt wanted his job, rigged the evidence
to show that Minow deliberately caused the crash.  Minow nearly lost his job
because of the sabotage; but the perpetrator made enough mistakes that he
was detected.  Says Schmidt was fired in February, and will be prosecuted if
his firing is upheld after a final hearing.  His lawyer says Schmidt is
being prosecuted for whistle-blowing.


Re: MD5 weakness and possible consequences (Leeming, RISKS-19.16)

Bear R Giles <bear@indra.com>
Wed, 2 Jul 1997 18:20:22 -0600 (MDT)
In RISKS-19.16, Geoffrey Leeming <geoffrey@jcp.co.uk> suggests that it would
be computationally difficult to find two meaningful pieces of executable
code with the same checksum.

I disagree, and refer to an old hack as a demonstration of a well-known
example.  In a more innocent age if you wanted to protect a database against
casual alteration (e.g., by buggy programs which directly accessed the data),
you would compute a checksum across the entire database.  That's a cheap
test for non-malicious alteration, but it's too expensive to continually
recompute a CRC checksum across a large file.

The solution was to reserve two bytes (for a 16-bit CRC) in each record.
When the CRC of the entire database is computed this field was set to zero.
When a record was edited, the original CRC of the block was computed, then
this field was set to the value which forced the CRC for the entire record
to remain unchanged.  Since the CRC for the block was unchanged, the CRC for
the entire file also remained unchanged.

(A variant method initialized the field so each record had a known,
identical checksum.  Then all changes maintained the checksum as an
invariant.)

This is why standard CRCs aren't good in cryptographic applications.  If
you can write any data to 16 contiguous bits (or restricted data to a
somewhat larger block) you can force the CRC to be any value desired.

The 128-bit MD5 hash will obviously require more than 2 bytes... but it
shouldn't be too hard to find ways of squirreling small chunks of rewritable
data throughout the data.  The most obvious approach is

  static char md5hack[16];

Or you could just use "sloppy" coding practice:

  static char stealthhack[200] = "hello, world";

You could even sneak the buffer into the code segment:

  foo ();
  goto hackaround:

  /* code is irrelevant, it just takes up space in code segment
     which will be overwritten later */
  for (i = 0; i < 10; i++)
     j = i;

hackaround:
  bar();

This then becomes a matter of determining an _efficient_ way to set the
value of the MD5 (or any) hash function to a desired value.  The brute force
method (allocate a buffer and write every possible value to it, computing
the hash function) is impractical when there are 2^128 to 2^160 possible
hash values.  But if, for example, you could reduce the problem to 4
problems with 2^32 possible hash values in each...

Of course a careful examination of executables or documents will show
dead spots or "weird" comments, but who would have the time to run such
exhaustive tests on a substantial application or document?

Bear Giles  bear@indra.com


DEC Alpha Bug?!?

"Gregory F. March" <march@BondNet.COM>
Wed, 02 Jul 1997 15:14:24 -0400
So there I am, looking at our trading system and noticing that the price of
one particular bond was different on two separate machines.  Damn, I think.
Must be a bug in the latest release of our software.  Quick, do a sum on all
the libraries.  Nope, they are the same.  Executable?  Nope, the same.
Hmm...  Step through the code, hey, look at that!  The pow() function is
returning different results!

So, I wrote a stand alone program.  Sure enough, the machine with the
latest rev motherboard (one that was just replaced by DEC) is
producing bad numbers.  Time to try 'dxcalc', DEX's X calculator.
Yup. different numbers.  How about perl?  Yup, different numbers.  How
about 'bc'?  Duh, bc doesn't take floating point powers.  Hmm... check
libm.  Nope, they are the same.

Bottom line:  DEC will be here shortly.

Test your alpha.  Try 'pow(1.234567, 7.654321)'.  If you don't get
5.017something, you have the same problem.

Risks?  In our case, could have been a large sum of money.

* Gregory F. March * http://www.gfm.net * march@gfm.net *


Manual compositing of reuters news on yahoo cocks up

George Michaelson <ggm@connect.com.au>
Tue, 15 Jul 1997 12:19:46 +1000 (EST)
I track 3 or 4 of the summary pages on http://www.yahoo.com/headlines/ --
which are reworked reuters news info.  Several times now, the link and
related 1-para summary has hotlinked to completely unrelated stories.  Or
are they?  The last one was a headline on the MIR commander having a heart
attack and it linked to a story on Yeltsins sex-life.

Just thinking about that one nearly gave *me* palpitations.

I suspect that the process is (a) manual (b) mindlessly boring and (c) uses
some keyword recognition process, and the person-in-the-loop saw 'russia' in
both of them and got the link wrong.


Calendars

Andrew R Koenig <ark@attmail.com>
Tue, 15 Jul 1997 11:39:42 -0500
I was just browsing through the introductory pages of the pocket-sized
calendar book I use.  It has blanks for the following information:

    Name
    Address
    Telephone number (home and office)
    Fax number
    Religious affiliation
    Blood type
    Drug allergies
    Social security number
    Driver's license number
    Automobile registration number
    Insurance company
    Credit cards
    Next of kin

At the bottom of the page, it says

    In event of emergency, please notify ____________
    If this diary is found, please return to the owner.

Anyone who fills out all that other information had better not lose it...

Andrew Koenig  ark@research.att.com


Follow-up to backhoe attack on cable (O'Hearn, RISKS-19.23)

"Cliff Krieger" <CKrieger@drc.com>
Thu, 3 Jul 1997 17:40:48 -0400
In 1973, a similar event happened at Korat Royal Thai Air Force Base and
when the US tenant tried to switch to the backup communications cable they
found that a large section of it had been stolen some time in the past.

The solution was to launch an EC-130 Airborne Command and Control Aircraft
(ABCCC) and use it to maintain communications with higher headquarters.  The
extended risk is that those who do not learn from history are condemned to
repeat it.

C R Krieger


Anti-spam technology

"Simson L. Garfinkel" <simsong@vineyard.net>
Mon, 16 Jun 1997 08:49:05 -0800
A little more than a month ago, Vineyard.NET, my ISP, started blocking SMTP
connections from computers on the Internet that do not have valid reverse
DNS.  We did this an an anti-spam measure.  A few days after we brought up
the new system, spamming dropped dramatically --- more than 75%!

We decided to filter against sites that do not have valid reverse DNS
because a lot of spammers do not have valid reverse DNS.  But it also seems
that we have caught up in our filter some legitimate sites that do not have
their nameservers properly configured.  Below is a list of all of the sites.

Interestingly, there are some sites below which are obviously spamming sites
(wow.boundless.com, for example). But there are also a lot of legitimate
sites as well, like aw.com, www.fda.gov, newshost.nytimes.com.

I'm trying to contact the postmasters at these sites to get them to correct
their systems. So far, I have sent many messages to the folks at Dow Jones,
for instance.  Unfortunately, all of those messages have been ignored.

So I'm not really sure what to do.  I like the anti-spam filter. I don't
want to start building an exception list.  And it seems that as the Internet
gets larger and larger, more and more machines are improperly administered.

Perhaps it would be simpler to just block the known spammers.

www.fda.gov             150.148.6.1         29
BANYAN.SMTP.IHS.GOV     161.223.220.100    226
mailer.usatoday.com     167.8.29.60        229
portia.teleport.com     192.108.254.5       11
aw.com                  192.207.117.2       38
acc                     193.227.61.28       11
jupiter.netdepot.com    198.81.231.2        77
wow.boundless.com       199.171.140.20     288
newshost.nytimes.com    199.181.173.226    456
simon.switchboard.com   199.222.0.10        13
charon.valueweb.net     199.227.124.197     58
home.corecom.net        199.237.128.11      77
jupiter.internet-australia.com 203.24.127.2  2
vision.eri.harvard.edu  204.166.91.12       38
aramis.link7.lat.net    204.179.70.11      154
mail2.gp.k12.mi.us      204.39.34.7        154
www.jobson.com          204.5.4.10           2
www.jobson.com          204.5.5.104         33
hermes                  204.77.214.122      10
mail-lax-3.pilot.net    205.139.40.17      143
deptvamc2-bh.va.gov     205.183.31.66      238
ns.sprintout.com        205.219.168.10      76
cordoba.shoppingplanet.com 205.254.167.153   1
easyaccess.ieaccess.net 206.112.36.11       39
ns1.digitaldelights.com 206.117.108.254     98
maui.net                206.154.205.1       41
apstech.com             206.242.178.253      1
mailserver.ccipr.com    206.40.70.7         39
netsys.hn               206.48.255.1        77
smtpmail.resortnet.com  206.99.110.1        38
smtp.autobytel.com      207.113.145.22      77
internetmedia.com       207.120.43.133      77
smarti2.smartworld.net  207.121.91.100      18
www.angelfire.com       207.226.241.14      38
mail.macline.net        207.230.18.26       21
WELCOME                 207.88.168.5       153
shani.marathon4com.net  208.12.112.31        2
pixelhype.com           208.150.36.215       1
[208.153.0.4]           208.153.0.4          3
nwnet.newsweek.com      208.194.106.7       38
firewall                208.198.116.12      10
listserv.dowjones.com   208.198.167.29     220
t-1net.com              208.21.213.10       34
demie.netsense.net      208.5.234.3         39
lamprey.internetmedia.net 209.25.82.66      30
ns.ultimatew.com        209.36.206.66       38
tripod.com              38.217.84.3         31
wopia.wo.erim.org       38.250.219.10      117

  [Incidentally, CSL.sri.com is now filtering out e-mail from sites from
  which we have been receiving inordinate numbers of spams.  This may have
  some unfortunate consequences, such as RISKS not being able to receive
  mail from some of you whose ISPs have been deemed less than helpful.
  Sorry!  The situation is really out of hand.  I'm getting hundreds of spam
  messages.  PGN]


List of known macro viruses

Klaus Brunnstein <brunnstein@rz.informatik.uni-hamburg.d400.de>
Thu, 10 Jul 1997 18:30:30 +0200
SUMMARY: Macro Virus List (PC + Macintosh) according to VTC
name specification, including (PC) In-The-Wild Indication
  Vesselin Bontchev @ FSI
  Klaus Brunnstein, Uni-Hamburg
  Joern Dierks, VTC Uni-Hamburg
  Thomas Buck, VTC Uni-Hamburg
  VTC = Virus Test Center, Status: June 30, 1997
<>> Copyright (c) 1997 University of Hamburg, Germany <<<

The number of known macro viruses in June 1997 grew again significantly:
with 18 new strains 132 new viruses, growth was significantly reduced as
compared to previous months (e.g. 37 new strains with 246 new viruses in
May). Only 22 months after Microsoft shipped the first Word macro virus
(Concept.A), the 1000th macro virus was reported around June 20, 1997.

Strains with fastest growth include Showoff (+15) as well NPAD and
CAP (+12) whereas growth of Wazzu (+5) and Concept (+3) is moderate.

The "list of known macro viruses", dated June 30, 1997, reports in
detail about all known macro-related malware. Here are the essential
statistical data:
                                   Word   +   Other  =  Total    (New)
        --------------------------------------------------------------
        Number of Strains           214   +      15  =    229    ( 18)
        Number of Viruses          1051   +      14  =   1065    (132)
        Number of Trojans            21   +       7  =     28    (  0)
        Number of Generators         10   +       0  =     10    (  0)
        Number of Intendeds          22   +       1  =     23    (  0)
        Number of Jokes               0   +       1  =      1    (  0)
        --------------------------------------------------------------
        Remarks: (*)=(viruses+trojans+intendeds+jokes)

  [list omitted for RISKS]

This list is published monthly (normally between the 3rd and 8th of a month)
and can be downloaded via FTP from VTCs "new" WWW/FTP site:
  ftp://agn-www.informatik.uni-hamburg.de/pub/texts/macro/

[Long and short] lists are also available from VTCs "old" ftp site:
   ftp.informatik.uni-hamburg.de/pub/virus/macro/macrolst.*


Web Security & Commerce, Garfinkel with Spafford

"Peter G. Neumann" <neumann@csl.sri.com>
Sat, 05 Jul 1997 16:28:43 -0400
  Web Security & Commerce, Simson Garfinkel with Gene Spafford
  O'Reilly & Associates, Inc., 1997, $32.95

This is a truly useful book that can help many of you avoid a lot of the
risks in Webware -- some of which have been discussed in RISKS, some of
which have not.  It is intelligently written, timely, informative, accurate,
comprehensive, understandable, and a great pleasure to read.  It becomes the
de facto definitive Web-ster's guide to Web security.


7th USENIX Security Symposium, Call for Papers (abridged for RISKS)

Avi Rubin <rubin@research.att.com>
Fri, 27 Jun 1997 10:34:02 -0400 (EDT)
26-29 January 1998, Marriott Hotel-- San Antonio, Texas
Program Chair, Avi Rubin, AT&T Labs - Research
Papers due 9 September 1997
Full version of CfP at http://www.usenix.org/sec/cfp.html

Please report problems with the web pages to the maintainer

Top