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…
As a result of a SMOP (small matter of programming) resulting from a few missing keystrokes that would have properly defined the recipient list, about 11,000 out of 13,000 of Chase Manhattan Corp.'s secured credit-card customers received a letter intended for just 89 customers — informing them that their accounts were in default and could not be converted to unsecured accounts. The screwup was blamed on an outside firm that administers the secured card program. Chase is apologizing. [Perhaps the apology letter will also go to the 89, using the same mailing-list glitch? (Sorry. That was a semi-snide RISKS-related comment from PGN.)]
``The incident shows how quickly relatively minor errors can balloon into big problems as financial services firms use computers to send hundreds of thousands of notices to customers almost instantaneously. Vanguard Group, the big mutual fund company, recently mailed incorrect tax-preparation materials to more than 5 million fund shareholders that could force customers to amend their federal income tax returns. In 1994, Fidelity accidentally reneged on a promise to pay investors a year-end dividend.''
[Source: An article in *The New York Times* 7 Mar 1996 Chase Manhattan
Computer Glitch Brands 11,000 As Bad Risks, By Michael Smith, from Bloomberg Business News. PGN Abstracting]
*The Boston Globe* (7 Mar 1996) reports that the scheduling computers of the
Harvard Pilgrim HMO ``broke down" on 4 Mar 1996 and are not expected to be available until Saturday. Patients needing to make appointments must wait until the computers are available; urgent care patients are being seen immediately. The medical records
system, as well, was down for seven hours on 6 Mar.
Harvard Pilgrim declined to specify the cause other than to say that it's a standard database problem, although requiring an intricate process to solve it. The full story can be retrieved from the Globe's web site:
http://www.boston.com/globe/eco/cgi-bin/retrieve?%2Fglobe%2Fvurdy%2F067%2Feco%2F002
The Risks? The more things change, the more they remain the same.
Saul Tannenbaum, Manager, Academic Systems, Tufts University Computing and Communications Services http://www.tufts.edu/~stannenbThe web page of the week in the most recent Information Week is www.switchboard.com. It is a compilation of the telephone white pages from all across the nation. You can search on combinations of last name, first name, city and state to find long lost friends, relatives or just interesting names. (A quick search found a Santa Claus in FL and a Bunny Easter in WA.)
This kind of information is not particularly new, of course. What is interesting is that Switchboard allows you to register by identifying your listing and sending your email address. They send back a password. Now you can login and add or modify information in your listing or even make your listing "unlisted". It is clearly a very easy thing to use throwaway email addresses to modify any number of listings. Switchboard admits as much in their policy statement (http://www2.switchboard.com/policy.htm) saying that their security is "designed to discourage" such impersonation. They will correct any falsification with appropriate documentation and take steps (this seems to mean blocking access from the offending email address) to prevent additional occurrences including, if applicable, legal action. (I fear there is very little substance behind that claim.)
Despite Switchboard's benevolent claims, the possibilities make me nervous.
I should note that when a listing has been modified by a user, it appears with an asterisk.
Joseph Richardson (Joseph125@aol.com)In RISKS-17.85, Li Gong talks about the Risks of running an applet of questionable parentage as ones self. In this context, he makes two related statements that I would like to address:
It is the second statement I wish to address. Data General's DG/UX operating system (with DSO, an additional security option) provides exactly this protection and for exactly the reason Li Gong points out (among other reasons). When a user first authenticates to the system (e.g., logs in), a session is created. Sessions are authorized for some number of sub-sessions (n >= 1). The session establishes a maximum set of credentials for any sub-sessions (i.e., a master domain). The credentials establish what a process can see and do *and* provide hard and fast limits for what any descendent processes can do. Within this context, each sub-session has its own domain which is more restrictive than the master domain.
So, for the scenario under discussion, a user might log in and begin performing their regular activities on the system (which might even include administrative duties). If a desire or need to surf the Net strikes them, a new sub-session is established with a very restricted set of credentials. Presumably, a site would be configured such that normal sessions did not have access to any Web browsers. The new sub-session would pick up the privilege to run the browser while simultaneously giving up access to virtually all information and other privileges on the system. This is assuming the master domain permits such actions. Then, and only then, the user could find and run Java applets. Regardless of what the applet tried to do or have other programs do on its behalf, the browser sub-session would be severely limited in what it could access or affect.
I hope this hasn't sounded too much like a commercial, but I did want to point out that there are operating systems that take this sort of thing *very* seriously and are actively working to provide the necessary
protections and assurances.
Li Gong's article in RISKS-17.85 postulates that the flaw which David Hopwood uncovered in Java is really a feature. It really is a serious bug. Java was designed to only use local classes which are part of its CLASSPATH (usually an environment variable). Here's a very real example of a situation where Mr. Hopwood's bug could cause a user to unknowingly delete every file on their hard disk, by simply browsing a Web page!
Lee Hasiuk <leeh@worlds.net> wrote:
> Your [Li Gong's] article in RISKS-17.85 postulates that the flaw
> which David Hopwood uncovered in Java is really a feature. It really is
> a serious bug.
In fact it is more serious than I had first thought.
The locations of files in Netscape's cache are predictable. By using a known security bug in JavaScript, it may be possible to arrange for downloaded files to be cached using a path and filename known to the attacker.
Although I haven't implemented an attack based on this, it is probable that it removes the requirement for the Loader and dynamic library to have been installed in advance, if Netscape's cache is enabled.
Li Gong <gong@csl.sri.com> wrote: > >A security problem occurs, however, if the remote web page refers (directly
> >or indirectly) to code that happens to exist on the client machine. [...]
However, they will be loaded by the standard AppletClassLoader, which causes the same security settings to be applied as for applets loaded from the network. For example, here is the result of an applet loaded via a file: URL attempting to link a native method:
[...] Opening stream to: file:/tmp/Loader.class to get Loader
*** Security Exception: link:/tmp/libtest.so ***
sun.applet.AppletSecurityException: security.link: /tmp/libtest.so at sun.applet.AppletSecurity.checkLink(AppletSecurity.java:153)
[...]
The bug I found loads applets using the built-in class loader, and so the above test succeeds.
David Hopwood david.hopwood@lmh.ox.ac.ukThe Netscape browser appears to be secure in this respect, but the online Java tutorial (draft version) seems to suggest that the security behaviors may be dependent on the specific browser, rather than being intrinsic in Java. Following is a direct quote from the tutorial. Note particularly the first point under "things ... that you might not expect".
[Draft Java online tutorial excerpt follows:]
What Applets Can and Can't Do
For security reasons, an applet that's loaded over the network has the following restrictions:
Things that applets can do, that you might not expect:
Another (possibly minor) risk of Java is implicit in its nature - it allows someone else to run a program on your system. If I wanted to do something like, say, set up a system to break encryption keys, my best way to get the needed processing power might be to build a Java applet that would do a small amount of the processing needed, then send the result back to me and wait for another 'assignment.' If I then proceeded to build an attractive Web site, I could drop that applet to anyone visiting my site and simply sit back and wait for results (which I'd need to refine).
I as the user might never notice this, but there'd be at least a small decrease in the resources available to me on my system, most notably a lack of available processing power. Depending on how the applet was written and whether it could detect other instances, my system might proceed to get slower and slower each time I visited the site in question. Would I notice this, or would I just chalk it up to overloaded servers and wonder later why my system was so sluggish?
There are a variety of other possible attacks based on this as well, which might or might not work depending on the capabilities of Java. Other possibilities include file 'storage', with small files being sent for storage and returned before the applet would exit for a shutdown and Miller's Migrating MUD, with a small private MUD/chat system being run on someone else's system, with only an address at a fixed site.
Alan Miller ajm@mcs.com http://www.mcs.net/~ajm/home.html[Li Gong suggested that Arjen Lenstra and friends might be interested in porting their large-number-factoring distributed software to Java. Perhaps they already have! Remember, they are looking for prime suspects (and sometimes suspect primes). PGN]
Read Larry Niven's short story, "Flash Crowd", and its two sequels. These deal with the problems that occur given an instantaneous transportation system (the fictional part), modern communication, and especially the accident "rubbernecker" instinct. Instant Woodstocks, or instant riots? Note for the science-fiction-impaired: Niven's teleportation stories aren't so much about teleportation, which he himself doesn't believe can be feasible [see his essay "Theory and practice of teleportation"], as about what would happen to society if it *could* exist, along the same lines of what happened to society with the telephone, the auto and highway system, etc.
John Light's comment: ``... a positive review ... of your favorite website may send millions of people to it ...'' is in very much the same vein.
-Harlan Rosenthal[The Larry Niven Flash Crowd, Flash Riot connection was also noted by wb8foz@netcom.com (David Lesher) observing the White Bronco phenomenon, AltaVista, and a though that universal teleportation had better wait until after 1/1/00, <soreff@VNET.IBM.COM> (Jeffrey Soreff), "Alan H. Martin" <amartin@zko.dec.com>, who points to Duncan Galloway in "Known Space" at http://ibm590.aims.gov.au/~duncang/niven.html, Andrew Duane <duane@zk3.dec.com>, hugh.davies@rnb.com (Hugh J.E. Davies), Christopher Davis <ckd@loiosh.kei.com>, bkis@nanaimo.island.net (Jonathan Thornburg). PGN]
Starting in the 1970's we have had to add occasional leap *seconds* to keep our official time in sync with the Earth's rotation. A leap second is a 61st second in a minute (always just before UT midnight), so that some date specifications such as "23:59:60 Dec 31 1972" are actually perfectly valid. This has worked reasonably well so far, but I've read predictions that within only a couple of decades we'll first start needing leap seconds every year, then twice a year, then even more and more often as the Earth slows down... (Note also that the Earth doesn't only slow down, it can sometimes speed up as well as our moment of inertia changes due to redistributions of atmospheric mass! To my knowledge we haven't yet needed an "anti leap-second" but it is bound to happen eventually.)
What shall we do then? Redefine the second? Keep two separate time standards, one with a fixed second and another with a stretchy second that changes to accommodate the Earth? There is already something called "Ephemeris time" that has been steadily diverging from standard time since 1900.
Another source of confusion is technical terms that mean different things in different fields. Geophysicists have appropriated the astronomical terms "Julian Day" and "Sidereal Year". The only trouble is they use "Julian Day" to mean day number in the current year, and "sidereal year" to mean tropical year!
[Some of you have submitted items relating to why do we need leap-days when we keep adding leap-seconds, and I have pointed out the difference between rotation and revolution to you. I am delighted to have this clear exposition from Joe in RISKS. TNX]
Recent postings have discussed the various algorithms used to calculate leap years, and the switching on and off of summer time (daylight saving time). A couple more thing to bear in mind (thanks to Steve Allen of UCO Lick Observatory, <sla@ucolick.org> ).
The length of day (LOD) will be increasing for the next few hundred million years. This is due to tidal drag. The exact amount of this increase in LOD is not yet certain because it cannot be calculated from simple physics; it must be measured and the tidal component painstakingly distinguished from the contributions of the changing currents in the fluid core of the earth and the angular momentum of the atmosphere and oceans.
The length of the year (LOY) is not changing in such a long-term secular fashion. Unless there is a fifth force or the fundamental constants of nature are changing as the universe ages, the size of the earth's orbit is pretty much fixed. There are subtle changes due to the other planets, but viewed over the long term these are mostly periodic.
For these orbital time periods you will find polynomial expressions (usually cubic) for their length. These expressions are the ones upon which Herschel's calculation of the proposed 4000-year leap are based. The most common expressions found in available literature are the cubic ones calculated by S. Newcomb at the beginning of this century. Those expressions are based on roughly 300 years of accurate observations. For that reason, it is a mistake to extrapolate those cubic polynomials more than about 300 years into the future. The cubic is really only the leading terms of a cyclical trigonometric series.
Even now, with another century's worth of data under our belts, and with the milliarcsecond accuracy with which we now know the positions of the inner planets, I think it might be a mistake to try to resolve whether the Herschel 4000-year term should be added to the calendar. Discriminating between the different schemes of the Gregorian and Eastern Orthodox calendars might be possible, but it would depend on how accurately you think you can predict the earth's rotation, and that depends on your ability to predict the weather in the earth's core."
So there isn't much point in trying to be too accurate about the number of days in a year! The variation in the length of the day is the prime reason for the introduction of leap seconds, which attempt to stop the calendar getting too far adrift from real (atomic) time. Leap seconds, at present, are not appearing in a predictable fashion, but as and when they are needed.
For computer system designers, here are some possibly helpful guidelines:
I've heard (but never actually found a source) that this 4000-year correction is in the standard Soviet calendar. The Greek Orthodox church's calendar (which I think is the official standard in Greece) replaces the 400-year rule by the rule "century
divided by 9 gives a remainder of 2 or
6". This is more accurate than the Gregorian calendar, but agrees with it
on the years 2000 and 2400.
Since the Greek Orthodox church is prevalent in Russia too, it seems the Russians have until 2/28/2800 to make up their minds which calendar they're using... :-)
Amos Shapir nSOF Parallel Software, Ltd. Givat-Hashlosha 48800, Israel amos@nsof.co.il Tel: +972 3 9388551 Fax: +972 3 9388552> ... This means, of course, that computations such as "number of days
> between x and y" where one or the other date is in early 1900 will be wrong.
This is actually a bug introduced by Lotus 1-2-3 and deliberately maintained by Excel in the interests of "compatibility". There is an option to use the 1904 Date System which was developed on the Mac for the original version of
Excel which does not have this bug.
Let's just leap from December 31, 1999 straight to January 1, 2001. That will eliminate not only any question about whether 2000 is a leap year, but also the arguments about when the twenty-first century begins. Of course some data processing software may need a bit of tinkering to know how to count the number of years when spanning century boundaries...
[And, of course, it won't solve the two-digit year problem... PGN]
As far as I know all CODASYL definitions up to and including COBOL-85 define the receiving field from ACCEPT variable FROM DATE which is used to read the system date, as a 6-digit field (PIC 9(6)) that holds yymmdd.
The risk is obvious — no system compiled with a standard COBOL compiler can deal with the turn of the century without explicit date manipulations being added to application programs.
[Yes, this one has appeared here before, most recently in RISKS-16.69. PGN]Many of the most popular real-time clock chips only hold the year as two digits and do not make provision for a century. As a consequence quite a few operating systems (including UNIX, via the ANSI C time_t structure) do not return the century as a separate field in their system time structures. Although time_t.year is not limited to two digits I suspect that it will not exceed 99 in practise if the clock chip used in the box doesn't have a century counter.
The risk? Same as described for COBOL.
Martin Gregorie Logica UK Ltd Gregorie@logica.com +44 (0171) 637 9111Please report problems with the web pages to the maintainer