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…
Navy Software Dead in the Water, by Michael Stutz, 16 Jul 1998
[http://www.wired.com/news/news/technology/story/13758.html]
If you think Windows 98 is an upgrade nightmare, consider the task of adding a new combat system to a Navy cruiser. Last week the US Navy acknowledged that two prized battle cruisers (the USS Hue City and the USS Vicksburg) will be out of commission until further notice as engineers try to integrate new onboard weapons-control systems. "Microsoft comes out with upgrades every three years, and they crash all the time," said one Navy source, who spoke on condition of anonymity. "The Navy comes out with upgrades every five years, but we can't afford for our systems to have any glitches, so we have to make sure that we get it just right."
The heart of the problem lies with two new systems being built into the ships. The Aegis Baseline 6 system helps defend the vessels against air attacks, and the Cooperative Engagement Capability (CEC) system gathers and shares radar data from multiple ships. Engineers are having trouble getting the new systems to work with each other and with the ships' legacy software.
There was some discussion in RISKS-19.64,65,66 on Harvard professor Elaine Scarry's theory ({\it New York Review of Books,} 9 Apr 1998) that the TWA 800 disaster involved High Intensity Radiation Fields. An article in *Harvard Magazine*, Jul-Aug 1998, p. 11-12, shows a diagram of TWA 800 at 13,700 feet between a P3 Orion overhead at 20,000 feet and a Black Hawk helicopter and HC-130 aircraft both below at 3,000 feet. The figure also includes a C-141 and C-10 known to be nearby, and three submarines south of the crash, each at locations still not released to the public!)
We have found another Java security flaw that allows a malicious applet to disable all security controls in Netscape Navigator 4.0x. After disabling the security controls, the applet can do whatever it likes on the victim's machine, including arbitrarily reading, modifying, or deleting files. We have implemented a demonstration applet that deletes a file.
This flaw, like several previous ones, is in the implementation of the "ClassLoader" mechanism that handles dynamic linking in Java. Despite changes in the ClassLoader implementation in JDK 1.1 and again in JDK 1.2 beta, ClassLoaders are still not safe; a malicious ClassLoader can still override the definition of built-in "system" types like java.lang.Class. Under some circumstances, this can lead to a subversion of Java's type system and thus a security breach.
The flaw is not directly exploitable unless the attacker can use some other secondary flaw to gain a foothold. Netscape 4.0x has such a secondary flaw (a security manager bug found by Mark LaDue), so we were able to demonstrate how to subvert Netscape's security controls. We are not aware of any usable secondary flaws in Microsoft's and Sun's current Java implementations, so they appear not to be vulnerable to our attack at present.
Please direct any inquiries to Edward Felten at (609) 258-5906 or felten@cs.princeton.edu.
Dirk Balfanz, Drew Dean, Edward Felten, and Dan WallachWhen airbags were pushed on the industry and the public as a risk-free safety measure, none of the subsequently found dangers and costs of airbags were taken into consideration in the cost-benefit analysis. In addition to the problems described in that story, there have been the deaths and injuries of children and small adults caused by fast-inflating airbags. Airbags also increase the cost of vehicles, increase their maintenance costs, and have become an attraction to car-part thieves. Airbag supporters continue to counter with claims about lives saved by airbags, but I have never seen estimates of how many of those lives would have been saved by properly-used seatbelts. The regulatory imposition of airbags forced the added costs and risks of an automated system on a large population partly to deal with the deaths and injuries of those unwilling to use a lower-cost, lower-risk manual system. Besides the standard tale of unintended consequences --- safety measures creating their own risks — we also have here a good example of the risks of pushing sweeping regulatory and mechanical solutions for problems that have already serviceable unintrusive solutions, but ones that require a modicum of human care (cf. keeping inappropriate content away from children, keeping networked computers reasonably secure, avoiding spam relaying).
A useful page summarising many virus hoaxes can be found at:
I wouldn't normally submit my own articles out of a fetching humility on my part, ho ho. But as it happens these two address questions raised in the last Risks digest, one on the malicious mobile code consortium, the other on the TACDFIPSFKMI. So I though I might bring them to your attention. Rachel
1. CONSORTIUM PLANS TO ADDRESS MALICIOUS APPLETS
The International Computer Security Association (ICSA) has formed a Malicious Mobile Code Consortium to address the threat of hostile ActiveX controls and Java applets. The list of charter members is an A to Z of anti-virus and intrusion detection companies, including Advanced Computer Research, Axent, CA, Cybermedia, Digitivity, Dr Solomon's, eSafe, Finjan, Internet Security Systems, Quarterdeck, Security-7, Symantec and Trend Micro, with more companies expected to join. At first glance it seems a little unfair to lump carefully sandboxed Java, designed to wreak no harm, with the nightmarish security free-for-all that is ActiveX. Product development manager Larry Bridwell argues: "Even with the sandbox, - and we want it to be known that we think Sun has done an excellent job in considering security - there is occasionally a chink in Java's armor." Experts beg to differ. "As far as I know, there have been no legitimate reports of Java viruses written in the wild," says Rob Rosenberger, webmaster of the Computer Virus Myths home page. "On the other hand, it's beautifully easy to do it in ActiveX." Rosenberger cites Princeton computer scientist Ed Felton, founder of the Secure Internet Programming Laboratory, who says he's never bothered to test the security of ActiveX. "He says he'd just have to write one virus in it and they'd be done. ActiveX is child's play." The problem is one of perception: "People see Java and ActiveX as two ways to get stuff on the internet," Rosenberger explains, "you're talking about apples and oranges, but people only see fruit. Java poses a theoretical threat. ActiveX is an actual threat." While Bridwell concedes that there have been no documented cases of security breaches via Java, he says he believes such attacks are on their way. "It almost appears that we are in the infancy of malicious mobile code, just as in the late eighties we saw the infancy of viruses written in auto-executable code," he contends. "The problem is that you have increased connectivity and much larger numbers of people." Even if viruses do start getting written in Java, how much real harm are they likely to do? Most current viruses - Word macros, for example - are easily trapped and prevented, causing little more than a nuisance. Bridwell, however, says the problem is one of scale: "Our survey shows that something that doesn't cause actual physical damage to data can still cause thousands of dollars in downtime and associated costs," he says. The ICSA surveyed IT managers at 300 organizations, each with a minimum of 500 computers, two LANs and two remote connections. A single virus attack costs these companies an average of $8,000; in two instances, an attack cost more than $100,000. Maybe there is a role for the consortium after all.
2. COMMITTEE SAYS KEY RECOVERY IS TOO HARD
A Technical Advisory Committee charged with developing a Federal standard for recovering cryptographic keys has told the US Secretary of Commerce of technical difficulties that will prevent it reporting on time. That's a blow to government officials - not least FBI director Louis Freeh - who want to see key recovery made mandatory, so the government can recover encrypted information and make life difficult for organized crime. This Committee inherited those expectations from an earlier, failed attempt to mandate key escrow: the Clipper Chip (CI No 3,395). Reuters says it "obtained" the letter to Commerce Secretary William Daley. That's a little disingenuous of the wire service, since the letter is freely available from the NIST web site along with the incomplete draft of the committee's report. In spite of having published its work, though, the euphoniously named Technical Advisory Committee to Develop a Federal Information Processing Standard for the Federal Key Management Infrastructure, or TACDFIPSFKMI, says in its letter: "We believe this document is not ready to be released for public comment." The draft certainly does make fascinating reading. The most recent set of changes, made by Steve Kent, chief scientist at GTE Internetworking, clearly alters the emphasis of the document. The word 'standard' is replaced throughout by 'product'. A passage describing the consequences of not having key recovery has been softened. The document no longer states that it is "necessary to ensure" that data can be decrypted by "authorized parties". Instead, the writers say they want to establish "requirements for Key Recovery products." The document has is now not so much a detailed technical standard as a purchasing guide. Kent concurs with this interpretation: "Most of these [Federal Information Processing Standards] are used for procurement purposes... Those changes were made by the committee specifically because we wanted not to make it a policy statement." So, will the private sector also be required to adopt key recovery? "Technically a FIPS is just for Federal agencies," says Kent, "in the past, industry has latched onto some of these even if they are in no way required to do so." If the key recovery FIPS is ever completed, vendors can expect to be very strongly encouraged to build their crypto software with a back door for officers of the law. However as the Committee explained in its letter, various problems make it unlikely that TACDFIPSFKMI, or as it prefers to call itself, "Bob", will meet its July deadline. "The technical difficulties were subtle details," Kent said, citing conflicts between the separate working groups drawn together only a few months ago. But observers are skeptical. "It can't be done," says Counterpane Systems' Bruce Schneier, "but they don't know that." University of Auckland computer scientist and co-moderator of the sci.crypt.research newsgroup Peter Gutmann agrees: "The trouble is that what they're trying to do is beyond the state of the art," he says. What's more, Schneier believes the Committee with the 12-letter acronym has been given its impossible job for exactly the wrong reasons. "The US government has been telling everyone that key recovery is what industry wants. Whenever industry gets together they say they don't want it. Then the FBI steps in and says that's not acceptable." Why is Louis Freeh so anxious to be given the power to recover crypto keys? "We're not actually sure," Schneier admits, "it's extremely expensive, it's difficult, and from all that we can establish, encryption is not actually a problem in Federal investigations. You could hire a few hundred FBI agents for what key recovery would cost. It's hard to believe that some amorphous technology that criminals can get around anyway would be better than a few hundred more FBI agents." Most critics of key recovery say it is another example of unjustified government surveillance of private life on the pretext of preventing crime. "Sure, cryptography is open to misuse," says Schneier, "just like kitchen knives, ladders and the interstate highway systems. Yes, criminals can use ladders to commit a crime. But I still like having ladders." Schneier believes the government will never have its way with key escrow. Gutmann is not so optimistic. "There will be creeping law changes. First building key recovery in will be voluntary. Then it will be mandatory," he says. "What makes it hard at the moment is that there is no infrastructure. In five years, when the infrastructure is there, it will be just a matter of changing the law." Though the committee's charter does expire next month, the 22 members have declared themselves ready to carry on if their country demands. So no Son of Clipper Chip today, but the show is far from over. As Gutmann says: "The government just keeps sugar-coating the poison pill by giving it a different name."
Deputy Internet Editor, ComputerWire Inc, 150 Post Street, San Francisco,I recently wrote a paper (together with Avishai Wool), and we included a citation to RISKS. The referees and the program-committee shepherd insisted that we replace URLs by ``paper'' citations. That was a problem, since a few of the citations in the paper where collected from the Web, and some URLs will probably never be published in the traditional sense.
The program committee (and Peter Neumann) finally agreed that the following citation is appropriate for RISKS forum:
[Ris98] aims@ext.jussieu.fr (AIMS / Intel-Info).
Two known GPS jamming cases.
RISKS Forum Digest, vol. 19, no. 74, May 1998.
USENET comp.risks,
Peter G. Neumann, moderator, Computer Science Lab, SRI International,
Menlo Park CA 94025 USA.
Archived at http://catless.ncl.ac.uk/Risks/19.74.html
and ftp.sri.com in directory "risks".
However, this incident raises a more fundamental question: How do we maintain human knowledge in the age of the Internet? In previous generations, scholarly publications consisted of printed journals and books, which were kept in libraries for use of future scholars. Today this method is mostly replaced by placing the information on your home page or on your company's Web site. There is a real problem of preserving and referring to this information in the future, especially as this information may be modified (and the original is lost), moved, or disappear altogether. Companies do fail and merge, and today's Web sites may not exist 10 years from now.
Publishing on the Internet is the future, and we cannot ignore it. We need ways to maintain permanent knowledge in this new age.
My suggestion is that professional societies (like ACM, IEEE and USENIX) should provide archival services for their own publications and for other sources of scholarly information (e.g. moderated newsgroups).
The charter of professional societies should change too. They should:
The revenue of professional societies would decrease, since members would pay a flat membership fee for an unlimited access to the archives. However, the expenses would decrease too, since there will be no need for printing and mailing. Note that the refereeing process is done by volunteers, and it will not be changed. Another (small) revenue stream will be the surplus from conferences.
All members of professional societies as well as institutional subscribers (i.e. libraries) should get a periodic CD-ROM (or another ubiquitous, capacious, permanent, and cheap electronic medium) containing recent additions to the archives. This would solve the survivability and availability of the material for future scholars. The CD-ROM should include only publications and moderated material, and not unmoderated material placed by individual members.
The question of CD-ROM longevity and availability of CD players and software readers in the future is still open.
Eran Gabber, Lucent Technologies - Bell Labs.
Preliminary Program (edited for RISKS)
Fifth ACM Conference on Computer and Communications Security
San Francisco, California, 2-5 Nov 1998, Sponsored by ACM SIGSAC
For more information visit http://www.research.att.com/~reiter/ccs5
=== Monday, November 2, 1998
Tutorials Core Topics Emerging Topics
9:00-12:30 Cryptography: Theory and Programming Languages and Security
Applications Martin Abadi (DEC Systems Research
Dan Boneh (Stanford Center, USA) and George Necula
University, USA) (Carnegie Mellon University, USA)
13:30-17:00 To Be Determined Authentication Protocol Verification
and Analysis Jon Millen
(SRI International, USA)
=== Tuesday, November 3, 1998
9:00-10:00 Keynote address
Risks and challenges in computer-communication infrastructures
Peter G. Neumann (SRI International, USA)
10:30-12:00 Group key management
Communication complexity of group key distribution
Klaus Becker (R^3 Security Engineering, Switzerland) and Uta
Wille (IBM Zurich Research Laboratory, Switzerland)
Key management for encrypted broadcast
Avishai Wool (Bell Labs, USA)
Authenticated group key agreement and related protocols
Giuseppe Ateniese (USC Information Sciences Institute, USA),
Michael Steiner (IBM Zurich Research Laboratory, Switzerland),
and Gene Tsudik (USC Information Sciences Institute, USA)
13:30-15:30 Anonymity
The design, implementation and operation of an e-mail pseudonym server
David Mazie`res and M. Frans Kaashoek (Massachusetts
Institute of Technology, USA)
Panel: Anonymity on the Internet
Moderator: Paul Syverson (Naval Research Lab, USA)
16:00-17:00 Mobile code security
History-based access-control for mobile code
Guy Edjlali, Anurag Acharya, and Vipin Chaudhary (University of
California, Santa Barbara, USA)
A specification of Java loading and bytecode verification
Allen Goldberg (Kestrel Institute, USA)
=== Wednesday, November 4, 1998
9:00-10:30 Cryptography
A new public key cryptosystem based on higher residues
David Naccache (Gemplus, France) and Jacques Stern (Ecole
Normale Superieure, France)
An efficient non-interactive statistical zero-knowledge proof
system for quasi-safe prime products
Rosario Gennaro (IBM T.J. Watson Research Center, USA), Daniele
Micciancio (Massachusetts Institute of Technology, USA), and
Tal Rabin (IBM T.J. Watson Research Center, USA)
Communication-efficient anonymous group identification
Alfredo De Santis (Universita' di Salerno, Italy) and Giovanni
Di Crescenzo (University of California, San Diego, USA)
11:00-12:00 Invited talk
The development of public key cryptography
Martin Hellman
13:30-15:00 Systems
A security architecture for computational grids
Ian Foster (Argonne National Laboratory, USA), Carl Kesselman,
Gene Tsudik (USC Information Sciences Institute, USA), and
Steven Tuecke (Argonne National Laboratory, USA)
Design of a high-performance ATM firewall
Jun Xu and Mukesh Singhal (Ohio State University, USA)
A practical secure physical random bit generator
Markus Jakobsson, Elisabeth Shriver, Bruce Hillyer (Bell Labs,
USA) and Ari Juels (RSA Labs, USA)
15:30-16:30 Invited talk
Trust in cyberspace? A research roadmap
Fred Schneider (Cornell University, USA)
=== Thursday, November 5, 1998
9:00-10:30 Protocol design and analysis
A probabilistic poly-time framework for protocol analysis
Pat Lincoln (SRI International, USA), John Mitchell, Mark
Mitchell (Stanford University, USA), and Andre Scedrov
(University of Pennsylvania, USA)
On using public-key cryptography in password protocols
Shai Halevi (IBM T.J. Watson Research Center, USA) and Hugo
Krawczyk (Technion, Israel)
Cryptanalysis of Microsoft's point-to-point tunneling protocol
Bruce Schneier (Counterpane Systems, USA)
11:00-12:00 System monitoring
How to prove where you are
Eran Gabber and Avishai Wool (Bell Labs, USA)
Temporal sequence learning and data reduction for anomaly detection
Terran Lane and Carla E. Brodley (Purdue University, USA)
Steering committee chair: Ravi Sandhu, George Mason University
General chair: Li Gong, JavaSoft
Program chair: Mike Reiter, AT&T Labs, Room A269, 180 Park Avenue
Florham Park, NJ 07932-0971 USA, phone: +973-360-8349
For more information, visit http://www.research.att.com/~reiter/ccs5
BKJAVASC.RVW 980520
"Java Security", Scott Oaks, 1998, 1-56592-403-7, U$32.95/C$46.95
%A Scott Oaks scott.oaks@sun.com
%C 103 Morris Street, Suite A, Sebastopol, CA 95472
%D 1998
%G 1-56592-403-7
%I O'Reilly & Associates, Inc.
%O U$32.95/C$46.95 707-829-0515 fax: 707-829-0104 nuts@ora.com
%P 456 p.
%T "Java Security"
As the author notes, security means many different things to many different people. In the general public, Java security tends to mean browser and applet security, and the default applet "sandbox." Therefore I feel obliged to point out that this book is primarily concerned with the programming of security into systems, and the security APIs (Applications Programming Interfaces) built into the language to ease that task.
Chapter one looks at the overall security model for Java, and particularly at the invocations of programs. Basic enforcement and verification is covered in chapter two. Class loaders, in chapter three, provide the programmer with a means to specify an almost arbitrary level of security protection for a program. Chapter four details the workings of the security manager, again providing the programmer with the ability to set specific protections. The access controller is new to Java 1.2, is the mechanism that the security manager now uses to actually permit or deny use of resources, and the object calls are discussed in chapter five. Implementation of access and security policies through the class loader and security manager is covered in chapter six.
Chapter seven looks at the need for authentication over open networks, and the security provisions of digital signatures. The discussion of cryptography itself is essentially non-existent since, as Oaks notes, it is not necessary to understand it in order to use it. Those who wish to test or implement strong encryption will need to go elsewhere. Implementation of standard cryptographic protection is via security providers, reviewed in chapter eight. Some simple message digest implementations are described in chapter nine. Key management is an important part of cryptography so chapter ten deals with keys and certificates while chapter eleven reviews the handling of them. Chapter twelve looks at the functions provided for dealing with digital signatures. Specifics for encryption are listed in chapter thirteen.
Appendices deal with security tools, identity-based key management, resources, and a quick reference chart.
While the book is well written it is not light, and is probably best suited to those who are well familiar not only with Java programming, but also the internals of the language. On the other hand, dealing with security is a great way to learn the internals of a language.
copyright © Robert M. Slade, 1998 BKJAVASC.RVW 980520
This today from "Amazon.com Delivers Cyberculture" (haven't read it yet or even seen any other reviews, but have ordered it):
"The Transparent Society: Will Technology Force Us to Choose Between Privacy and Freedom?"
by David Brin
http://www.amazon.com/exec/obidos/ASIN/020132802X
"The Transparent Society" is David Brin's call for what he terms reciprocal transparency. With the Net and countless other technological wonders eating away at our privacy, worry about the erosion could cause a backlash of secrecy-- or at least the illusion of it, because the government, the powerful, and criminals will find a way to keep their eyes on us. Instead, Brin asks us to demand accountability and keep the good aspects of technology by opening windows both ways rather than building walls that don't really keep anyone out.
Warren Monroe <wwmonroe@mail.hac.com>Please report problems with the web pages to the maintainer