precedence: bulk
Subject: RISKS DIGEST 19.24
RISKS-LIST: Risks-Forum Digest Wednesday 16 July 1997 Volume 19 : Issue 24
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. *****
Contents: [BIG BACKLOG. Please be patient.]
Errors in California's Megan's Law sex offender CD ROM (Karen Coyle)
Website on Spreadsheet Research (Ray Panko)
"*sex" County sites blocked (Frank Carey)
Jon-Benet Ramsay case "hackers" unmasked: dead battery (Bear R Giles)
Credit-card numbers stolen from the Web (Drew Dean)
Lewis satellite downlink jammed by car alarm (George Michaelson)
Aircraft and Passenger Electronics; FMS Nav Data (Peter B. Ladkin)
Mid-air collisions (Hal Lewis)
Faulty lavatory smoke detector lawsuit (Frank Carey)
High-technology toll road six months late in Ontario (George Swan)
"DA computer chief almost loses all to clever sabotage" (James H. Haynes)
Re: MD5 weakness and possible consequences (Bear R Giles)
DEC Alpha Bug?!? (Gregory F. March)
Manual compositing of reuters news on yahoo cocks up (George Michaelson)
Calendars (Andrew R Koenig)
Follow-up to backhoe attack on cable (Cliff Krieger)
Anti-spam technology (Simson L. Garfinkel)
List of known macro viruses (Klaus Brunnstein)
Web Security & Commerce, Garfinkel with Spafford (PGN)
7th USENIX Security Symposium, Call for Papers (Avi Rubin)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Wed, 02 Jul 1997 09:38:27 -0700
From: Karen Coyle <
[email protected]>
Subject: Errors in California's Megan's Law sex offender CD ROM
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
[email protected] 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]
------------------------------
Date: Tue, 8 Jul 1997 17:29:14 -1000
From: "Ray Panko" <
[email protected]>
Subject: Website on Spreadsheet Research
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
[email protected]
------------------------------
Date: Thu, 3 Jul 1997 10:17:35 -0400
From: "Carey, F E (Frank), NCSIO" <
[email protected]>
Subject: "*sex" County sites blocked
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
[email protected]
------------------------------
Date: Wed, 2 Jul 1997 15:40:17 -0600 (MDT)
From: Bear R Giles <
[email protected]>
Subject: Jon-Benet Ramsay case "hackers" unmasked: dead battery (RISKS-19.23)
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
[email protected]
[Also noted by Jonathan Corbet <
[email protected]>, who commented
"Anything can happen when you don't understand your hardware."
and by Laura Stinson <
[email protected]>, 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]
------------------------------
Date: Fri, 11 Jul 1997 16:31:11 -0700
From: Drew Dean <
[email protected]>
Subject: Credit-card numbers stolen from the Web
Over 2,300 customers of Websites ESPN 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
[Typo on ESPN fixed in archive copy. PGN]
------------------------------
Date: Fri, 4 Jul 1997 16:17:25 +1000 (EST)
From: George Michaelson <
[email protected]>
Subject: Lewis satellite downlink jammed by car alarm
>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
[email protected] +61 7 3834 9976 connect.com.au pty/ltd
------------------------------
Date: Sun, 13 Jul 1997 19:25:57 +0200
From: "Peter B. Ladkin" <
[email protected]>
Subject: Aircraft and Passenger Electronics; FMS Nav Data
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
------------------------------
Date: Tue, 01 Jul 1997 21:34:48 -0700
From: hal lewis <
[email protected]>
Subject: Mid-air collisions
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
------------------------------
Date: Thu, 3 Jul 1997 10:22:30 -0400
From: "Carey, F E (Frank), NCSIO" <
[email protected]>
Subject: Faulty lavatory smoke detector lawsuit
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
[email protected]
------------------------------
Date: Fri, 11 Jul 1997 16:04:35 -0400 (EDT)
From: George Swan 7547 <
[email protected]>
Subject: High-technology toll road six months late in Ontario
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.
------------------------------
Date: Tue, 8 Jul 1997 20:26:52 -0700
From: "James H. Haynes" <
[email protected]>
Subject: "DA computer chief almost loses all to clever sabotage"
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.
------------------------------
Date: Wed, 2 Jul 1997 18:20:22 -0600 (MDT)
From: Bear R Giles <
[email protected]>
Subject: Re: MD5 weakness and possible consequences (Leeming, RISKS-19.16)
In RISKS-19.16, Geoffrey Leeming <
[email protected]> 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
[email protected]
------------------------------
Date: Wed, 02 Jul 1997 15:14:24 -0400
From: "Gregory F. March" <
[email protected]>
Subject: DEC Alpha Bug?!?
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 *
[email protected] *
------------------------------
Date: Tue, 15 Jul 1997 12:19:46 +1000 (EST)
From: George Michaelson <
[email protected]>
Subject: Manual compositing of reuters news on yahoo cocks up
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.
------------------------------
Date: Tue, 15 Jul 1997 11:39:42 -0500
From:
[email protected] (Andrew R Koenig)
Subject: Calendars
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
[email protected]
------------------------------
Date: Thu, 3 Jul 1997 17:40:48 -0400
From: "Cliff Krieger" <
[email protected]>
Subject: Follow-up to backhoe attack on cable (O'Hearn, RISKS-19.23)
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
------------------------------
Date: Mon, 16 Jun 1997 08:49:05 -0800
From: "Simson L. Garfinkel" <
[email protected]>
Subject: Anti-spam technology
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]
------------------------------
Date: Thu, 10 Jul 1997 18:30:30 +0200
From: Klaus Brunnstein <
[email protected]>
Subject: List of known macro viruses
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.*
------------------------------
Date: Sat, 05 Jul 1997 16:28:43 -0400
From: "Peter G. Neumann" <
[email protected]>
Subject: Web Security & Commerce, Garfinkel with Spafford
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.
------------------------------
Date: Fri, 27 Jun 1997 10:34:02 -0400 (EDT)
From: Avi Rubin <
[email protected]>
Subject: 7th USENIX Security Symposium, Call for Papers (abridged for RISKS)
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
------------------------------
Date: 1 Apr 1997 (LAST-MODIFIED)
From:
[email protected]
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. Or use Bitnet LISTSERV. Alternatively,
(via majordomo) DIRECT REQUESTS to <
[email protected]> with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
INFO [for unabridged version of RISKS information]
=> The INFO file (submissions, default disclaimers, archive sites, .mil/.uk
subscribers, 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
[email protected] 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 18" for volume 18]
or
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue].
The ftp.sri.com site risks directory also contains the most recent
PostScript copy of PGN's comprehensive historical summary of one liners:
get illustrative.PS
------------------------------
End of RISKS-FORUM Digest 19.24
************************
