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…
[via Dave Farber <farber@cis.upenn.edu>... Many thanks to Dave's IP! PGN] > Late Wednesday night EPA shut down its entire Internet services, including > its web site and staff email. > Our conclusion is that there is no rationale for the unprecedented > shutting down of the EPA web site and email services, cutting off a major > means for the public to communicate with EPA. There is no question that > EPA has computer vulnerabilities, but these could have been resolved with > good computer management. In the meantime, Rep. Bliley (R-VA), the chair > of the House Commerce Committee, basically held a gun to EPA's head, > effectively telling EPA to shut down its site or it would put information > out about security risks, making it easier for the public to hack EPA's > site, instead of helping EPA make fixes. This does not exonerate EPA. > EPA has known about its computer vulnerabilities for some time and has > done little to fix the problems. Despite the computer problems at EPA, > there was no "crisis." The General Accounting Office never recommended > shutting down the EPA site, but Bliley, who has done the bidding of > powerful special interests, has acted to thwart public access. > THE STORY: > Some months ago Rep. Thomas Bliley (R-VA), the chair of the House Commerce > Committee, requested the General Accounting Office (GAO) to do a computer > security audit at EPA. As the audit was coming to a close, GAO was > required to share the information with EPA. But, reportedly, Bliley was > upset since he didn't want EPA fixing the problems. Rather, he wanted to > bash EPA. He required GAO to give him a copy of the letter to EPA and > then, it is rumored, he leaked some portions to the press, making the > problems at EPA sound horrendous. > GAO did, however, find "serious and pervasive problems that essentially > render EPA's agency-wide information security program ineffective." The > problems at EPA mostly dealt with bad to poor computer management: > ineffective firewalls; lack of controls (e.g., passwords); logs that > didn't capture hackers; computer doors that had been left open. GAO found > EPA's "vulnerabilities...have been exploited by both external and internal > sources." It appears that GAO was able to take control of the router and > then capture the password of anyone logging on to the system. > GAO does not have evidence of data being tampered with or violations of > trade secrets or enforcement data. In some cases where there were > violations, it resulted in criminal investigations. And while there are > big problems, GAO never recommended that EPA shut its web site down. (In > fact, GAO has found computer security problems at other agencies, such as > State Dept, but it appears no agency has completely and this thoroughly > cut off its Internet connection and email services.) > Bliley planned a hearing today (2/17) on EPA computer security and had > asked GAO to testify. EPA raised concerns about holding the hearing. > Reportedly, Bliley gave EPA an ultimatum: shut down the EPA web site and > all email services or the public would hear about how to hack the EPA web > site. EPA decided to shut down their Internet services last night. > Bliley postponed the hearing but called a press conference at 1 p.m. on > Friday. At the press conference, Bliley released the GAO testimony and > supported EPA's decision to shut down the web site. EPA claims it was > disappointed that it had to shut down. > According to folks in the White House, EPA is quickly trying to put the > public web site back up and sever its connection to the internal systems. > It is not clear when this will happen. > There are many issues that this "crisis" raises, but two stick out. > First, if EPA had security violations, why didn't Bliley give EPA the time > that is needed to fix the problems that GAO found? Why did he hold a gun > to EPA's head? Even if there were computer security problems, it could > have been handled in a manner that did not disrupt public access to the > agency and did not create a "crisis." > This raises questions about Bliley's objectives. Maybe it is a > coincidence that a number of his campaign contributors are regulated by > EPA. For example, a large grouping of contributors are from the mining > and electrical gas sectors, which for the first time will need to report > to EPA on toxic releases. Some of his larger contributors are listed as > major polluters. Bliley is the same person who pushed the terrorism > argument last summer as a reason to withhold public access to information > about chemical hazards in our communities. Instead of improving public > access, Bliley has taken a course of thwarting EPA and, hence, public > access. > Second, EPA has known for many years that it has computer management > problems. Inspector General reports since 1997 have raised concerns, but > little has been done to fix the problems. When GAO showed EPA it had > problems, why didn't it immediately address these problems? > EPA Administrator Browner took the helpful step to create an Information > Office within EPA. But since then no one has been appointed to run the > office. Increasingly, the Office is proving to be less than useful, maybe > even a major disappointment. Why has the Office not taken the leadership > to develop a comprehensive information plan that covers computer > management issues? > Rick Blum P: (202) 234-8494 > OMB Watch (CFC #0889) F: (202) 234-8584 > 1742 Connecticut Ave NW Em: blumr@ombwatch.org > Washington, DC 20009-1171 > Web: ombwatch.org > Right-To-Know Network: www.rtk.net
In what was billed as the first live online interview with a sitting U.S. president, CNN's chat with President Clinton turned kinky when a computer security consultant assumed Clinton's identity and changed his response to: "Personally, I would like to see more porn on the Internet." The consultant said guessing the president's nickname was an "easy trick," and that "I hope this harmless prank has served to let CNN know that this system is insecure and needs to be overhauled before someone does actual harm to them or one of their guests." Such security flaws can easily sabotage New Media journalism if not fixed, he added. [CBC News 16 Feb 2000 http://cbc.ca/cgi-bin/templates/NWview.cgi?/news/2000/02/15/online000215; included in RISKS with permission from NewsScan Daily, 17 Feb 2000. NewsScan Daily is underwritten by IEEE Computer Society and Arthur Andersen, world-class organizations making significant and sustained contributions to the effective management and appropriate use of information technology. NSD is written by John Gehl and Suzanne Douglas, editors@NewsScan.com.]
On 17-18 Feb 2000, America West Airlines canceled 86 flights, due to the failure of their flight-plan computer system. (Associated Press item, 18 Feb 2000; PGN-ed) [This seems like a major consequence for a relatively minor system. GD]
A fire in a switching station interrupted phone service for large portions of NTL's phone customers in Nottingham, England from 7pm on 16 Feb 2000 through most of 17 Feb 2000. Dave Weingart, Randstad North America <dweingart@chi.com> 1-516-682-1470
CNET reported that H&R Block's online tax-filing service exposed at least 50 customers' sensitive financial records to other customers over the weekend of 12-13 Feb, prompting the company to shut down the system on 15 Feb. Web-based registered users signing on were given access to someone else's data. This was the second time in two weeks that H&R Block's widely used "Do-it-yourself" Net filing service had to be shut down. [Source: Courtney Macavinta <courtm@cnet.com>, CNET News.com, 15 Feb 2000, URL: http://news.cnet.com/category/0-1005-200-1550948.html, PGN-ed] [The risks are obvious. The safeguard is less so. Certainly civil or criminal penalties cannot prevent errors. GD]
I recently changed jobs and moved, so I called my previous employer to give them my new address. They said they would also tell Great West (401K company; 'individual retirement plan' to people outside the US) about the change of address. Yesterday I got snail mail from Great West; a confirmation of my account imploring me to examine the information carefully and report any errors to them. I guess this is their odd 'change of address' confirmation. Unfortunately the mail they sent me contains: my name, birthdate, social security number (SSN), sex, marital status, account number, the mutual funds to which I have made contributions - and the percentages of the contributions. I called the 800 number to complain about their appalling lack of security for personal information and was greeted by a telephone system which said I could gain online access by pressing '2' - which I did. I was then asked to enter my SSN, which I did - and was then told that a PIN would be mailed to me. I wasn't required to confirm anything (not that it would have mattered, because I had all the confirmation information right at my fingertips). Following this, as most automated systems do, it hung up on me. I then called back and got to speak with a customer service representative; I briefly told him why I was calling and then he had the audacity to tell me he wanted to confirm some information - my name, birthdate and SSN! I was able to talk with the account representative for the company where I previously worked and she didn't seem to see the gravity of the situation, so I eventually got to speak with her boss, Nancy Lynch. Nancy seemed more appreciative of my concerns and said she would bring this up in a meeting scheduled for 2000.02.21 and call me back. From what I gather, no one at this company has even thought about these issues before - which scares the hell out of me when I think about the amount of money they must be maintaining. I was assured that online access to my account would not allow any transfers out of the account, but heck... who needs online access when Great West will gladly send the key (i.e. all the confirmation information) to the intruder's mailbox! If I maliciously changed someone else's address, I could gain access to their account through the phone system and presumably cash out their account without them even knowing it. I wonder what other privacy gems are lurking out their with financial companies! t.hutt@world.net.att.net
Under certain circumstances, a web server can force an IE client to serve up the contents of a file on a local hard drive. The server needs to know/guess the name of the file to be retrieved. The vulnerability only exists if you have Active Scripting available for the security zone (yet another reason to turn it off!) MS says "The vulnerability exists because it is possible, under very specific conditions, to violate IE’s cross-domain security model in order to allow a web site to read data that it should be prevented from reading." An interesting feature is that if you try to install the patch on a machine running IE 4.01 with SP1, the install states that the patch isn't needed (when in fact it really is). The only solution is to "upgrade" to a newer version of IE. Although MS warns of this on their web page, I wonder how many people will get a false sense of security when told they don't need the security patch. See http://www.microsoft.com/technet/security/bulletin/ms00-009.asp --Jeremy
I heard more than one reader pronounce "DoS" to rhyme with "sauce" — and sound just like "DOS". I can only imagine the confusion that this caused with listeners. The risk? One might argue this shows a lack of technical education in the media. But an equally strong argument can be made that the fault lies with the composers of the news releases, for not explaining the jargon — or maybe even for not realizing that this is jargon, and not common knowledge. Ken Cox kcc@research.bell-labs.com
And there's always the other side [Re: ZDNet comment in RISKS-20.79]: > An Open Letter to Microsoft Customers on Windows 2000 > From: Jim Allchin, Group Vice President, Platforms Group, Microsoft Corporation You may have seen reports in the media claiming that Windows 2000 contains over 63,000 defects. I'd like to assure our customers that these reports are inaccurate. Microsoft is committed to delivering high quality products, and we believe Windows 2000 is the most reliable operating system Microsoft has ever shipped. In fact, the technical press, industry analysts, and our customers have already spoken. a.. There have been more than 20 technical reviews of Windows 2000, and in all of them Windows 2000 received very high marks in the area of reliability. b.. Analyst studies show Windows 2000 to be significantly more reliable than any previous version of Windows ever. c.. To ensure we received the maximum testing coverage possible before releasing we shipped over 750,000 beta test copies of Windows 2000. d.. Many small businesses like CenterBeam and WFofR as well as hundreds of enterprises such as Ford, Wells Fargo, Motorola, and Prudential are currently rolling out Windows 2000 across their infrastructure. e.. Windows 2000 has now been fully deployed in many businesses including Stride Rite and Sears Homelife. f.. Additionally, Windows 2000 is driving many of the world's major websites, including Buy.com, Barnesandnoble.com, Dell.com, Microsoft.com, Monster.com and large ISPs such as DataReturn, and Digex. So does Windows 2000 have 63,000 defects? The answer is a flat no. There was an internal development paper that described a broad set of focus areas for the team that mentioned the 63,000 number. However, without understanding our development process (which isn't described in this paper) reporting such a number is totally meaningless when taken out of context. First, we track many issues internally in our "bug" database, including feature requests that someone may have mentioned or dreamed about, potentially confusing phrases in the documentation, performance improvement ideas, etc. - most of which are clearly not bugs in the classical sense. We track virtually everything mentioned by testers (internally or externally). These include feature requests, potential problems, or real problems. We also track any place in our code where we think we can improve an algorithm. This does NOT mean that there is a bug. In fact, it is often the case the code is marked so that it can be reviewed in the future for performance or feature enhancements. We also have a special advanced source code analyzer that we use. This tool generates a significant number of false positives (it thinks the code should be changed, but in fact it should not be). But, we track them all. The only way to be sure is to look at each hit and see if the issue is real or not. We love this tool. It helps us improve our code for readability and it can find bugs that our testing may not find. We also track our test code. There are over 10 million lines of test code that can also have improvements, potential bugs, etc. that we track in the same database. So, we track together test code, shipping code, and future code for the next release (we always have future projects cranking out code long before the previous release ships). Technically, we keep all of this information in a single tracking system and simply query for the kinds of information we want. At the end of every release we need to clean up our database and code since it ends up accumulating lots of random data. The internal paper discussed doing this clean up. Will customers run into bugs in Windows 2000? We worked harder than ever to ensure they would not. Windows 2000 is the highest quality product we have ever released-just ask any one of the thousands of satisfied users who have experienced Windows 2000 so far. We are very proud of Windows 2000's quality and our relentless pursuit of the highest quality software in the world. Thank You, Jim Allchin Group Vice President, Platforms Group Microsoft Corporation
BKVRPRNG.RVW 20000111 "Virtual Private Networking", Bruce Perlmutter/Jonathan Zarkower, 2000, 0-13-020335-1 %A Bruce Perlmutter bruce@ispb.com %A Jonathan Zarkower %C One Lake St., Upper Saddle River, NJ 07458 %D 2000 %G 0-13-020335-1 %I Prentice Hall %O +1-201-236-7139 fax: +1-201-236-7131 %P 268 p. %T "Virtual Private Networking: A View From the Trenches" The aim of the authors is to make this book different from others in the Virtual Private Network (VPN) field. In this they have, to a certain extent, succeeded. The book does not merely rehash old approaches, analogies, and illustrations. While this determined novelty does not always work, and sometimes gives the book a ragged feel, there is a freshness to it that is engaging. Perlmutter and Zarkower also wanted to make the book fun: they don't always succeed, although their humour remains light throughout, and never descends into the heavy sarcasm that befalls most who insist on larding their books with jokes. The levity is amusing, but it isn't really illustrative. The text also aims at a rather unique audience. As well as presenting the concepts to business people needing a basic understanding, the material emphasizes the ability of the Internet Service Provider (ISP), and particularly the small one, to offer VPN technology as a value added service. This means that the book looks at both sides of the picture, and the view thus generated is both interesting and useful. Chapter one offers a good introduction to the basic concepts. The evolution of networking adds a depth of understanding to this prelude in chapter two. (I would note that the authors suggest cable modems and Digital Subscriber Line [DSL] technologies can be used in conjunction with VPNs in order to create a high speed connection between offices. It should be pointed out that both cable systems and the most common form of DSL have an inherent asymmetry of bandwidth that prevents this usage.) The business case for VPNs is made carefully and realistically in chapter three. Tunneling is discussed in chapter four, although some ends are left loose. An example of a problem with encapsulating Appletalk over PPTP (Point to Point Tunneling Protocol) seems to beg the question of whether the application can be made to work. Chapter five is not simply a list of available products, but an outline of the types of VPN components and devices that can be used. Considerations to be made when choosing, and getting ready for, a VPN are brought forward in chapter six, while the ways that ISPs can offer service are examined in chapter seven. Chapter sight closes off with a realistic look at new technologies that will soon be affecting VPN decisions. Within the book there are a number of boxed items. These are variously scenarios, sidebars, comments, or other material entirely, and it isn't always clear which they are intended to be. Many of the scenarios are extremely short, and really don't explain anything. These materials should not necessarily have been excluded, but more thought could have been given to their purpose, and whether or not they fulfilled it. This is a practical and realistic guide to the reasons for, and construction of, a Virtual Private Network. Users (and particularly small to medium business users) and ISPs alike will benefit from the explanations herein. copyright Robert M. Slade, 2000 BKVRPRNG.RVW 20000111 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
SAFETY & RELIABILITY OF EMBEDDED SOFTWARE SYSTEMS
Special Issue of Quality and Reliability Engineering International
(Issue 6, December 2000)
Wiley InterScience
CALL FOR PAPERS [abridged for RISKS. PGN]
This special issue will cover techniques for the development of dependable
systems containing embedded software and the assessment of their levels of
dependability.
Submission of abstracts: 31st March 2000
Submission of completed papers: 31st July 2000
Final versions of accepted papers: 15th September 2000
[Possible topics:]
- Techniques for fault avoidance: requirements capture, HCI design, formal
specification methods, validation and verification.
- Techniques for fault removal: inspection, testing and system trial.
- Techniques for fault tolerance: redundancy, design diversity, ``belt and
braces and a piece of string''.
- Techniques for dependability assessment: ``operational profile'' and
definition of realistic operating environments for system trial, data
collection, statistical analysis, quantitative demonstration of achieving
targets, dependability apportionment, certification of dependability to
conform to industrial or governmental standards.
[... For more info, contact]
Peter Mellor, Centre for Software Reliability,
City University, Northampton Square, London, EC1V 0HB ENGLAND
Tel.: +44 (0)20 7477 8422 Fax.: +44 (0)20 7477 8585
E-mail: p.mellor@csr.city.ac.uk
The Wiley InterScience website is: www.interscience.wiley.com
Pete Mellor
2000 USENIX Annual Technical Conference June 18-23, 2000 San Diego Marriott Hotel & Marina San Diego, California, USA http://www.usenix.org/events/usenix2000 The USENIX Annual Technical Conference is the gathering place for like minds in the computer industry, a place to meet peers and experts and share solutions to common problems. Join us in San Diego on June 18 - 23, 2000 as we celebrate our 25th Anniversary and pave the way for future innovations. * Keynote Presentation by Bill Joy, Co-Founder of Sun Microsystems * Closing Presentation by Thomas Dolby Robertson, Founder of Beatnik, Inc. * Refereed paper presentations and Invited talks includes new work from Bill Cheswick, Rob Pike, and Margo Seltzer; the latest research results on operating systems, tools and techniques for dealing with the system infrastructure headaches, and a discussion on the Microsoft Antitrust Case by expert witness Edward Felten of Princeton University. * The very popular Freenix track returns with topics on *BSD, Linux, X11-based graphical user interfaces, and the full range of freely redistributable software. * BoFs and WiPs bring attendees together for informal reports on interesting new projects and on-going work. Fast paced and spontaneous, WiPs and BoFs discuss new ideas and novel solutions. See website for schedule and to reserve WiP slots. For detailed technical and tutorial programs and online registration: http://www.usenix.org/events/usenix2000 Sponsored by USENIX, the Advanced Computing Systems Association.
October 24-26, 2000, Boston, Massachusetts USA (tentative) Sponsored by the IEEE Computer Society Organized by the CERT* Coordination Center, Software Engineering Institute General Chair: Tom Longstaff, Technical Manager of R&D at the CERT/CC ISW 2000 is the third in an ongoing series of IEEE-sponsored research workshops in survivability. The Information Survivability Workshops provide a forum for researchers, practitioners, and sponsors to discuss the area of survivability, the nature of the unique (and sometimes not-so-unique) problems associated with survivability, and promising approaches to finding solutions to these problems. An emerging discipline, survivability extends the goals of traditional computer security to encompass concepts, methodologies, and tools that support the ability of a system to continue to fulfill its mission in the presence of attacks, accidents, and failures. The goal is not only to thwart attackers whenever possible, but also to build systems that are robust in the presence of attacks that cannot be completely repelled. [...] The ISW 2000 call for papers will be distributed, within the next few weeks, to the same mailing lists as this announcement. The call for papers will also be posted at the ISW web site: http://www.cert.org/research/isw.html Proceedings from previous workshops (ISW'97 and ISW'98) are available at the same web site. * CERT and CERT Coordination Center are registered in the U.S. Patent and Trademark Office.
Please report problems with the web pages to the maintainer