Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
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]
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
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
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]
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
>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
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
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
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
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.
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.
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
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 *
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.
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
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
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]
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, 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.
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