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…
(Washington, DC, press release by IP Newswire, 1 April 1998) The Defense Advanced Research Projects Agency (DARPA) today announced a major new initiative in software engineering. F.P. Rivers, program manager for the initiative, said that it addresses a major problem facing the US military: that much of current information technology is too "compute-intensive" to be deployed where it is most needed — at the small unit or even individual soldier level. This initiative has its origins in a fortuitous observation: Rivers and several colleagues noticed that users on the most widely used platform -- Windows 95 — were routinely presented with messages that an unknown unrecoverable error had occurred, and that these users just as routinely ignored those messages. "This occurred not just in casual use, but also in mission-critical operations." Rivers said, "Once we started thinking about these messages not as a help, but as a hindrance, several other observations came together." In a typical program, 40% to 80% of the code is devoted to error detection and error handling. "Software bloat" — the ever increasing size of programs — has been blamed on programmers adding more and more features, but could also be blamed on all the error handling associated with those features. To make matters worse, multiple studies had shown that much, if not most, of the error-handling code was never tested. Sometimes this was because of time and budget pressures; sometimes the potential errors were so obscure and complex that the situations were too difficult to create "in the lab". This research was backed up by actual experience: error-handling code was often found to have significant errors. Rivers summarized, "So, the typical program is overloaded with code that is rarely used, that may not work, and whose output is likely to be ignored anyway." He concluded, "With this code removed, programs will be dramatically smaller and will run somewhat-to-noticeably faster." Many software developers, including several major vendors, have already taken some tentative steps in this direction, having recognized pieces of the problem, but without grasping the "big picture". Rivers said he expects this new approach, dubbed "Fault-Oblivious Computing", to quickly become the dominant software-engineering paradigm. He acknowledged that there were small highly specialized segments where fault-tolerant computing and program verification would still be of value. A major component of this initiative will be to develop tools to automatically identify and remove unneeded error-handling code from existing applications. The success of this approach would be be bad news for memory-chip manufacturers, who are already hard-hit by decreased demand. [Perhaps Fault-Oblivious Computing could be used to help with the Y2K problem, getting rid of all those gratuitous date comparisons!!! PGN]
A small team of researchers has succeeded in building a prototype of the so-called "quantum computer" that can factor large numbers quickly and defeat public-key cryptosystems. The researchers cracked the DES-IV-1 challenge, revealing the message "Can't anyone around here keep a secret?" Since the new computer is based on superconducting quantum interference devices, it is not bound by conventional temporal limits on computation. In fact, the researchers were able to use their system to crack challenges that had not yet been created. These future secret messages included, "God in Heaven, what have we done?" and the cryptic "tsopyadslooflirpanasisihtsey" -- which clearly shows that future challenges are going to use multiple layers of encryption. President Clinton congratulated the researchers, but said that he was considering a proposal to ban the export of quarks from the United States until the NSA could implement a quark escrow system, by which each quark in the universe would be uniquely numbered. When asked if their invention would enable scientists to foretell the future, the researchers pointed out that they can only decrypt messages that are encrypted using certain methods that are known today. Furthermore, there is no way for them to determine if the messages that they receive are authentic or if unknown people are sending false messages to confuse us. "If only there were a reliable way to digitally sign a transmission," bemoaned one of the researchers.
First there was the Texas cattlemen's legal action against Oprah Winfrey for her remarks on TV about whether she would ever eat beef again after hosting a program segment on Mad Cow Disease. This suit was brought under the Texas food antidefamation laws intended to protect that state's agricultural products. Winfrey was eventually absolved. There was also Nike's threatened action against the Doonesbury comic strip for drawing attention to the shoe manufacturer's alleged unsavory labor practices in foreign sweatshops. (A few years ago one week of Doonesbury columns on Frank Sinatra was deemed offensive by the Italian-American Antidefamation league and was omitted from some newspapers.) Consequently, it is not surprising in our litigious society to hear of the recent passage of the new Computer Anti-Defamation Law (CADL) protecting computer system developers against people making public remarks detrimental to computer programs and hardware. Apparently, this law was in part a response to the fact that specific cases of shoddy software are frequently mentioned in the Risks Forum and other Internet newsgroups, which has annoyed certain developers of chronically (and chronologically!) flawed systems. Although there have been reports that allegedly some of these developers intentionally leave flaws in new software releases to incentivize customers to upgrade to future versions, specifically naming purveyors accused of such nasty business practices has explicitly been made illegal under the new law. In response, RISKS has considered the use of a private coding scheme to refer to specific companies and products, but has discarded that approach because it appears that the mapping from descriptors to specifics would fall under the cryptographic escrow and key-recovery regulations. The Justice Department is considering whether the CADL can be applied to the Cloverdale High School students (RISKS-19.60) who broke into Pentagon computers and thereby made the U.S. Department of Defense look rather silly. However, prosecution is considered unlikely — not because there were no financial gains and no extensive damage to the systems, but rather because DoD surprisingly appears to be very grateful to the young hackers for demonstrating how vulnerable the Pentagon systems really are. A recent draft report from the U.S. General Accounting Office details the extent to which Government computer systems currently fail to be Year-2000 compliant. The GAO legal staff is currently considering whether public release of this report would be in violation of the CADL, because there are many references to specific noncompliant systems and their developers. [We may need a CADL prod to get this report out of their barn.] Precisely because of ongoing difficulties in rectifying the Year-2000 Problem, the CADL has an exclusionary clause granting immunity to the purveyors of the critical infrastructures (telecommunications, electric power, transportation, etc.) in case their systems collapse at Y2K. This relief clause was included in hopes of inducing these purveyors to reveal the extent to which the critical infrastructures are still Y2K-vulnerable -- which they have previously resisted disclosing in fear of subsequent liability litigation. There are unofficial reports that many of the computer systems on which the critical infrastructures depend are in fact not yet Y2K compliant and that many of them are not likely to be repaired in time. Rumors persist of massive outages of communications, utilities, and transportation on or after 1 Jan 2000, but are very difficult to verify at this time. (The proof of the pudding is obviously in the eating, but many of us may be dieting at that time.) Additional legislation absolving companies, COBOL programmers, and other Y2K specialists of all liability is apparently also being contemplated, in hopes that they too will be more likely to share their experiences — although they would evidently still be subject to the CADL, unless a Supreme Court challenge rules the CADL unconstitutional. Given the date of this message, it is not clear whether the CADL applies to April-Fools' Day messages — but it would seem highly likely. Although such messages always constitute risks unto themselves, they might be considered beyond legal liability if they are suitably tasteful. (We hope this one is.) [Please observe that we have been extremely careful not to violate the CADL in writing this note. PGN]
According to BBC Radio, British Prime Minister Tony Blair has taken a personal interest in the year 2000 problem, or "Millennium Bug" as it is becoming known in UK media circles, to match the "Millennium Dome" being built to celebrate the rollover to 2000. An industry minister has been delegated to oversee a UKP 70 million (US$ 110 million) project to train people to fix year 2000 bugs. The average amount to be spent per trainee is apparently around UKP 1300 (US$ 1900). The minister, when interviewed, indicated that she thought this was adequate to get people up to speed on the problem. It was not clear from the 15-minute item whether the people to be trained are existing programmers and analysts, or new to the computer industry. UK unemployment is running at about 6%, and Government statistics do not show how many of these people have the potential to become experienced Cobol and RPG programmers in eighteen months. In the interests of balance, a professor from the University of Reading was interviewed, stating that in his opinion, 99.99% (sic) of systems would be unaffected. He did not expand on this, so we don't know if he meant by number of CPUs, dollar value of installed base, or megabytes of data stored. The overall impression given by the item was that either the politicians, or the journalists, or both, may not have completely grasped all the subtleties of the issue. Regular RISKS readers may be forgiven for not falling off their chairs at this revelation. Nick Brown, Strasbourg, France.
The *Guardian* ran a story on 25 Mar 1998 on some of the effects of the Y2K bug in the aviation industry. Some of the more interesting points include the following; - Parts of the world could be declared no-go areas including Africa, South America and parts of the United States. - Lloyd's say they will withdraw cover for airlines that did not adapt systems before 2000. - The U.S. Federal Aviation Administration has said 20 of its computer systems are not ready to cope with the changes. - The International Federation of Airline Pilots have been holding meetings to discuss a possible boycotts of some airports. But they commented that in some parts of the world there was no probability of being hit by the bug because they are so far behind the rest of the world that they don't even have basic computer systems. As a footnote they give the air-crash loss figures for 1997 at 375 million pounds, with 22 crashes involving western built aircraft. The figure so far for 1998 is 166 million pounds. [A completely unrelated risk involves finding you don't have any floppy discs to transfer the risk submission from home to work, as all the floppy discs used for that purpose are still at the office...] Mike Ellims - Pi Technology - mike@pires.co.uk www.pi-group.com - +44 (0)1223 441 256
Experts predict financial software may go haywire if the Dow Jones Industrial Average tops 10,000. Many software programs are designed to handle only four-digit Dows, says one software designer, who says that concern over the D10K problem soon "will spawn the usual parade of opportunists" to fix the bug. (*Wall Street Journal*, 26 Mar 1998; Edupage, 26 March 1998) [... "if" it tops 10K? Is anyone dow-ten' that Dow10K will occur? PGN]
This spring's round of clock complications prompted me to dig through the archives to look for an article I remembered on this topic (http://catless.ncl.ac.uk/Risks/18.03.html#subj2). I came in this beautiful Summer Time morning (after paying my bill for weekend airport parking which overcharged me by one hour - but I digress) to find all our Linux boxes running with the correct (Summer) time. I rebooted my Linux workstation to NT, and manually set the time forward one hour. On rebooting to Linux again, the time was again advanced by one hour. Since Bruce Wampler didn't draw any conclusions in his article, I thought I'd try. Our Linux boxes are configured to regard the CMOS clock as permanently set to UTC. Since Linuxes understand the Summer Time rules our machines happily migrated. However, NT (whether shifting zones manually or automatically) seems to insist on keeping the CMOS clock set to local time. Obviously, a reboot from Linux to NT and back to Linux is going to leave the latter one bogus hour ahead as NT has advanced the CMOS clock as well. It's possible that Linux can be told to regard the CMOS clock as local (and possibly to update it when necessary), but this suggests all sorts of horrible race conditions: what if a Linux is rebooted shortly after it's set the CMOS clock forward? How does it know it's done it? If it marks the file system in some way, what if one reboots from a different volume? Quite clearly, the only sensible option is to have the hardware clock run in contiguous UTC, with the software making timezone interpretations. Perhaps unsurprisingly, this is the thing which NT cannot be persuaded to do. A colleague suggests that backwards compatibility requires a local-time CMOS clock for old applications; I can't think of any other explanation. My dual-boot machine has three SCSI disks, so that the NT and Linux environments are kept as separate and immune from interference as is possible. Even so, they manage to interfere over the only other fragment of mutable hardware state in the entire machine, a few bytes of battery-backed RAM. I just wanted to be the first to report this spring's set of date complications. (Any earlier messages with dates stuck on GMT don't count...) Nick Rothwell, CASSIEL http://www.cassiel.com
With $4.7 billion budgeted this year and next for solving the "Year 2000" problem (when many computers will be unable to distinguish in which century they are crunching numbers), the current progress report from federal agencies is: only 35% of computer software systems critical for agencies to perform their missions have been checked and fixed, with 3,500 critical systems remaining in need of attention. In testimony before two subcommittees of Congress, an official of the General Accounting Office summed up the situation by saying: "It is unlikely that agencies can complete this vast amount of work in time." No one knows the full scope of the problem, because it is not possible to identify which systems are in fact critical: a seemingly minor system will be critical if major systems will not run without it. (*The New York Times*, 19 Mar 1998; Edupage, 19 March 1998}
Microsoft EXCEL version 6.0 ("Office 95 version") and version 7.0 ("Office
97 version") believe that year 1900 is a leap year. The extra February 29
cause the following problems.
1) All day-of-week before March 1, 1900 are incorrect;
2) All date sequence (serial number) on and after March 1, 1900 are incorrect.
3) Calculations of number of days across March 1, 1900 are incorrect.
The risk of the error will cause must be little. Especially case 1.
However, import or export date using serial date number will be a problem.
If no one noticed anything wrong, it must be that no one did it that way.
[If Y2K brings you back to 1900, that will be an added goody. PGN]
Someone in Vice President Al Gore's office staff moused the wrong icon, resulting in a letter to U.S. Sen. Daniel Moynihan (D-NY) congratulating him on the birth of twins, instead of a letter congratulating him on his 71st birthday on 16 Mar 1998. "Tipper joins me in sending our warmest congratulations and best wishes to you. We know that everyone close to you shares the excitement of the new additions to your family." [signed "Al".] A new letter followed when the mistake was reported. Tony Bullock, Moynihan's chief of staff, said that "Sen. Moynihan sent a note to Gore's office saying that in 71 years he never had a birthday present that gave him so much joy or laughter." [Source: 1998 Nando.net and The Associated Press, 22 Mar 1998, http://www.nando.net/newsroom/ntn/politics/032298/politics7_11530.html] [Twins, eh? A Moyninhand is worth two in the Bush Administration. PGN]
Ronald Rivest has posted an interesting new model for maintaining
confidentiality without using encryption:
Chaffing and Winnowing: Confidentiality without Encryption
Ronald L. Rivest
MIT Lab for Computer Science
March 22, 1998
See <http://theory.lcs.mit.edu/~rivest/chaffing.txt> for full details.
The method has the following key points:
* Sender and receiver desiring confidential communications agree on a
basis for computing message authentication codes (MACs);
* Sender breaks message up into packets and authenticates each packet
using the agreed-upon MAC algorithm.
* Sender introduces plausible "chaff" text, comparable to true message,
and generates random MACs for these packets.
* Receiver with authorized method for verifying MACs can distinguish
real packets ("wheat") from chaff by checking MACs and discarding chaff.
* Eavesdroppers, lacking a method for authenticating MACs, cannot
distinguish wheat from chaff.
This method of enhancing confidentiality would not seem to qualify for
regulation under the Export Administration Regulations of the U.S.
Department of Commerce, nor would current proposals by the FBI and other
elements of the Administration for mandatory key recovery appear to be
applicable.
M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education, International
Computer Security Association (Carlisle, PA) <http://www.icsa.net>
[Ron Rivest has a later version of the document than that which Mich saw
when he wrote this, and has added some further clevernesses. This is
really a very nifty piece of research. Incidentally, Ed Felten notes that
he found a potential inference exploitation by monitoring packet
acknowledgements, and has a fix that does not seriously detract from the
advantages. PGN]
[Multiply forwarded, original author apparently lost. PGN]
The April 9 _New York Review of Books_ has published a long special
supplement, "The Fall of TWA 800: The Possibility of Electromagnetic
Interference," by Elaine Scarry, a noted author and Harvard professor:
http://jya.com/twa800-emi.htm (128K with 3 images)
The article closely examines the possibility of electromagnetic interference
in TWA 800's controls, comm, and black boxes by activities of the ten US
military planes and ships in the vicinity which were heavily equipped for
electronic warfare and were conducting tests of the gear.
It is reports on what is publically known about the EM armaments of planes
and ships in the vicinity, about secret EM weapons and defenses, the several
dozen military and commercial planes that have crashed due to EMI, military
studies of long-standing EM hazards which will not be released to crash
investigators, current research in EMI and what scientists in the field
think about the possibility of EMI causing the fall of TWA 800.
It calls for the military to release its classified EMI research to NTSB
investigators, and short of that, for the servicemen and women on the planes
and ships at the scene to tell what they know. It asks Congress to order
military cooperation.
<L.Wood@surrey.ac.uk>PGP<http://www.sat-net.com/L.Wood/>+44-1483-300800x3641
Here is a memo sent to me privately [slightly edited for clarity]: The following Phone Scam Alert was reported in Canada by IM, We need to be aware of this same situation in the US. A person receives a telephone call from an individual identifying himself/herself as a Technician who is running a test on the telephone lines. They state that in order to complete the test, you should touch nine (9), zero (0), pound sign (#) and hang up. By pushing 9-0-# you end up giving the individual that called you access to your telephone line and allows them to place a long distance call, which appears on your bill. This works best with computer based telephone systems such as the one in Baltimore. Apparently, this scam has been originating from local jails and prisons. Be cautious of this type of requests for people claiming to be Phone Techs, Copier Techs, and Fax Repair persons.
Earlier this month, a Cornell University organization spammed the campus with what amounted to 9GB of mail in the span of a few hours. The organization legitimately obtained a list of the e-mail addresses of approximately 6100 on-campus students. They proceeded to send out a message with the entire block of addresses in the To: field, creating a 290K header. This message provoked four angry replies to the entire group, 290K header intact. Needless to say, the incident caused a severe spike in disk usage on the two Cornell postoffice machines. Anyone care to wager how long it will be before this list is in the hands of some commercial mass-mailer? James Byers - jwb19@cornell.edu - http://www.people.cornell.edu/pages/jwb19
The Journal of Computer Security
CALL FOR PAPERS
Research in Intrusion Detection
There has been a recent resurgence in efforts within the intrusion-detection
research community to investigate and extend intrusion-detection technology
to larger distributed computing environments, including work to address such
issues as scalability, interoperability, distributed correlation, dynamic
deployment, and autonomous operation. Among such efforts has been work
involving the cross-pollination of intrusion-detection research with other
communities, such as the information retrieval and network management
communities. In addition, interest has arisen in applying
intrusion-detection technology to new problem domains, such as fraud
detection in financial transactions and operations monitoring of
telecommunications infrastructures.
This special issue seeks papers that describe research beyond the scope or
orthogonal to what the commercial intrusion-detection community is producing.
The intent is to capture results from key efforts in the field, and to
understand the directions and motivations that are driving current and future
research in this area. Papers are solicited on all aspects of intrusion
detection, including the extension of intrusion-detection techniques to new
problem domains, as well as the application of other techniques to intrusion
detection. Suggested topics include, but are not limited to
o Active response capabilities and cooperative decision support
o Cooperation policies and distributed correlation across administrative
domains
o Cross pollination of intrusion-detection techniques and applications
with other disciplines
o Formalization of activity modeling
o Integration into large scale environments, including efficient methods
for high-volume event analysis
o Integration of intrusion-detection capabilities into existing network
services, infrastructure, and management frameworks
o Interoperability and reusability among intrusion-detection modules
o Service-oriented intrusion-detection architectures (including work
toward supportive services such as intrusion-detection management,
dynamic registration, event collection, results interpretation)
The selections for this special issue will consist of high-quality original
unpublished research, case studies and implementation experiences. The full
Call for Papers is available at: http://www.csl.sri.com/jcs-ids-call.html ,
with papers due by 15 Jul 1998.
Editor of the Special Issue: Phillip A. Porras <porras@csl.sri.com>,
Computer Science Laboratory, SRI International, 333 Ravenswood Avenue
Menlo Park CA 94025-3493; phone: 650-859-3232, fax: 650-859-2844
Please report problems with the web pages to the maintainer