The *Washington Times* reported Monday that computer malfunctions have recently switched Russian nuclear weapons to 'combat mode', according to a 13-page classified CIA report. This could increase the risk of accidental launch, although U.S. state officials are quoted as saying that they believe Russian nuclear weapons to still be under the central control of Moscow -- and that additional codes held are still required to launch the weapons. As is usual for mass-media coverage of these events very few facts are clear from the report. U.S. officials have been downplaying the report, and the fact the additional launch codes (controlled by Moscow) are still required for any nuclear attack should not be a comfort to any readers of RISKS. M. Welsh, currently at Vrije Universiteit Amsterdam.
Virtually the whole of the UK Internet disappeared yesterday for a couple of hours due to a power outage at a communications facility. Telehouse, which houses a POP for most major UK ISPs (*and* their international transit), lost power. This meant that the UK NAP, the LINX, went offline and UK to UK traffic had to re-route via the States, which it did very inefficiently. Customers connecting to the Net at an ISP POP in Telehouse (a very large percentage of the UK leased lines and dial-up) would have had no net access at all. Telehouse claims to have redundant power for up to some ludicrous number of days. Obviously not. The ludicrous situation is that the UK Internet, while not having one single point of failure, does appear to have one single node which is vulnerable. The Telehouse outage dragged down net.service for thousands, possibly millions, of us. And we had no fallback. The message: UK ISPs! Please think about your redundancy! Azeem Azhar, The Economist, 25 St James Street, London SW1A 1HG UK email@example.com http://www.economist.com +44 171 830 7133
The Swedish newspaper *Svenska Dagbladet* reports that the Swedish meat packers, Scan, had their web page replaced by an unknown attacker. The new page looked much like the old, but with changed text, including: "Now we're making our packages EVEN smaller, so that YOU the consumer can buy our meat for even lower prices. Boycott nasty vegetables. Eat more meat, smile, and be happy. And, by the way, you sure don't want to turn your stomach into a composter, right?" [My free translation.] The page's links take you to the Animal Rights Law Center, McDonalds, and Flashback, a home on the net for a number of underground movements. Original article at <http://www.svd.se/svd/ettan/ettan_97-05-12/Scans.html> Martin Minow firstname.lastname@example.org
A federal judge has thrown out a record-breaking $5.3-million verdict [Patricia Gerassy] against Digital Equipment Corp. after new evidence indicated the plaintiff's wrist injuries were caused by a neck condition unrelated to working conditions. However, in a separate ruling, the court upheld a smaller, $274,000 verdict awarded to a co-plaintiff [Jeanette Rotolo]. The judge also threw out a third $302,000 ruling awarded to another co-plaintiff [Jill Jackson], saying the statute of limitations had expired. The first plaintiff's lawyer says they plan to appeal the decision. (*Wall Street Journal*, 30 Apr 1997; Edupage, 1 May 1997)
For the past several days, and especially over the weekend of 10-11 May 1997, news stories in Kansas have repeatedly covered errors in the Sex Offender Database published on the World Wide Web by the Kansas Bureau of Investigation. On 12 May, the errors were enumerated for Geary County: of the sixteen addresses listed as the current residences of convicted sex offenders, fourteen are occupied by people who are not those listed in the Sex Offender Database. The reason for listing the incorrect addresses? The KBI reports that the convicted sex offenders moved without telling law enforcement authorities. And that is against the law. That the KBI (or local law enforcement) might have checked each address for the presence of an innocent family before announcing announcing their address as the home of a sex offender is not mentioned by the electronic or print media. But one man reports that his two daughters, both in grade school, have already been the subject of taunting and other abuse by schoolmates who are aware of the presence of their address in the KBI list. Robert Davis Amateur Radio K0FPC Emporia, Kansas email@example.com OR firstname.lastname@example.org
Microsoft Internet Explorer (3.x and 4.0) thinks that URLs of the form <http://...?x.y> should have the returned content executed if the ".y" is a recognized file extension (like .COM (or .PL for Perl users)). This works even if "Enable ActiveX controls and plug-ins" and "Run ActiveX scripts" are turned off. It looks like the MIME type is being ignored in favor of the file extension. As an example of the bug in Perl (although it looks like it works on any executable file (I've briefly tried it on .COM too)), if you have .PL defined to execute Perl scripts on your machine (your Web browser machine), a URL like: <URL:http://fisherm.indy.tce.com:8001/cgi-bin/hello?hello.pl> where the "hello" Perl script on the server is: #!e:/mksnt/perl.exe print "Content-type: text/plain\n\n"; print<<EOF; print "Content-type: text/plain\\n\\n"; print "Hello, Jigsaw!\\n"; sleep 10; EOF brings up a window on your machine (your Web browser machine!) for 10 seconds: Content-type: text/plain Hello, Jigsaw! This problem was first noted by Brian Hoyt (email@example.com) and Simon Hewison in comp.infosystems.www.browsers.ms-windows. Mark Leighton Fisher Thomson Consumer Electronics Indianapolis, IN firstname.lastname@example.org [What's MIME is yours? PGN]
A new Government Accounting Office report notes that the Pentagon procurement tracks purchases of small stuff (Tootsie Rolls) the same way it tracks big stuff. The estimate millions of dollars lost are attributed to over 100 different computer accounting systems that cannot communicate with one another. [PGN Abstracting from Reuter report in the *Mercury Mail*, 12 May 1997.] [Correction in source identification in archive copy.]
This lack of a sense of scale reminds me of the CIA: while they were overlooking that "old boy" betraying agent after agent in the Soviet Union leading to their deaths, a brother of another agent told me they checked to see why he (the brother!) was taking a Russian language class. It also reminds me of when I was working at a major telecommunications company. We were at a meeting to discuss how to verify that the company's computer accounts were being used by the people they were issued to. I brought up the idea that since this was going to take a lot of time, we should begin by identifying and verifying accounts with the most privileges: the accounts that could do the most damage if misused. I still can't explain why that was met with total indifference. A clue might be that the most powerful accounts of course belonged to people in the systems group who wanted to be, and had the power to be, left alone. These accounts ended up being specifically excluded from this verification process. Fred Ballard email@example.com Highland Park, Illinois USA
In ``The Social Security Internet Website: Technology and Privacy Implications'' (http://www.csl.sri.com/neumann/ssa.html), PGN says, "the SSA is to be commended for taking the initiative toward making this database available on the Internet, but chided for not having engaged in a public review prior to implementation and deployment." This statement made me think about the number of databases casually created because they may fulfill a valid need and are easy to do, but are not constructed with security concerns in mind. The risks associated with such casual information management are well documented in RISKS DIGEST. There is, however, an opportunity to improve the situation, analogous to the rapid response we have seen in Internet-related security. I am not up to date on the current database management software available for personal and midrange computers, so I may be speaking out of hand, but I am familiar with past offerings. While large mainframe DBMSs grew up in the security-conscious world of corporate IS and EDP departments, personal database software grew up in a much more open (and in hindsight, naive) environment. Security was simply not a concern in these smaller systems, and was not even a feature. PC-based DBMSs made it very easy to construct useful databases without much technical knowledge. So while the mainframe DB administrator may have some background in information security, the typical PC-based DBA had none (and probably didn't even know he or she *was* a DBA!). And since the available software did not emphasize security, the people who built such databases were blissfully ignorant of its needs. As a case in point, I myself was guilty of such a casual attitude. A long time ago in a job far away, I was asked to assist the police department with a database they were constructing for a long-term investigation. This was simply as a favor to the police, a little corporate good citizenship, since several of our corporate security people had connections with the police department; I happened to be the guy around with a little DB experience. Despite the fact that this was a large metropolitan police department with its own mainframe and EDP facilities, they had no resources to help their detectives with a PC-based database. This was long before I was a RISKS reader, and I was not at all sensitive to the various privacy and security issues. My assistance in the matter consisted of reviewing record layouts and data entry screens to make sure they could get the information they wanted back out. As one might imagine, the data to be recorded contained sensitive items, and its inadvertent release could harm the investigation, or cause all kinds of problems for the people listed in the database or the police department (Consider the scenario where a newspaper publishes the fact that an individual is listed in such a database. That person, regardless of guilt or innocence, then lives under a cloud of suspicion, and sues the city.) I dealt only with the functional issues, to make sure it would do what the detectives wanted, and never gave any thought to protecting the information. But what if someone had gained unauthorized access to this PC (i.e., had turned it on), or the computer or hard drive was stolen? The software did not require users to identify themselves, could therefore not determine whether they should have access to any of the data, and at any rate stored the data in clear on the disk (and just because some it was binary instead of text would be little hindrance to reading it). So we have a database that is easy and convenient to construct, yet its contents are wide open, because they are difficult and inconvenient to protect. I would imagine there are many such private databases in existence. The lack of public review means that no one will ever point out their security vulnerabilities. The opportunity we have for the future is for even the simplest personal DB software to include high-quality security features. However, this alone is insufficient. These products must also emphasize security consciousness from the beginning. Every product includes tutorials and sample databases, setup `how-to's and quick-start procedures; many also include interactive database design capabilities. Each of these should as a matter of course include database security. Security features such as authentication, encryption, and access levels should be enabled by default; the option should be to turn them *off*, not turn them *on*. This will begin to build awareness among the people who use this software and at least give them some opportunity to protect the information. By analogy, consider the rapid improvements in security and awareness in Internet-based activities. We still have gaffes like the unprotected access to SSA data, but many people are now aware of the risks of posting their credit card numbers in Internet transactions or downloading any random program they find. More to the point, the software they use to do these operations now incorporates many security features and makes them very visible as an integral part of using the software. The effectiveness and usability of such features may be subject to debate, but at least we are moving in the right direction. Many people are actively involved scrutinizing and probing their capabilities for weaknesses. What commercial PC-based database software now available could withstand such scrutiny? None. Think about that the next time you enter your credit card number into a secure transaction form on the web, and it goes into a database on the server PC. Security will always add cost and inconvenience to software. However, the costs and inconveniences caused by security breaches should motivate us to use it. Steve Branam Hub Products Engineering 508-486-6043 firstname.lastname@example.org Digital Equipment Corporation DTN 226-6043
Peter Ladkin, Universitaet Bielefeld, Technische Fakultaet, Postfach 10 01 31, D-33501 Bielefeld, Germany http://www.rvs.uni-bielefeld.de +49 (0)521 106-5326 (From John Laverty via Peter Ladkin) In Britain, the National Physical Laboratory is the canonical site for questions concerning standard time, and the Royal Greenwich Observatory (which is now in Cambridge) refers all questions there. I talked to Dr. John Laverty of Time and Frequency Services, CETM (email@example.com), who kindly supplied me with the following account of time standards. The position of the sun in the sky has been used as a basis for measuring time for many centuries. One simple example is that 12 noon in local solar time occurs when the sun is directly `overhead'. However, local solar time does not provide as uniform a time scale as that based more implicitly on the rotation of the Earth about its axis. The Earth's orbit is elliptical and its axis tilted, so that the actual position of the sun against the background of stars appears a little ahead or behind the expected position. The accumulated error varies from 14 minutes slow in February to 16 minutes fast in November. These effects can be predicted, and a more uniform timescale can be established on the basis of a hypothetical 'mean' sun that moves with uniform speed across the sky. Greenwich Mean Time (GMT) is probably the most well known example of such a time scale: GMT is the local time on the Greenwich meridian based on the position of a hypothetical mean sun. The need to coordinate time measurement and agree on a standard time was driven by improved communications, particularly by the railways, when the differences in the local time at different locations became very noticeable. Greenwich Mean Time was established as a world time standard at the International Meridian Conference in 1884. The time scales in active use today are Universal Time (UT), Coordinated Universal Time (UTC) and International Atomic Time (TAI). They are described below along with some of the reasons for their use. Greenwich Mean Time (GMT) and Universal Time (UT) are very closely related. Before 1925 January 1, the twenty four hour GMT day was taken to commence at noon, while since that date the convention has been for the GMT day to begin at midnight. The term Universal Time (UT) was introduced in 1928 by astronomers to denote GMT measured from Greenwich Mean Midnight, to be clear about the convention for the start of the day. Now there are actually three different definitions: UT_0, UT_1, UT_2 (using underscores to denote subscripting). UT_0 is based on `direct' observation of the earth's rotation on the prime meridian, UT_1 is adjusted to account for the small movements of the Earth relative to the axis of rotation (polar variations), and UT_2 adjusts for seasonal variations. The maximal difference between all three is of the order of a few tens of milliseconds. The term `UT' thus crudely refers to all three for large granularities, and for finer granularity, the term is ambiguous and one needs to specify which of the UT's one is referring to. Starting in the 1930's with the development of quartz crystal oscillators, but particularly in the 1950's with the introduction of atomic clocks, better measurements have been available. As a consequence of studies comparing atomic clocks and astronomical observations, it was realised that atomic clocks offered a more much more stable time standard than one based on the rotation of the Earth. In 1967, the SI second was redefined as "the second is the duration of 9192631770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom". The international time scale based on the SI second is International Atomic Time (TAI). TAI was synchronised with UT at the beginning of 1958. It is a more stable time scale than UT, but UT and TAI naturally drift apart because they are based on different principles. Universal Coordinated Time (UTC) is a compromise between TAI and UT and was established in its current form on 1 Jan 1972. It uses the SI definition of the second, but introduces leap seconds by convention in order that the difference between UTC and UT shall never be more than one second. There have been 20 leap seconds introduced since January 1972; the first at 1 July 1972. The 21st leap second is scheduled for 1 July 1997. So UTC and TAI run in lockstep, but with conventional separation, which is now 30 seconds and will become 31 seconds on 1 July 1997 (By the beginning of 1972 TAI and UT had drifted apart by 10 seconds from the `synchronisation' point at the begining of 1958, which accounts for the extra 10 seconds in addition to the leap seconds). UTC is the current world time standard, as indicated by the recommendations of the International Telecommunications Union (ITU) for example. There are some 50 or so centers around the world which measure TAI/UTC using commercial atomic clocks, with just a few laboratory based 'primary' caesium standards which are are able to measure the time with greatest accuracy. The PTB in Germany has the distinction of having the longest running and most reliable primary caesium standards. The NPL, having developed the first caesium atomic clock in the 1950's, is currently working on the `next generation' standard based on the caesium fountain method demonstrated at the LPTF in Paris. There are other primary caesium standards at NIST in the US, NRC in Canada, CRL in Japan and in Moscow. The institute responsible for maintaining TAI and UTC is the BIPM in Paris, and the decision as to when to introduce leap seconds is made by the IERS, also in Paris, who measure UT also. The Royal Greenwich Observatory (RGO) no longer maintain their own time standard. It is recognised that GMT and UT are equivalent, so that now the IERS provide the information necessary to determine GMT. However, the appropriate definition of UT should be used instead of GMT if the distinction between UT_0, UT_1 and UT_2 is important for a given application. The time standards that are so carefully measured by astronomers and metrologists need to be made available if they are to be of use, and radio time signals are one of the most common ways of making UTC available. In Western Europe, NPL broadcasts the UK time on 60 kHz from the BT Radio Station at Rugby (call sign MSF), and similarly, the PTB broadcasts Central European Time from Frankfurt (call sign DCF77) on 77.5 kHz. There are similar transmitters operated by other countries around the globe. The other common means of accessing standard time is through the Global Positioning System (GPS) navigation system, where accurate position and time information allow a receiver to calculate its position from the times of flight (at the speed of light) of signals from a number of GPS satellites. The GPS system was developed, as its name implies, for positioning, but a welcome spin-off is accurate time. The GPS time signals offer high-accuracy UTC (one microsecond time accuracies are readily achievable) and global coverage, but the LF radio time signals, although limited to a range of typically 1500 km, offer the advantage of broadcasting the local time including summertime changes (to millisecond time accuracies).
Last evening I discovered a probable side-effect of the Y2K problem. I have used a credit card to pay the monthly charges of my on-line service provider. It happens to be the service noted in my return address. A week or so ago, when I signed onto the service, I was prompted that my credit card information must be updated. As I had no other choice, I dutifully followed the instructions and submitted the information. My access was granted and I thought no more about it even though I had been using the same card for several years. Yesterday, I was again prompted for an update of my credit card information. I entered the information but noticed a message stating that they would resubmit the charge to the credit card company. This peaked my interest to the point I contacted the company and inquired as to whether there was any problem with my account. Fortunately, I was able to contact a real person, (score one) who was very helpful and seemed knowledgeable about the system, (score two) and even offered some information as to the problem (score three)! Seems that the on-line service provider was submitting the charge using only one digit for the month in the expiration date and the credit card company required two (zero fill to the left for all months less than 10). I advised her that I was apparently being victimized by a program bug but also indicated that the company's program was perhaps an accomplice (i.e. accept a single digit month as valid, except for zero, which would reduce the possibility of a false negative from 75% (9 out of 12 months) to a fraction since the only positive errors would be confined to those bum transmissions of only 2 months). I then signed back onto the on-line service and checked my billing information only to discover that there was no way to force the lead zero in the expiration date! I did leave a message for customer service. My suspicion is that in "fixing" one or both computer programs for the Y2K problem, the program "broke" the month. The risks are quite obvious; thorough testing, customer requirements, et al. I am reminded of a time many years ago when a particular technical support person began cataloging the application programmers excuses. This one falls under the heading of, "But I didn't change anything in that part of the program!" I can only hope that I will be able to sign onto the service to send this. Phillip
You may remember RISKS-19.09, in which I discussed the risks in a network-wide attack on the RSA DES challenge: The Swedish group at http://www.des.sollentuna.se/ didn't give out its source, so the client could, in fact, do anything, such as crack a master EC-card key. The reason given was client integrity. Well, a month after this, the promised source code release has not happened. Instead, it appears that somebody disassembled part of the client, made a version that reported fake "done" blocks, and then sent these to the servers. Moral? Don't ever think that nobody can read compiled code. Don't try to run a cooperative effort like this in a closed development model. Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, firstname.lastname@example.org.
As Hans Dobbertin's recent works have shown, the quasi-standard MD5 checksum has weaknesses (for more info, see http://www.ph.tn.tudelft.nl/~visser/hashes.html ). There is a chance that a malicious attacker can create two files with the same MD5 hash, if he can create both files. If this really becomes true, this creates some interesting threat models for software. For example, the attacker could create two versions of a program, one correct one and a second one with a back door. He could give the correct version to an expert, who would verify the program and its MD5 checksum (or PGP-sign it, since PGP uses MD5). Then, the attacker hands out the back door version of the program, together with the expert's PGP signature. Consequences? Yet another reson to distrust code signing. Don't use MD5 for it. SHA-1 and RIPEMD-160, which have been designed with this kind of attack in mind, probably are better choices at the moment, but nobody knows tomorrow's research results... Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, email@example.com
Please report problems with the web pages to the maintainer