RISKS-LIST: Risks-Forum Digest Monday 15 October 2001 Volume 21 : Issue 69 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/21.69.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: New class of wireless attacks (Gary McGraw) Reducing risks to hospital patients (Mike Martin) Ukraine missile apparently downs Russian airliner (Hanan Cohen) SirCam redux (Gavin Scott) A risk from Excel and Outlook (Will Middelaer) Outlook for Thanksgiving (Patrick Lincoln) Billion-seconds bug (Massimo Dal Zotto) Risks of undocumented 'standards' (Lloyd Wood) Re: Ham radios in the aftermath of 11 September 2001 (Todd Jonz, Mitch Collinsworth) Re: Remote control of airliners (Alan Wexelblat) Re: Sincerely yours, *Not* Osama bin Laden? (Nick Brown) Re: TurboMedical (Dick Karpinski) Public information campaign on privacy (Ben Hutchings) Re: Hackers and others win big in Net casino attacks (R.S. Heuman) REVIEW: "The CERT Guide to System and Network Security Practices", J.H. Allen (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 15 Oct 2001 08:30:07 -0400 From: Gary McGraw <gemat_private> Subject: New class of wireless attacks Bob Fleck, a security consultant at Cigital, working with Jordan Dimov, has discovered new class of wireless attacks that can be used to gain unauthorized access to normally-protected machines on a standard wire-based internal network. Wireless networks involve installation of a wireless Access Point on a normal internal network. This Access Point is usually connected to the wired network through a switch or a hub. The attacks discovered by Cigital are based on an adaptation of a well understood network attack from the non-wireless world known as ARP cache poisoning. This emphasizes the importance of re-considering old risks in light of new technologies, something that is especially important in software-based systems! The new class of attacks encompasses: 1) the ability to monitor and manipulate traffic between two wired hosts behind a firewall 2) the ability to monitor and manipulate traffic between a wired host and a wireless host 3) the ability to compromise roaming wireless clients attached to different Access Points 4) the ability to monitor and manipulate traffic between two wireless clients Previous wireless attacks have demonstrated that wireless traffic on an 802.11b network is vulnerable to monitoring and manipulation, even when it is "protected" with WEP encryption. This new class of attacks discovered by Cigital is based on abusing the Address Resolution Protocol (ARP) which binds internal IP addresses to ethernet addresses. Mitigating the risks of these attacks is possible. The best fix involves placing a technical barrier between the wireless network and the normal wired network. This provides only a partial solution that leaves the wireless network in a compromised state, though it protects against the worst of the attack class Cigital discovered. Further risks can be mitigated through advanced design of any and all software applications that make use of the wireless network. Bob Fleck (fleckat_private) and Gary McGraw (gemat_private) For more, see: http://www.cigital.com/news/wireless-sec.html http://www.cigital.com/news/wireless/faq.html ------------------------------ Date: Fri, 5 Oct 2001 15:06:50 +1000 From: "Martin, Mike" <mike.martinat_private> Subject: Reducing risks to hospital patients Spectacular accidents to hospital patients are always newsworthy. Recent cases include a patient in the UK who died after the wrong kidney was removed, and a boy killed by a flying oxygen cylinder (RISKS 21.55). But according to Dr Brent James, Executive Director of Intermountain Health Care in Utah, the overwhelming majority of cases of patient harm are from mundane, and preventable, causes. Interviewed recently on Australia's Radio National by Dr Norman Swan, http://www.abc.net.au/rn/talks/8.30/helthrpt/stories/s380415.htm <http://www.abc.net.au/rn/talks/8.30/helthrpt/stories/s380415.htm> , James said that of 3996 cases of moderate or severe adverse drug events that his organisation identified over a ten year period, only 3.5 per cent resulted from a human error. The rest of the confirmed 4155 human errors over the period "were caught before they actually led to injury, or the patient suffered such a minor consequence that it wasn't classified as an injury". In other words, concentrating on human error will cause 96.5 per cent of injuries to be overlooked. Furthermore, James said that the majority of adverse drug events were not reported through the voluntary reporting system on which most hospitals depend, and indeed many are not being even recognised by patient care staff. Using a computer-based system to detect evidence of morphine overdoses, James found that 80 (yes, eighty) times as many events were occurring as were being reported. By using a computer system containing information about drugs' potential for allergy reactions, and that tailored drug doses specifically to each patient, his organisation has been able to cut the adverse drug event rate associated with such reactions by more than 50 per cent. A simple systems change in treatment of patients with congestive heart failure in his organisation means, James estimates, that 310 lives are being saved each year, patients who otherwise would have died. It seems people in the health system are beginning to apply principles long used by safety analysts in aviation and other industries. (James was a member of the Quality of Health Care in America Committee of the Institute of Medicine that created the 1999 report, "To Err is Human". Its executive summary noted, "Health care is a decade or more behind other high-risk industries in its attention to ensuring basic safety.") The key principles in James's attack on the problem appear to be: * focus on injuries, rather than human errors; * encourage (and indeed reward) injury reporting (and protect from victimisation); * improve systems so that it's easy to do things right and hard to do them wrong; * assign accountability for safety improvement; * measure outcomes. Use of computer technology is key to collecting and using data and instituting process control to support these principles. On top of improving patient experience and saving lives, James said, "... the old belief that quality means spare no expense, just turned out not to be a good model. A better model is do it right the first time. It looks like that could save as much as 15% to 25% of our total cost of operations." Mike Martin Sydney <mike_martinat_private> ------------------------------ Date: Sat, 13 Oct 2001 06:47:31 -0700 (PDT) From: Hanan Cohen <hanan_cohenat_private> Subject: Ukraine missile apparently downs Russian airliner While searching for early information on the Sibir Airlines TU-154 crash, I went to the website of Russian newspaper Pravda and was surprised to see that they have a special section for accidents. http://english.pravda.ru/accidents/ I think the editors of Pravda are RISKS readers! Ukraine Admits Missile Might Have Downed Airliner [http://dailynews.yahoo.com/h/nm/20011012/wl/russia_crash_dc_44.html] ``The cause may have been an accidental hit from an S200 rocket fired during Ukrainian exercises,'' Evhen Marchuk, head of Ukraine's National Security Council, told a news conference to present crash investigators' preliminary findings. The plane crash would be the second time in 18 months that Ukraine's armed forces have lost control of a live missile. Last year, four people were killed in the town of Brovary when a rocket plowed into their apartment block. The defense ministry denied responsibility for several days until rescue workers found missile parts in the rubble. ------------------------------ Date: Tue, 9 Oct 2001 14:46:34 -0700 From: "Gavin Scott" <gavinat_private> Subject: SirCam redux For the past week I've been receiving hundreds of e-mails from a user apparently infected with the "SirCam" virus. Ho-hum, old risk, nothing new. But in this case the virus has included an interesting document scavenged from the user's computer. The infected machine appears to belong to a Clinical Assistant Professor at the UCLA Department of Radiation Oncology, and the document is a 13 page Word .DOC form titled: UCLA RADIATION SAFETY DIVISION APPLICATION for the USE of RADIOISOTOPES (Human Use) and includes fields for the name, SSN, and Date-of-birth of all the personnel involved, radioactive compounds to be used, their dosages, whether the Principal Investigator has graduated from High School, and so on. Fortunately in this case the document is not filled out, and the SirCam virus is apparently "defective" in that each time it runs it is selecting the same document to send out, but of course it's not much of a stretch to imagine even more sensitive medical documents being sprayed across the Internet indiscriminately. Another example of an organization which Ought To Know Better failing in basic security, and of the tenacity of recent viruses (or perhaps the stubbornness of end-users) as UCLA's people have been unable to stem the tide of e-mail from the virus five days after having been informed of the problem (though their security people were quick to respond to an e-mail suggesting that medical documents were being distributed). P.S. 22 more copies of the virus arrived during the composing of this message. Oops, 27 now. [This risk certainly needs to be SirCamVented. PGN] ------------------------------ Date: Mon, 8 Oct 2001 13:05:38 -0700 (PDT) From: Will Middelaer <betamaleat_private> Subject: A risk from Excel and Outlook I stumbled across this risk when an astute coworker wondered why opening an apparently short e-mail took an inordinate amount of time to open, even for our slow connection to a remote outlook server. I sent him an e-mail composed of one short sentence of plain text followed by (what I thought was) a two column by ten row grid of excel cells. I put the cells into the e-mail by highlighting them in Excel, then copying and pasting them into an e-mail. What I did not know was that the e-mail message actually contained the entire 12,000 plus cells of the spreadsheet including formatting and formulas. Though it appears to contain only the 20 cells that I intended to send him, double clicking the cells in the e-mail launched Excel, which opened with a complete version of the spreadsheet from which I had selected the cells to send him. The only piece of information missing seems to be the name of the file, as it opens with a generic name. The risk: releasing quite a bit more information (plus structure of the spreadsheet itself) to an e-mail recipient to whom you intended to send only part of the spreadsheet, and the risk of an application being a bit too helpful. (Versions are Outlook 2000 Corporate or Workgroup, Excel 2000.) Will Middelaer <will.removeat_private> ------------------------------ Date: Wed, 10 Oct 2001 07:34:46 -0700 From: Patrick Lincoln <lincolnat_private> Subject: Outlook for Thanksgiving It seems that in some versions of Microsoft Outlook, Thanksgiving 2001 is marked as 29 Nov. In fact, Thanksgiving is early this year, on 22 Nov. ------------------------------ Date: Thu, 11 Oct 2001 19:56:58 +0200 (MEST) From: Massimo Dal Zotto <dzat_private> Subject: Billion-seconds bug As everybody knows, on Sep 09 01:46:40 2001 GMT the system clock of every UNIX system made the transition from 999999999 seconds to 1000000000. After having survived the millennium bug we believed that the "billion seconds bug" wouldn't happen, since the UNIX time is stored as a 32-bit integer. I have, however, been witness of a real "billion seconds bug" that hit a medical application distributed by a top company in the medical sector. (No, I won't name the company.) On September 11, a colleague told me that he and other technicians were having strange problems with an archiving application that was unable to initialize new cdroms. After a quick investigation, we discovered that the automatically generated cd label contained a UNIX timestamp that after Sep 09 01:46:40 passed from 9 to 10 characters, resulting in an invalid label not recognized by the application that was expecting a fixed-length label. An interesting side effect of this has been a sudden rise in orders of cd-rw drives that were initially blamed as the cause of the problem. Massimo Dal Zotto, Via Marconi, 141, 38057 Pergine Valsugana (TN) Italy ++39-0461534251 www: http://www.cs.unitn.it/~dz/ dzat_private ------------------------------ Date: Tue, 9 Oct 2001 17:17:23 +0100 (BST) From: Lloyd Wood <eep1lwat_private> Subject: Risks of undocumented 'standards' Andrew Tridgell is quoted as saying of the SMB protocol [http://www.linux-mag.com/2001-07/tridgell_03.html]: The protocol is so incredibly convoluted and bloated and badly designed -- there are ten ways of doing everything. You end up with these massive exchanges going on the wire between Windows 95 and NT, just because they are trying to work out exactly which sets of bugs the other guy has so they can figure out how to actually stat a file or find its size or date or something. And we've found from talking to people who work at Microsoft how much of a headache it is to maintain the damned thing and keep it secure. So, they've got to be thinking of dropping it at some stage. As also shown by Microsoft's office document formats (RISKS passim), the risk here is that an unpublished design with gradual increments and a focus on implementation interoperability at all costs leads to baroque, complex implementations, a shifting feature set, and emergent, undesirable side effects. It's like building on sand; eventually you spend all your time just shoring up the existing structure. There's a lot to be said for having published, fixed revisions of documented standards, for implementations to adhere to, in minimising such risky interactions. <L.Woodat_private>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/> ------------------------------ Date: Fri, 12 Oct 2001 22:28:33 -0700 From: Todd Jonz <toddat_private> Subject: Re: Ham radios in the aftermath of 11 September 2001 (Murnane, R-21.68) In RISKS 21.68 Richard Murnane <RichardMat_private> writes: > 570 Amateur (ham) Radio operators from 35 states and two > Canadian provinces provided auxiliary radio communications... What Richard's message didn't mention are the numerous pressures, particularly in the U.S., that put volunteer communications services like these at risk. In the U.S. the radio spectrum used for these communications is either dedicated to the Amateur Radio Service, or shared with other services. But a variety of commercial interests, from cellular telephone companies to package shippers to low earth orbit satellites operators, have had their eye on this spectrum for quite some time and never miss an opportunity to attempt a "land grab." Unfortunately, sometimes they are successful. In this age of spectrum auctions that generate revenue for the federal government, the amateur radio community must continually struggle to retain its spectrum allocations. Identical bills in the House of Representatives (HR 817) and the Senate (S 549) known as The Amateur Radio Spectrum Protection Act of 2001 would protect these allocations. These bills have a broad base of bipartisan support, with 44 co-sponsors in the House and seven in the Senate. Nevertheless, although these bills have been introduced in previous sessions of Congress, they have never made it to a floor vote in either house. Additional information about The Amateur Radio Spectrum Protection Act of 2001 can be found at: http://www.arrl.org/govrelations/arspa-backgrounder.html RISKS readers who feel inclined to contact their Congressional representatives in support of these bills will have my gratitude and, I'm sure, the gratitude of the entire amateur radio community. Todd Jonz, KB6JXT <toddat_private> When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. ------------------------------ Date: Sat, 13 Oct 2001 14:33:55 -0400 (EDT) From: Mitch Collinsworth <mitchat_private> Subject: Re: Ham radios in the aftermath of 11 September 2001 (Murnane, R-21.68) And the RISK that this points out is that if local government regulations, restrictive covenants, and tenant organization rules continue to make it more and more difficult/impossible for Amateur Radio operators to put up antennas for their stations, the day will eventually come when this nearly free backup communication system will no longer be available in times of emergencies. Hams have "been there" for their communities, nations, neighbor communities, and neighbor nations in times of trouble for many, many years. The value of their service needs to be recognized, and their right to assemble functional radio stations needs to be guaranteed rather than restricted. Mitch Collinsworth, K2VD ------------------------------ Date: Tue, 9 Oct 2001 13:09:51 -0400 From: Graystreak <wexat_private> Subject: Re: Remote control of airliners (Bellovin, RISKS-21.68) NPR had a fairly extensive discussion of the alternate-control proposal. One key element of the scheme being proposed is a weighted voting system, with weights assigned based on degree of deviation from preapproved flight plan. I regret not writing down the name of the expert interviewed (though writing while driving has its own risks :). He seemed quite reasonable and spent a good portion of the interview discussing possible failure scenarios. He noted that ground facilities such as control towers and transmission facilities are in fixed locations that are easier to secure, easier to harden, and easier to retake in the event of hostile takeover than an airplane cockpit. If all else fails, the control signal could be sent from an alternate ground site, and this is where the discussion of the deviation-from- flight-plan algorithm came in. In essence, if the plane's control computers received conflicting signals (say, from cockpit controls and from a ground station) they would give more weight to those signals closer to the original flight plan. The criminal acts of 11 Sep required significant deviation from flight plans over an extended period of time. If an order to take such a significant deviation can be overridden by another order saying "stick to plan; fly to LAX; land normally there" then you reduce the number of possible disaster scenarios significantly. Of course, this is not a total solution - we can all easily think of sequences of events that would lead to this kind of system failing. In addition, the system would need good specification in order not to interfere in standard emergency situations (onboard fire, engine failure, passenger with heart attack, etc). But a system of this sort raises the bar to hijacking substantially, requiring the acquisition and use of much higher levels of technology than simple 'box cutters.' Such technology and training is clearly not out of the reach of all criminals, but it is out of the reach of most. I am in favor of continuing investigation and testing of such systems, as they seem more directly focused on preventing known bad scenarios. By contrast, most of the responses proposed so far by the FAA and Congress seem to have little bearing on the scenarios as we understand them at this point. Alan Wexelblat <wexat_private> http://wex.www.media.mit.edu/people/wex/ CHI'02 Panels Chair moderator, rec.arts.sf.reviews ------------------------------ Date: Thu, 11 Oct 2001 14:24:04 +0200 From: Nick Brown <Nick.BROWNat_private> Subject: Re: Sincerely yours, *Not* Osama bin Laden? (RISKs 21.68) >A Filipino in Belgium ended up in jail after *receiving* a joke e-mail It turns out on reading the article that the message in question was an SMS text message sent on a GSM phone. I cannot believe that the people who (in the name of freedom of course) monitor telephone traffic are grepping SMS messages for "Osama bin Laden", on the off chance that he signs them himself. But if they are doing so, I guess they're reading this too, so "hi guys" ! Nick Brown, Strasbourg, France ------------------------------ Date: Tue, 9 Oct 2001 00:56:09 -0700 (PDT) From: Dick Karpinski <dickat_private> Subject: Re: TurboMedical (RISKS-21.68) The RISK I noticed in TurboMedical (sm) is that it instructs the applicant in exactly what lies to tell the FAA to get through. Thus it may be a RISK of FAA practices rather than of the use of computers. Dick ------------------------------ Date: Fri, 5 Oct 2001 20:04:45 +0100 From: Ben Hutchings <benat_private> Subject: Public information campaign on privacy The UK's Information Commissioner, a part of the government with which databases of personal information are supposed to be registered, is running a series of poster ads encouraging people to be careful with their personal information. For example, one ad says "When your bank rings you up asking questions, do you ever make sure it really is the bank?" While the message may be familiar to RISKS readers, it's heartening to see it brought to public attention - and somewhat surprising to those of us who consider the current government to have little regard for personal privacy. Ben Hutchings <benat_private> http://womble.decadentplace.org.uk ------------------------------ Date: Tue, 02 Oct 2001 10:32:58 -0400 From: rshat_private Subject: Re: Hackers and others win big in Net casino attacks (RISKS-21.67) Your added statement to Ken Nitz' item about illegal Internet gambling parlours ignores the simple fact that they are NOT illegal in many jurisdictions outside the US, and that US law does not apply outside the US. [Also, it was two of their sites that had been hacked, not one...] An example of the latter statement is: http://news.excite.com/news/ap/010919/20/australia-internet-defamation which is an interesting risk of publishing on the Internet where US law is NOT accepted as primary. R.S. (Bob) Heuman, Toronto, ON, Canada ------------------------------ Date: Wed, 10 Oct 2001 07:54:02 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "The CERT Guide to System and Network Security Practices", Julia H. Allen BKCGSNSP.RVW 20010728 "The CERT Guide to System and Network Security Practices", Julia H. Allen, 2001, 0-201-73723-X, U$39.99/C$59.95 %A Julia H. Allen %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2001 %G 0-201-73723-X %I Addison-Wesley Publishing Co. %O U$39.99/C$59.95 416-447-5101 fax: 416-443-0948 bkexpressat_private %P 447 p. %T "The CERT Guide to System and Network Security Practices" The preface states that the intended audience for this work is the mid-level system and network administrator. Actually, it uses the plural, giving the first indication that this text is only intended for those working in very large organizations. Chapter one is an overview of the structure of the book, along with a listing of some other resources, and a few general security definitions. Part one deals with securing or hardening computers against attack. Chapter two lists good practices for servers and workstations, providing basic guidelines. There is something of a detailed breakdown of these conventions, as well as considerations that might be useful in policy discussions. However, these are not procedures, and there is very little in the way of system detail. The reader is advised to limit services running on computers. This is a good practice, but there is nothing to indicate how to find out what services are running, nor how to limit or eliminate them once they are found. A number of assumptions have been implicitly made, for example about centralized administration policy, so even the material that is included may not be suitable for all environments. The explanations are reasonable, but rather pedestrian, and there is a great deal of duplication of material (the sections dealing with limiting services running on servers and workstations, for example, are almost identical.) Much the same is true of securing public web servers, in chapter three. Some material is quite specific (specifying the Common Log Format, CLF, for activity files) while other recommendations are vague. Deploying firewalls, in chapter four, is a bit different, in that it does contain some explanation of firewall types and architectures. Unfortunately, this text is very brief, and is padded out with unilluminating illustrations. Part two examines intrusion detection practices. Chapter five covers the preparation and setup of intrusion detection, chapter six the actual detection of intrusions, and chapter seven outlines responses to intrusions. Overall, part two is more useful than part one, since intrusion detection is a newer field, and general concepts are still helpful even if specific details are lacking. Given the complaints I have made about the lack of details, some will respond that I have, heretofore, ignored the fact that there are two appendices in the book, dealing with security implementations and practices. True, these documents exist. In terms of the security implementations, if you are using Solaris 2.x, Tripwire, Logsurfer, and Snort, the additional material may be very useful. Otherwise, it still doesn't address the lack of specifics in the book. This work does provide the security specialist, faced with responsibility for policy creation or maintenance, a handy set of checklists and some framework for the policy process. Use of the text will help remind the professional of areas to be addressed, and prevent certain aspects from slipping between the cracks. The advanced and experienced system administrator may also benefit from the volume, since he or she will likely already know system specifics for a number of the functions required, and probably has some idea of where to find information about others. However, intermediate sysadmins, with an "engineer" level certificate and a few years' work experience, are unlikely to know the details of security operations that have, usually, been seen as a specialty area. Therefore, the audience which will find this book to be useful is a rather narrow one. copyright Robert M. Slade, 2001 BKCGSNSP.RVW 20010728 rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: 12 Feb 2001 (LAST-MODIFIED) From: RISKS-requestat_private Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, send e-mail requests to <risks-requestat_private> with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomoat_private . [If E-mail address differs from FROM: subscribe "other-address <x@y>" ; this requires PGN's intervention -- but hinders spamming subscriptions, etc.] Lower-case only in address may get around a confirmation match glitch. INFO [for unabridged version of RISKS information] There seems to be an occasional glitch in the confirmation process, in which case send mail to RISKS with a suitable SUBJECT and we'll do it manually. .MIL users should contact <risks-requestat_private> (Dennis Rears). .UK users should contact <Lindsay.Marshallat_private>. => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risksat_private with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 20" for volume 20] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. Lindsay Marshall has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r http://the.wiretapped.net/security/info/textfiles/risks-digest/ . http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/ ==> PGN's comprehensive historical Illustrative Risks summary of one liners: http://www.csl.sri.com/illustrative.html for browsing, http://www.csl.sri.com/illustrative.pdf or .ps for printing ------------------------------ End of RISKS-FORUM Digest 21.69 ************************
This archive was generated by hypermail 2b30 : Mon Oct 15 2001 - 07:08:27 PDT