Legislation has been introduced in both the House and Senate to permit the export of data encryption hardware and software if similar technology is available from foreign suppliers. The bills affirm the right of U.S. citizens to use any type of encryption equipment domestically, and prohibit the mandatory use of special keys that would allow law enforcement officials access to encrypted messages. In addition, the legislation would make it a crime to use encryption technology in the commission of a crime. (*The New York Times*, 4 Mar 1996, C6)
I thought you might be interested in some of the measures allegedly taken by the White House sysadmins to prevent a total meltdown of its mail service.-- Prentiss Riddle firstname.lastname@example.org
> Date: 9 Feb 96 16:03:20 -0700
> From: <a href="mailto:email@example.com">firstname.lastname@example.org</a> (Joel M Snyder)<br /> > Subject: High mail volumes at whitehouse.gov
> Organization: Opus One, Tucson, Arizona
> Newsgroups: comp.mail.misc,comp.security.misc,news.admin.net-abuse.misc
> Good day. By way of introduction, I'm the consultant who did the
> "anti-mailstorm/anti-mailbomb" software that runs on the MX host for
> WHITEHOUSE.GOV. Now that the Telecom. Act of 1996 has been signed,
> the volume of mail through WHITEHOUSE.GOV has gone up significantly.
> For example, there were about 85,000 lines in the mail log file yesterday.
> Most of that is just people who want to express their opinion. However,
> several misguided individuals have decided that they want to throw a monkey
> wrench into the works by storming the President's e-mail.
> I'm writing this to let any system administrators out there know that you
> may find mail from your site to WHITEHOUSE.GOV is not moving very quickly.
> This is normal; it's a sign that the automatic protections of that system
> have kicked in.
> Without going into details, if too many messages come from a single site,
> the mail handler will throttle back accepting messages. Eventually,
> though, the mail will be accepted for delivery. If you have legitimate
> mail, it will eventually get through (many messages from the same
> correspondent will be flushed without acknowledgement). However,
> correspondents who were used to getting a reply within seconds telling them
> that their message was accepted may see a substantial delay.
> Finally, if any users on your site have any delusions about the effect of a
> mail bomb or storm of mail, let me help you dispel them: (1) no one
> important enough to make a difference will be affected or know or care; (2)
> if the messages are nasty or threatening enough, someone equally nasty may
> come and visit; (3) what you'll succeed most in doing is ruining the
> weekends and/or days of underpaid civil servants as well as wasting federal
> tax dollars.
> Please feel free to redistribute this or use parts of it in your motd.
> Joel Snyder
> PS: I don't read these newsgroups and am spending most of the weekend
> trying to make sure that the mail system doesn't melt down anyway, so if
> there is discussion on this, I won't see it.
David Hopwood in RISKS_17.83 mentioned, "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."
This does not appear to be a bug (e.g., a slip in the implementation) but rather a design decision. It is clearly documented in Java that any applet downloaded from the local machine is not subjected to the security restrictions that apply to applets downloaded from elsewhere. This at first appears quite reasonable — otherwise, you cannot do a lot of interesting things even locally.
A security problem occurs, however, if the remote web page refers (directly or indirectly) to code that happens to exist on the client machine. For instance, the following line can be found at the bottom of my home page <A HREF="file:/tmp/play.html"> Fancy page </A>. If you click on that, and if your trojan-co-worker has placed a file called play.html and its associated class files in /tmp on your machine, those applets will run.
Alternatively, if someone knows that you have certain code X (applet or not) in your directory — suppose you have been developing it as a possible attack on others — that person may trick you into invoking X on yourself. An immediate question is which file should "file:/tmp/play.html" refer to? The one on the remote machine or the local one? There are pros and cons either way.
The real problem is rooted in the fundamentally flawed philosophy that an applet you downloaded runs on the local machine as you. This goes against years of research in computer security. Such an applet, unless its authenticity can be verified to the satisfaction of the downloading client, should instead run within a confined (protected) sub-domain, and any further invocations from this code should also run within this sub-domain. (PGN can tell us all about the required and desirable properties of such a domain.)
Most machines and OSs obviously do not support such confined domains. The point is whether Sun should have done the Java interpreter differently to make life safer. For instance, on Unix machines, it is possible to set uid on downloaded stuff. This is just one of the many ways to improve security within the Java execution model.
Nevertheless, Java security will probably remain a news item until the day when the fundamentally flawed philosophy is changed.Securely yours, Li Gong, SRI International, http://www.csl.sri.com/~gong/
Assuming no significant damage to a telephone central office or supporting infrastructure, the most common cause of "collapse" (defined in this case as a dramatic form of overloading) is indeed the simple act of too many people trying to use the phone at the same time. Telephone switches (and related trunking) are designed to a designated expected maximum number of simultaneous calls, which is far less than the total number of lines/subscribers. In widespread emergency situations, that threshold can be easily exceeded.
In the case of earthquakes here in L.A., the quake itself can cause its own telephone problem even before people have had a chance to reach for the handset--the quake can knock so many phones off the hook that (at least initially--there are timeouts in modern switches) the switch thinks that everyone and his brother is trying to make calls. Phones off hook also can fool some people into thinking that their line is dead, since most modern switches, after a few minutes of tones and recordings, will only put forth silence until all phones on a line have been hung up and reset. If an extension phone is off-hook under a pile of books, it's easy to miss (especially in the dark!)
However, the most common cause of frustration during overload events is that people are not patient enough. Modern switches establish a queue for providing dialtone. Under normal conditions, you typically get a dialtone essentially immediately. But under overload, you might have to wait ten seconds, thirty seconds, or even for minutes. It seems like a *long* time. Most folks don't realize this and keep hanging up and picking up the phone again, trying to get a dialtone. Each time they hang up they lose their place and reset back to the end of the queue.
So, in emergency situations (assuming you have a serious need that really requires use of the phone), pick it up and *wait* for dialtone. To test to see if you're still connected with the central office, simply blow into the handset microphone and see if you can hear the blowing lightly in the earpiece (this is easiest to test by blowing while alternately being hung up and off-hook). If you hear a difference, you've still got current on the line, and your connection to the switch is intact. If you wait, you'll probably get dialtone--sooner or later. (Whether or not there will be sufficient trunking for your call to get *out* of the office to your destination is another matter...)--Lauren-- Moderator, Internet PRIVACY Forum http://www.vortex.com
In RISKS-17.84, Jake Livni described an Israeli news report in which it was stated that the local telephone system "collapsed" shortly after a terrorist attack. The term "collapse" was not defined in the article.
Jake also noted that people near to a disaster tend to use a nearby phone to inform others (family members, etc.) of the event, and that people who know someone near a reported disaster will attempt to call and verify that person's well-being.
While a telephone system can "collapse" in a number of ways, most systems in use today go to great lengths to avoid a total failure under abnormal loading (which is caused by the human tendencies noted above). A system's performance will degrade under such conditions, but not necessarily fail completely. (This is, of course, neglecting bugs and other unpredictable situations.) While some systems may indeed fail to the point of requiring repair service, most will simply slow down until the overload dissipates.
The Risk in this case is that under disaster conditions, calls to emergency services may be blocked by bystanders using up the available phone bandwidth to call Aunt Martha to say, "I'm OK, but you should see the mess!" Communications into and out of San Francisco area after the World Series earthquake a few years ago were rendered almost useless by this condition.
I spoke with the commander of the Central Ohio HAZMAT (Hazardous Material) Response Team (operated by the local fire departments) two years ago. Part of his equipment is a cellular telephone, but he admitted that it is rarely used because by the time his team arrives at a disaster the locals have swamped the system and he can't get a dial tone. The Team is considering using volunteer Amateur Radio operators to provide contact with various telephone information services during a disaster, to bypass the need for local telephone access at the disaster site.
Telephone systems are expensive to install and maintain, so operators design their systems to carry "normal" loads, with some reserve capacity. A system designed to carry the entire load during a disaster would make the price of telephone service prohibitively expensive. (Thereby reducing load? Hmmm...)David Hinerman Aldiscon, Inc. phone (614) 764-2490 ext 228
Last Friday we had a power outage that lasted for about 2 hours. It was one of those dirty outages. The ones where the power goes off and on four or five time in the span of about two seconds, before it goes out for good.
We made the decision to move our computer that serves as a file server and mail server to the other side of the computer room so we could plug it into the ups system. This computer carries a lot of baggage with it--a tape drive, external disk drives, and two printers.
After we moved this equipment, the security alarm started going off in the mornings before I was coming in to deactivate it. One of our observant employees thought that the printer was the problem. So we ran some tests, and sure enough, the security system's motion sensor was detecting the paper as it came out of the printer and setting off the alarm, which also sounds an alarm in the campus police dept.
We have now moved the printer to its original spot, under the motion sensor, and we are on good terms with the police again.Jim Hudson
[Now you have a protector protector detector rejector? PGN]
On March 1st 1989 we received a support call from a user of our equipment based in the (Persian) Gulf. It wasn't working! The equipment comprises two boxes, both using the Microware OS/9 operating system (completely blameless throughout, I hasten to add). Box 'C' was a battery portable computer, with a real-time clock chip & continuous memory. Box 'D' was a volatile system where the OS was re-started at each power on. The system was developed in 1987 & first shipped in 1988.
On 1/3/89, box 'C' attempted to boot box 'D' as usual. As part of this process, it set the date - to 29/2/89! The OS date validation routine in box 'D' rejected this, quite rightly. Box 'C' *knew* it had the right date - the RTC chip told it so, and rebooted box 'D' to teach it a lesson. And so the process continued (all day if necessary).
It turns out that the RTC chip used - a 58274C - only has a 2 digit year counter (!). As a result, it needs a separate 2-bit leap year counter, which has to be correctly initialised. Since the initial boot of the box 'C' operating system was part of manufacture, initialising the clock chip was part of the manufacturing test procedure - which was written and tested in 1988!
We had worked this out quickly enough to call our manufacturing partners in San Diego CA first thing in their morning & tell them to expect a lot of support calls that day! The problem was actually in the driver for the RTC chip, which bypassed the OS date validation code when setting the time & date.
This was not the last problem we had with the 58274C clock chip, but that is another story...xxxxxxxxxxStewart Hughes Ltd, School Lane, Chandlers Ford,Eastleigh, Hampshire SO53 4YG UK email@example.com +44 (0) 1703 270027 firstname.lastname@example.org Fax:+44 (0) 1703 270007
The following is important information about Digital UNIX[R], formerly known as DEC OSF/1[R]. Thank you, Digital Customer Support Center
SOURCE: Digital Equipment Corporation DATE: February 28, 1996
TITLE: Digital UNIX Systems Date/Time Problems - Leap Year
Recently Digital Equipment Corporation discovered a time keeping problem
in Digital UNIX with respect to leap year recognition.
On machines without this ECO/patch installed, the problem is seen
only if the system is rebooted during the month of March.
I just found a URL for the Digital SPR 11-60903 that Dale Robinson quoted in RISKS 17.83, and I highly recommend it for both its completeness and its humor as an explanation of why the year 2000 *is* a leap year. The SPR can be found at
http://www.southern.edu/people/bnbennet/text/lycomplaint.html-- sidney markowitz <email@example.com>
Another aspect of people's confusion with the rules for dates came to light the other day when I was tring to match the behaviour of two Julian functions.
One, the Oracle numbers is well behaved and successfully handles the leap from Julian to Gregorian calendars in (a gap of 10 days in 1582). As has no doubt been discussed before just when the adjustment of calendars were adjusted was a matter of national preference and several nations did not make the move until this century.
Unfortunately the set of public domain clipper routines I encountered that had been embedded in a new system I was trying to interface with didn't understand:-
The Julian Gregorian change.
No leap years when the year is divisible by 100.
(I assume the fact that it will get 2000 right is an
The documentation with the routine claimed it was accurate back to 01-Jan-0100; unfortunately it fell over for dates before 01-Jan-1901.
The risk here is of course embedding 'shrink-wrapped' software in your apps and trusting it to do the job on the label. In fact this software didn't even come with disclaimers I'll post the names of the routines and the author if people suddenly wonder if their Clipper apps are going to run alright.
Note: For UK/US dates in the range 01-Jan-1901 to 31-Dec-2099 they work fine.
[Julienne calendars is more like it — chopped up in thin strips around funny leap years. PGN]
A note to followup to Tom Dickens' message regarding 29 Feb 1996 errors in Excel (RISKS-17.83)
I use Lotus 1-2-3 Release 5 for Windows and Excel 5.0 on the MAC. My tests revealed the following:
A number from 1 through 73050 that 1-2-3 assigns in sequence to each date from January 1, 1900, through December 31, 2099. For example, the date number for July 21, 1991, is 33440.
Lotus has various number formats for dates including a day-month-year format that shows today's date, for example, as 05-Mar-96. When one enters (or calculates) a date past December 31, 1999, the format changes such that February 29, 2000 is represented as 29-Feb-2000. If the column width is set to accommodate a dd-mmm-yy format, one gets a string of ********* for dates past December 31, 1999. Also, the @YEAR function returns a value of 100 for a year 2000 date (@YEAR returns 96 for a 1996 date).
These results may surprise spreadsheet users who have expectations about the consistency of formatting and who do not understand the convention that Lotus uses. By the way, the maximum date for Lotus is December 31, 2099 (date number 73050).
After reading about the fact that Excel 5 assumes that there is a leap year in 1900, and so all its dates (recorded as days since 1/1/1900) are wrong, I was
struck by a horrible thought.
Ole Automation, the Windows inter-application macro programming interface, uses data types based upon those of Microsoft's spreadsheets and Visual Basic. One of these datatypes is a date. Did this "Date" type deal with the leap year properly, or were apps using it meant to assume that 1900 was a leap year for compatibility.
I bit of CD searching cam up with the following answer from from the Win32 SDK, Ole Automation, "Data Types, Structures, and Enumerations":
A value denoting a date and time was specified. Dates are represented as
double-precision numbers, where midnight, January 1, 1900 is 2.0,
January 2, 1900 is 3.0, and so on. The value is passed in date. This is
the same numbering system used by most spreadsheet programs, although
some incorrectly believe that February 29, 1900 existed, and thus set
January 1, 1900 to 1.0.
So, modern apps are meant to assume that 1/1/1900 is really the second day of the year/century, rather than the first so that from 1/March/1900 onwards the value of a date calculated by a broken (assumes 29/Feb/1900 exists) application and a non broken application is the same.
I can't decide if this is an elegant workaround of the problem or not...Steve Loughran, Hewlett-Packard Laboratories, Bristol
In 17.83, Steve Elliot asks:
>Over the weekend, Win95 erroneously took my system out of Sydney Daylight
>Saving. This should not happen until the end of March.
> * What other "automatic" operations may be instigated without my knowledge?
Plenty. Lots. This is, after all, what computers are for. Modern operating systems are designed to hide functionality --- especially with regards to chronic activity --- from the guise of the user. Multitasking (and multiprocessing) systems have the intentional property that "daemons" perform routine actions without the end-user's knowledge and perhaps consent.
There is a very good reason for this: If the user were asked to verify and understand every subtle operation of an operating system or daemon process, no useful work could ever be done. (Could you imagine having to answer for a dialog box for every operation taking place on your system?)
Unfortunately, this problem is only going to get worse --- not better. As personal computers and the operating systems that they run become more complex, much more will be going on in the system "behind your back", and you may never be aware of it. Most people are used to thinking of the PCs on their desks as predictable boxes that only do what they are explicitly told to do. MS-DOS and Mac operating systems aren't going to spawn spurious processes on you to, say, initiate their own I/O or network activity.
This is, of course, something of a myth. Nearly all computers (regardless of the power of the O/S) are capable of performing "asynchronous" activity which is unknown to the user. These functions are both necessary and desirable in nearly all systems. Examples include:
I came into work today to find e-mail waiting in my in-box from someone who had clearly reached their frustration point with their bank.
It appears that this person [who will remain nameless] has had a great deal of difficulty with some banking and credit card services for the Bank of Hawaii. It just so happens that I am the owner of the BOFH.COM domain, which I use. This person sent me copies of all of his past correspondence with the bank, including his home telephone number, his VISA number and credit line. Now, being a relatively nice guy (and completely against the spirit of the domain ;) I sent him a polite note informing him of his mistake.
I believe the risks are obvious, but here are a few I can think of:
T Bruce Tober <firstname.lastname@example.org> wrote:
: In more than ten years of computing I've been hit by a virus only once.
Actually, that's probably not true.
: Phil Katz's Arc program (now known as PKZip). I
: downloaded it and ran the supposedly self-extracting file.
: No hard drive. All files deleted.
*Sigh*. You've just described a trojan [horse program], not a virus. It's still bad, of course.
The risk? Virus detection programs typically won't help at all in detecting or avoiding trojans. Calling everything a virus might lead to an unwarranted complacency in people who have such protection software.
Please report problems with the web pages to the maintainer