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…
Today was apparently a bad day for spamming spoofs at the White Hoise. There are reports of huge quantities of e-mail being sent to various addresses at WhiteHouse.gov with header fields such as > Subject: You are now subscribed to the RISKS list and evidently many other lists. I received at least 10 autoresponder replies from whitehouse.gov with the subject field > Subject: Re: You are now subscribed to the RISKS list The beleaguered mail server at WhiteHouse.gov has evidently been spewing out automatic standard responses to each mailing, with the return address coming back to the LISTSERV. There is now a subscription at UBVM for the Vice President that was not there the last time I reviewed the list (which coincidentally happened to be yesterday!). This is a very ugly situation, and clearly will cause the whitehouse site much grief in trying to unsubscribe massively. Unfortunately, e-mail spoofing is still vastly too easy. All of the past cries in RISKS for a much more secure infrastructure bear repeating. And April Fools' day is only four weeks away, to make things worse — reminding us of all the more benign spoofs of past years. I hope this flurry of annoying activities does not prompt some hasty legislation trying to make spamming and spoofing illegal. If the Communications Decency Act (CDA) experience is followed, and if the California Computer Crime law is any guide (which in essence makes it illegal to read, write, alter, or delete information — rather broadly making *all* uses of computers potentially illegal), we could wind up with an unworkable definition of spamming and spoofing that includes sending e-mail to more than one person. Here is another argument for cleaning up the infrastructure. The WorldWide Information Infrastructure would come screeching to a halt otherwise (and that acronym would unfortunately be WW II). PGN
BerkshireNet in Pittsfield, Massachusetts, was the victim of an attack on 27 Feb 1996 in which someone planted swastikas and racist messages while masquerading as the provider's administrator, erased data on two computers, and then shut down the system. It was off the air for about 12 hours. Older deleted files were restored, but files created in the last several days were lost. [Source: *Palo Alto Daily News* (a relatively new local freebie paper that is off to a good start), 2 Mar 1996, p. 6]
Some people thought that our esteemed editor was incorrect (myself included) when he said: >However, I have spent so much time lately correcting folks who think >2000 is NOT a leap year... As one of the folks, I humbly submit the following... As I am currently writing some backup dependent routines that I expect will be here in the year 2000, I did some research, and found the following: An article in IBM system User International (Issue 19, Nov. 95), "...like many calendars, thinks there will be a February 29th in that year - there will not be." A Digital SPR (11-60903 13/10/93): "...a formula suggested by the Vatican librarian Aloysius Giglio was adopted. It said that every fourth year is a leap year except for century years that are not divisible by 400..." So we have two reports that believe 2000 is *not* a leap year. Further research was done and an Information Leaflet No. 48: 'Leap Years' by The Royal Greenwich Observatory advises that 2000 IS a leap year. (http://www.ast.cam.ac.uk/RGO/leaflets/leapyear/leapyear.html) [Furthermore, several folks e-mailed me today that they concluded from an NPR item that 2000 is *not* a leap year. PGN] As most readers would agree, the Royal Greenwich Observatory would have to be a leading authority on the subject. I'll take their information as gospel! The Risks: ...Assuming that long-held beliefs are always correct... ...That the first reference one looks at is necessarily the right one... Dale Robinson. [PGN says, check it out. The above website points out that the length of the tropical year is 365.24219 days. The algorithm I know and love that makes 2000 a leap year because it is divisible by 400 gives 365.2425 days in a year, an error of about three days in 10000 years. So, sooner or later we will need a further adjustment. I hope someone decides well in advance, to permit the programmers to get ready. If the hassle over 1/1/2000 is any indication, the leap-year corrections to provide the -.00031 day could also take a lot of expensive preparation, so we might as well start teaching our young programmers soon — just in case. Well, are you sick of leap-year problems? Sorry. Three more follow, plus a daylight-savings problem. PGN]
In the (UK) Times newspaper, 2 Mar 1996, an article appeared reporting a problem with laboratory equipment at Papwoth Hospital. This is one of the main centres for the research and conduct of heart transplants and surgery in the UK. It seems that analytical equipment needed to carry out specialist tasks to do with heart surgery were unable to function on the 29th of February. The manufacturers have admitted there is a problem within the code and stated that '...all their equipment would have the same problem.' Fortunately all patients were treated as scheduled - other labs at the hospital were able to carry out the required analysis with different manufacturers machines. David Alexander Camberley, England Dave_Alexander@online.rednet.co.uk
According to *The New York Times*, 1 March 1996, the NYC Taxi and Limousine commission made the mistake of choosing 1 Mar 1996 as the start date for a new, higher fare-structure for cabs. As if the usual rigged-meter problems weren't enough, meters programmed by one company in Queens forgot about the leap day and charged customers the higher rate on February 29. [Forgot, eh?] Mark Eckenwiler eck@panix.com
After reading RISKS-17.81, I checked data in a spreadsheet I was working on, and sure enough, a leapyear bug. Microsoft Excel 3.0, both the Mac and PC versions, has trouble with February 29th. Enter a date for the current year as 2/28 in a cell and it is converted to the format 2/28/1996. Enter 2/29 and you get 2/1/1929. I tried setting the system clock to 1992 and 1988 with the same results. Excel version 5.0 on the PC does work for 2/29. Note that by typing the full date, including year, as 2/29/96, and then choosing the desired format, you can get what you want. The risks? Relying on automated data formatting. Not upgrading to the latest versions of software (upgrading has another set of risks). And the risk of not reading comp.risks, otherwise I would not have caught this error. The year 2000 should be very interesting... ...Tom Dickens tpd6908@yak.ca.boeing.com
Over the weekend, Win95 erroneously took my system out of Sydney Daylight Saving. This should not happen until the end of March. A search of Win95 HELP provided absolutely no information about the parameters used to control such a behaviour. This raises the following questions. * What other "automatic" operations may be instigated without my knowledge? * What verification of the data for such operations has occurred? * Where can users of such systems get accurate documentation of the functionality of their operating systems? Steve Elliott, NORESE Pty. Ltd. 4, Glassop St. Balmain, NSW 2041 Australia selliott@world.net +61 (41) 12 608 12 Fax +61 (2) 555 7911
I just decided to check the balance on my current account using my bank's automated telephone banking service. I share a phone with several others, so to avoid arguments over the bill I decided to put the call on my British Telecom chargecard. Both the chargecard service and the phone banking service are operated by DTMF (tone dialing), however when I was connected to the bank and dialed ## code for "cancel operation", British Telecom disconnected the call and asked me if I would like to make another one. The risks here are: (a) To have seen me dial the ##, BT must have been monitoring the line for DTMF throughout the call. This means that they monitored my account number and PIN as I entered them into the banking system. (b) Anything I dial is ambiguous in this situation, unless I know *every* code BT understands during a call, and which ones it will act upon instead of passing them through to the called party. Ian Chard, back in Manchester ian@tanagra.demon.co.uk NTS: G7OMZ @ GB7VRB.#38.GBR.EU Phone: +44 161 434 6492
If you are running Netscape 2.0 on your system, and are at all concerned about security or privacy, you should run, not walk to this URL: http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html The World Wide Web Security FAQ Pay special attention to questions 69 through 71. Number 71 in particular discusses: * How a JavaScript page could grab a user's e-mail address from Netscape's preferences dialog and send it across the Internet. * A script that can open up a small window that continuously monitors the user's browsing activity, capture the URLs of open documents, and transmit them to a remote server. * A script that can obtain recursive directory listings of the user's local disk and any network disks that happen to be mounted. This information can be transmitted anywhere in the Internet. * How the version of JavaScript that was included with beta versions of Netscape 2.0 contained holes that allow the user's history and cache files (both of which contain lists of recently-visited URLs) to be captured. I have not seen any information on this before today, so I suspect that other Netscape users might want to know about these risks!
Researchers at Purdue University have discovered a flaw in the popular Kerberos computer-security system that affects the way Version 4 of the software creates the secret keys for encryption. The problem does not affect Version 5, unless it is run in a way that emulates Version 4. The software is supposed to select its keys randomly from among billions of numbers, but the problem occurs in the random-number generator, which is selecting from a much smaller pool of perhaps a million or so, making it much easier for an intruder to crack the key. "Basically, we can forge any key in a matter of seconds," says Purdue professor Eugene Spafford. The CERT Coordination Center at Carnegie Mellon University has issued an advisory on the problem — CA-96.03 — and recommends using "patches" to fix the flaw. < http://www.sei.cmu.edu/technology/cert.cc.html > (Chronicle of Higher Education, 1 Mar 1996, A29) Michael J. Chinni US Army ARDEC, Picatinny Arsenal, New Jersey MIL: mchinni@pica.army.mil UUCP: ...!uunet!pica.army.mil!mchinni [This is old news to some of us, but has not yet appeared in RISKS. PGN]
After all the difficulties Intel Corp. had in response to the discovery of a flaw in its Pentium chip [RISKS-16.57,58,59,61,62,63,64,66,67,81], the discovery of a flaw in the new Orion 82450 chipset has caused Intel to promise being much more open about disclosing this and other flaws. The Orion flaw was discussed by Intel on 29 Feb 1969. This chipset is an auxiliary for the Pentium pro; the flaw seriously affects I/O bus throughput: ``as low as five megabytes per second, instead of the regular 25 to 55 megabytes''. Intel was aware of the fault and told its primary customers, leaving it to them whether to tell the end users. ``Intel spokesman Howard High estimated 1 percent to 2 percent of all users would experience the poor performance though. High noted there was a big difference between the Orion fault and the earlier Pentium fault, saying the former was a performance issue that would not necessarily affect everyone's performance, while the latter related to data corruption that theoretically would affect every user.'' [Source: Intel Discloses Flaw in Orion Chipset, Reuter, 1 Mar 1996]
Well, well. Here we go again, eh? The Orion chipset has been widely touted in the trade press as the logical follow-up to Intel's extremely popular "Triton" PCI chipset, this time oriented toward the P6 (oops, "Pentium Pro"). It even included such old-time niceties as support for parity memory, which was left out of the Triton as an economy measure. (Hey, people can use the cheaper 8-bit memory! Who needs the extra bit?) Now we find that not only is Orion flawed, but Intel is even trying to put a new spin on their famous Pentium floating-point bug! Today's press releases on Orion seem to indicate that the problem most likely rests with PCI bus handling, possibly resulting in throughput decreases up to 90% compared with what might be otherwise expected. Intel feels this won't affect most users. We don't know exactly what that means at this point. Are they saying that the bug is so subtle that it comes up only rarely? The release seems to imply that all of the Orion chipsets shipped to date are capable of exhibiting the problem. Or are they suggesting that only those users whose applications depend on the full performance of the PCI bus will be affected? You know the type, those folks who went out and bought Pentium Pro PCI motherboards for high-speed graphics, digital audio and video, that sort of thing. The folks depending on the bus to work correctly so that their dandy PCI cards will perform up to spec. So, maybe Intel is actually saying that so long as your main applications are spreadsheets and word processing, or similar work that doesn't depend on PCI bus performance, you won't notice any problem, because you'll never stress the bus enough anyway. In either case, for Intel to know about this from day one, and to keep it effectively a secret between themselves and the motherboard manufacturers, is shameful. What's humorous about all this is the way Intel is now implying that the Orion bug isn't really a big problem, because they feel that only a few of the users will notice. But they then compare this with the floating-point bug, which they say had a (very small) chance of affecting anyone with the appropriate steppings of the chip. Is there some sort of doublespeak going on here? Isn't a major reduction in bandwidth, that can affect any user of the Orion chipset who needs significant bandwidth, at least as important as the floating-point bug, if not much more so? First, Intel comes out with a new processor chip (the P6) that turns out to execute the software that most people run more slowly than some of the chips that proceeded it. Now, the Orion problem. Intel's press releases today indicate that they're going to clean up their act when it comes to early disclosure of hardware problems. Let's hope it's true.
There is a serious security bug in the class loading code for the Java development kit and Netscape (all Java-enabled versions). If an attacker can arrange for two files (a "Loader" class, and a dynamic library) to be installed in any readable directory on the client machine, he/she can bypass all of Java's security restrictions. For example, the applet can read, write and execute files on the client, with the same permissions as the user of the browser. The only way to avoid this bug at the moment is to disable Java. In Netscape this can be done by selecting 'Disable Java' in the 'Security preferences...' section of the 'Options' menu. This bug affects all Java implementations based on Sun's source code. It is not related to JavaScript. Further details will be posted when Sun and Netscape have released patches. David Hopwood david.hopwood@lmh.ox.ac.uk
Unfortunately my news server has been off-line for the past few days. However, I'll try to address some of the questions that were raised on strong-java@entmp.org and in private mail about the recently-discovered bug in Java's class loading code. The same questions have probably been asked on RISKS and/or comp.lang.java as well. Apparently I wasn't clear enough in stating that this bug allows classfiles to be loaded from _any_ directory on the client machine, not simply those on the CLASSPATH or LD_LIBRARY_PATH. This includes, for example, /tmp, ~ftp/incoming, or an attacker's home directory if he/she has an account on the same system. The attack requires two support files on the client's system: a classfile and a dynamic library. Both files must be readable by the browser, and the dynamic library must be executable (this is always true for systems that have no file permissions). The path to the classfile from the client's root directory must be known by the attacker in advance. Code demonstrating the bug has been written and tested on Linux and Digital Unix (OSF/1). It should be portable to all POSIX systems, and with a little work, to any system that supports Java. The demonstration is very easy to extend - hiding it within any applet would require adding only two extra lines of code. Changing the C code to execute any command would be a single-line change. For that reason, the code will not be described in detail or released publically until patches are available for both Netscape 2.0 and the Java Development Kit. David Hopwood david.hopwood@lmh.ox.ac.uk
In more than ten years of computing I've been hit by a virus only once. Early on New Years Day 1988 I awoke, logged on to my favourite BBS (Alice's Restaurant, Branford, Ct. USA) and happened upon what appeared to be the then latest update to Phil Katz's Arc program (now known as PKZip). I downloaded it and ran the supposedly self-extracting file. Boom. No hard drive. All files deleted. Fortunately I'd done a backup a couple of days earlier so lost only a couple of day's work. It appears that virus is back, as detailed in the following forwarded message: > Date: Tue, 27 Feb 1996 02:04:11 -0800 > Subject: Virus Alert** Do not download PKZ300.exe! > From: Mike Hammoud <mhammoud@ci.tacoma.wa.us> > To All of the NETTERS, from our computer support center at the City of > Tacoma: There is an alert about a virus is being distributed on the I-Net, > as a bogus PKZIP file. It has a potential to destroy all of your data on > your hard drive. The virus may be named PKZ300b.zip or PKZ300.exe. Do not > download it, or execute it, and pass the word. > FYI: The latest version of pkzip is 2.04g and the file should be PKZ204g.zip. > Mike Hammoud mhammoud@ci.tacoma.wa.us > Computer Support Tacoma Public Utilities [This item also noted by kegill@halcyon.com (Kathy E. Gill). PGN]
My laser printer (an Apple Personal LaserWriter) is placed conveniently on top of a 4 drawer filing cabinet. Recently it ran out of paper, & when I went to refill it, I pulled the paper cassette out a little too energetically, losing my grip on it. As the paper cassette fell, I made a grab for it, not realising that the large steel plate in the floor of the cassette (used for lifting paper up ready for printing) had separated from the plastic tray. The falling steel plate neatly sliced a small piece of flesh from a point near the knuckle of the middle finger of my left hand, & several drops of blood fell on the cassette before I realised what had happened & wrapped a paper tissue round my finger to stop the flow. The steel plate that had popped out so easily was almost impossible to put back in place, but I eventually managed it by distorting the plastic tray using the strength still remaining in my unmutilated hand. Readers will be pleased to know that though the cassette's function was unimpaired, the cassette tray suffered rather more than my finger & lost a sizable piece of plastic from one corner. The steel plate was unscathed. This episode highlights a number of computer-related risks :- 1. Falling computer equipment can be dangerous, both to itself & to people 2. The risks from falling computer equipment usually increase with the height from which it falls 3. People should not try to catch bits of computer equipment when they fall. 4. If you do try to catch falling computer equipment :- - beware of large bits of steel with sharp edges flying out - be thankful that the equipment will usually come off worse than you do Presumably, moving all computer equipment to floor level would reduce the risks from falling computer equipment, but increase other types of risk (e.g. tripping over computers, eye-strain). Ross Anderson J R A Consulting ross@jrac.demon.co.uk (01494) 437030 Fax: (01494) 537346 <http://www.demon.co.uk/jrac/>
In a posting to the Cypherpunks mailing list, Julian Assange (proff@suburbia.net) announced a mailing list to discuss legal aspects of computer crime. Based on my reading of the announcement, it appears to have a UK (or at least English Common Law) focus, though I suspect that it is not limited to UK-specific issues. The announcement concludes: This list has been created in an attempt to mitigate the lack of tangible resources people involved with computer crime have at their disposal. It is hoped that by bringing together knowledgeable legal professionals together with para-legal personnel and informed lay persons that information and resources relevant to the difficult task of analyzing, presenting in court, formulating departmental or company policy or otherwise dealing with computer crime law and computer crimes may be shared and intelligent discussion and law reform stimulated. To subscribe, send mail to: lacc-request@suburbia.net with the body of: subscribe lacc Back issues are available from: ftp://suburbia.net/pub/mailinglists/lacc I haven't looked further but, judging from the well thought-out announcement (unfortunately too long for a complete posting to Risks), it should be of interest to many Risks readers. Martin Minow, minow@apple.com
jgrant@namsa.nato.int wrote: > I am not defending Microsoft's products in any way. I use them because I > have to and I don't care about which vendor's product is "better" as long as > the one I have allows me to get the job done effectively. I think another RISK is that in our eagerness to ridicule the largest software company in the world, we've forced perfectly sensible people like jgrant to put needless disclaimers in their discussion of computer products, for fear of being ridiculed themselves. Heaven forbid that an end-user should defend Microsoft's products! Rick Russell // rickr@is.rice.edu //
Jot Powers' "Arizona lottery blottery on 29 Jan 1996" had >Machines refuse to recognize 29 Feb 1997 (*Arizona Republic*, 1 Mar 1996) ^^^^ PGN's leap-year item had 1956/1900/1940 instead of 1856/1900/1940. ^^^^ Both were obvious typos, and have been fixed in the archive copy to avoid further confusion.
Please report problems with the web pages to the maintainer