RISKS Forum mailing list archives
Risks Digest 27.86
From: RISKS List Owner <risko () csl sri com>
Date: Tue, 29 Apr 2014 16:27:59 PDT
RISKS-LIST: Risks-Forum Digest Tuesday 29 April 2014 Volume 27 : Issue 86 ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <http://www.risks.org> as <http://catless.ncl.ac.uk/Risks/27.86.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: Health Care: Website Fails -- Oracle Blamed (Stephanie M. Lee) It's Insanely Easy to Hack Hospital Equipment (Henry Baker) Critical Care Medicine: Gorilla my dreams? (UPMC) EHR hazards (from DKross) Mobile payment systems fail to take off with consumers (Brian X. Chen via Monty Solomon) FBI Needs to See *Enemy of the State* (Marc Rotenberg) Global Entry and Company: Worth the Price? (Seth Kugel via Monty Solomon) Remote bicycle brakes (Charles P. Lamb) "5 takeaways from Verizon's 2014 Data Breach Investigations Report" (Roger A. Grimes via Gene Wirchenko) Microsoft injects code into files backed up on their cloud (Mark Thorson) "US CERT and KB 2963983: Don't use drive-by-enabled Internet Explorer" (Woody Leonhard via Gene Wirchenko) Stanford's password policy (David Magda) Re: The sky is falling! Hackers target satellites (Erling Kristiansen) Re: heartbleed (Henry Baker, Dimitri Maziuk) Book: Vulnerability in Technological Cultures (MIT Press) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 29 Apr 2014 15:20:21 PDT From: "Peter G. Neumann" <neumann () csl sri com> Subject: Health Care: Website Fails -- Oracle Blamed (Stephanie M. Lee) Stephanie M. Lee Website fails -- Oracle blamed *San Francisco Chronicle* and SFGate.com Front page of the Business Report: D1, 29 Apr 2014 (PGN-ed) Oregon embraced the Affordable Care Act early on, and hired Oracle to lead its state health insurance exchange Cover Oregon. (The overall project cost nearly $250 million in federal funds.) The website "ended up an utter failure by all measures. Customers could not sign up without using paper applications. Last week Oregon ditched its website, and is switching to the federal exchange (which will cost another $5 million). The *Chronicle* article notes that Oracle also received another $50 million to modernize the Oregon Department of Health Services, allowing online applications for certain services. Oregon and Oracle are blaming each other. ``Despite the technical glitches, about 65,000 residents have obtained private insurance plans through Cover Oregon.'' ------------------------------ Date: Sat, 26 Apr 2014 15:25:08 -0700 From: Henry Baker <hbaker1 () pipeline com> Subject: It's Insanely Easy to Hack Hospital Equipment [FYI -- "Insane" is the right word...] [Long item truncated for RISKS. PGN] Kim Zetter, *WiReD*, 25 Apr 2014 http://www.wired.com/2014/04/hospital-equipment-vulnerable/ When Scott Erven was given free rein to roam through all of the medical equipment used at a large chain of Midwest health care facilities, he knew he would find security problems -- but he wasn't prepared for just how bad it would be. In a study spanning two years, Erven and his team found drug infusion pumps -- for delivering morphine drips, chemotherapy and antibiotics -- that can be remotely manipulated to change the dosage doled out to patients; Bluetooth-enabled defibrillators that can be manipulated to deliver random shocks to a patient's heart or prevent a medically needed shock from occurring; X-rays that can be accessed by outsiders lurking on a hospital's network; temperature settings on refrigerators storing blood and drugs that can be reset, causing spoilage; and digital medical records that can be altered to cause physicians to misdiagnose, prescribe the wrong drugs or administer unwarranted care. Erven's team also found that, in some cases, they could blue-screen devices and restart or reboot them to wipe out the configuration settings, allowing an attacker to take critical equipment down during emergencies or crash all of the testing equipment in a lab and reset the configuration to factory settings. Erven: ``Many hospitals are unaware of the high risk associated with these devices, Even though research has been done to show the risks, health care organizations haven't taken notice. They aren't doing the testing they need to do and need to focus on assessing their risks.'' Erven works as head of information security for Essentia Health, which operates about 100 facilities -- including clinics, hospitals and pharmacies -- in Minnesota, North Dakota, Wisconsin and Idaho. Essentia decided to open its facilities to a full-scale evaluation in 2012, and in a remarkable and laudable move, allowed Erven to publicly reveal some of his findings. Erven won't identify specific product brands that are vulnerable because he's still trying to get some of the problems fixed. But he said a wide cross-section of devices shared a handful of common security holes, including lack of authentication to access or manipulate the equipment; weak passwords or default and hardcoded vendor passwords like `admin' or `1234'; and embedded web servers and administrative interfaces that make it easy to identify and manipulate devices once an attacker finds them on a network. Although Erven and his team don't know whether any of these devices are connected directly to the Internet -- they plan a subsequent test to determine this -- many of them are connected to internal networks accessible via the internet. Hackers could gain access to the devices by infecting an employee's computer via a phishing attack, then exploring the internal network to find vulnerable systems. A hacker who happens to be in the hospital could also simply plug his laptop into the network to discover and attack vulnerable systems. ``There are very few [devices] that are truly firewalled off from the rest of the organization. Once you get a foothold into the network, you can scan and find almost all of these devices, and it's fairly easy to get on these networks.'' Everything Was Tested, And Most Of It Was Hackable [...] The Worst Problems [...] Hospitals Are Unaware of the Dangers [...] [Also noted by Matthew Kruk. PGN] ------------------------------ Date: Sat, 26 Apr 2014 9:11:15 PDT From: UPMC Subject: Critical Care Medicine: Gorilla my dreams? [Per request, the name of the RISKS submitter is omitted here, although that person added: ``UPMC is the biggest employer in Pittsburgh and behaves like a gorilla.'' PGN] In the why-care-about-software-assurance, e-health records breaches or legal compliance file, University of Pittsburgh Medical School, Critical Care Medicine [has posted] the following job opening: Position Description: We're looking for a full-time individual to design, build and maintain high-volume, real-time clinical data acquisition systems, including developing hardware and software solutions to interface with existing hospital systems. Operating within a multidisciplinary research team, tasks will additionally involve implementing analytics in the context of clinical decision support system. Experience: - Data modeling - Designing high-availability and high-performance systems - Documenting and communicating processes and systems - Emergency Planning - Working under minimal supervision 3 years of experience in at least some of the above areas; Minimum bachelor's degree in relevant fields. Solo designing with "minimal supervision" a software system to have privileged interface with other hospital data systems -- that doesn't present any risks! Note, while this system is to be designed to obtain "real-time clinical data," which presumably will include some e-personal health records, not a word is mentioned about credentials in security or privacy engineering or software assurance. Do they know of the minimum mandatory Federal software requirements for e-PHI security and privacy? Not mentioned here. Meanwhile, UPMC is facing a class action for thousands of people affected by a data breach, including several hundred employees whose tax refunds were fraudulently filed and re-directed post-breach. ------------------------------ Date: Sun, 27 Apr 2014 13:24:34 PDT From: "Peter G. Neumann" <neumann () csl sri com> Subject: EHR hazards (from DKross) https://www.ecri.org/Forms/Pages/PSRQ_Top10.aspx?rF=7mkfdys https://www.ecri.org/EmailResources/PSRQ/Top10/Top10PSRQ.pdf ------------------------------ Date: Tue, 29 Apr 2014 00:02:05 -0400 From: Monty Solomon <monty () roscom com> Subject: Mobile payment systems fail to take off with consumers (Brian X. Chen) Brian X. Chen, *The New York Times*, 28 Apr 2014 SAN FRANCISCO - Millions of Americans use smartphones for tasks like hailing a taxi or checking in for a flight. But for buying something in a store? That mostly remains a tech entrepreneur's dream. For years now, the promise of a mobile wallet - in which paying in person can be as simple as hitting a button on a phone - has led to a host of US startups trying to cash in. Those companies, though, have faced nearly as many hurdles as they have competitors, including the most basic ones: Many people are not aware of the new payment systems, others are confused by the many choices, and some see no benefit in the mobile option over using cash or credit cards. The hurdles have left all the payment companies scrambling to find the code for a profitable business model. And now, a feeling is growing that mobile payments systems will not replace traditional wallets, at least anytime soon. ... http://www.bostonglobe.com/business/2014/04/27/mobile-payment-systems-fail-take-off/LTYGTCqyzkZ9dOkmeTNpGN/story.html ------------------------------ Date: Tue, 29 Apr 2014 17:39:09 -0400 From: Marc Rotenberg <rotenberg () epic org> Subject: FBI Needs to See *Enemy of the State* I noted that in the cell phone privacy case today the FBI revealed that they did not know how to build a decent Tempest tested room.
MR. DREEBEN: I have anecdotal reports from the F.B.I. that that has happened, that they have looked into the question of to what extent can you protect a phone through the use of things like Faraday bags. I think one of the important things to notice, if you throw a phone into a Faraday bag, which is supposedly going to be able to block network signals, when you open it up, it has to be similarly shielded or it will pick up a signal from a cell tower, and that will wipe the phone. And the F.B.I. tried to build a Faraday room in a building that they later discovered Verizon had put up a cell tower on it, and that cell tower put out a strong enough signal to go right through the Faraday room.
At the very least, someone at the FBI should see the movie *Enemy of the State* (1998): Gene Hackman managed to construct a perfectly workable Tempest cage to inspect electronic devices without fear of disruption. ------------------------------ Date: Mon, 28 Apr 2014 23:47:37 -0400 From: Monty Solomon <monty () roscom com> Subject: Global Entry and Company: Worth the Price? (Seth Kugel) Global Entry and Company: Worth the Price? Seth Kugel, Frugal Traveler, *The New York Times*, 24 Apr 2014 Time versus money - there's no more fundamental trade-off in budget travel. Nonstop or layover, taxi or public bus? Stand in line for half-price theater tickets or buy full-price at the click of a mouse? Airports, you may have noticed, have some lines of their own. Some you can't avoid - the one forming at Starbucks at 6 a.m., for example - but others, you can, for a price. In January 2013, I decided to pay $100 for five years of immigration-line exemption through the government's Global Entry program. Instead of waiting with the masses, I could plop my passport and fingerprints onto a fast-working kiosk, and be on my way. Until I couldn't. In February, I entered the immigration area at Kennedy Airport, and, with an air of superiority that is the exact opposite of walking through business class into coach, I left my fellow passengers to the long lines and waltzed up to the kiosk. As expected, the machine quickly recognized my fingerprints. But this time it didn't like them nearly as much. It spit out a notice: My Global Entry membership had been "revoked." ... [Trying to determine *why* it was revoked, Seth checked with the JFK Global Entry office (``to no avail'') and has been waiting nearly two months (``and counting'') for an answer from the `trusted traveler ombudsman' of the U.S. Custom and Border Protection. The article continues with Seth doing a detailed comparative analysis of whether it is worth the $100 overall. PGN] http://www.nytimes.com/2014/04/24/travel/global-entry-and-company-worth-the-price.html ------------------------------ Date: Fri, 25 Apr 2014 18:10:25 -0400 From: "Charles P. Lamb" <CLamb () acm org> Subject: Remote bicycle brakes Here is another poorly thought-out product--a remote bicycle brake. It is intended for parents to control children's bicycle riding. The idea is to allow someone to, via a radio signal, apply a brake to a bicycle on remote command or when the bicycle ventures out of range. Even if it works only as intended the ability of a rider to control the bicycle by an unexpected sudden application of the break. But suppose someone other than the authorized user figures out how to block the don't brake signal to the bicycle? It could be applied purposefully when the bicycle is in the process of crossing a busy intersection or other dangerous circumstance or accidentally by EMI. Surprisingly, the inventor considers this a feature, "also, as an extra safety measure, *when anything blocks the signal* between the remote controller and the bike, *the brake is automatically applied*." ------------------------------ Date: Tue, 29 Apr 2014 10:30:52 -0700 From: Gene Wirchenko <genew () telus net> Subject: "5 takeaways from Verizon's 2014 Data Breach Investigations Report" (Roger A. Grimes) Roger A. Grimes | InfoWorld, 29 Apr 2014 If there's one security report you should read every year, this is it. Trends include rising corporate espionage, more frequent ATM compromises, and improved hack detection http://www.infoworld.com/d/security/5-takeaways-verizons-2014-data-breach-investigations-report-241488 ------------------------------ Date: Sat, 26 Apr 2014 16:55:13 -0700 From: Mark Thorson <eee () sonic net> Subject: Microsoft injects code into files backed up on their cloud Certain type of files (including .htm, .docx, .xlsx, .php) are injected with code when restored from Microsoft's cloud. Doing this without notification seems like an enormous breach of trust. Certainly extremely risky. http://www.myce.com/news/microsoft-onedrive-for-business-modifies-files-as-it-syncs-71168/ ------------------------------ Date: Tue, 29 Apr 2014 10:02:42 -0700 From: Gene Wirchenko <genew () telus net> Subject: "US CERT and KB 2963983: Don't use drive-by-enabled Internet Explorer" (Woody Leonhard) Woody Leonhard | InfoWorld, 28 Apr 2014 US CERT and KB 2963983: Don't use drive-by-enabled Internet Explorer Department of Homeland Security recommends avoiding Microsoft browser until vulnerability in IE6 to IE11 is fixed http://www.infoworld.com/t/microsoft-windows/us-cert-and-kb-2963983-dont-use-drive-enabled-internet-explorer-241467 ------------------------------ Date: Fri, 25 Apr 2014 19:18:10 -0400 From: David Magda <dmagda () ee ryerson ca> Subject: Stanford's password policy A new password policy has been released by Stanford that introduces a "sliding scale" when it comes to complexity and needed 'special characters': Students, faculty, and staff can use passwords as short as eight characters, but only if they contain a mix of upper- and lower-case letters, numbers, and symbols, according to the policy, which was published last week on Stanford's IT Services website. [=85] The standards gradually reduce the character complexity requirements when lengths reach 12, 16, or 20 characters. At the other end of the spectrum, passcodes that have a length of 20 or more can contain any character type an end user wants, including all lower case. http://tinyurl.com/lfndwrv http://arstechnica.com/security/2014/04/stanfords-password-policy-shuns-one-size-fits-all-security/ According to my math, a 20-character all-lowercase password is potentially more secure (log2(26^20) = 94 bits of information entropy) than a 10-character funny-character password (log2(95^10) =3D 65.7b). Even a 14-character all-lower password is slightly better (log2(26^14) = 65.8b). Stanford's recommendation is at least 16-characters mixed-case (log2(52^16) =3D 91.2b). Now if only all systems actually accepted arbitrary strings. [Please feel free to correct me--it's been a while since I did log2()s. =) ] [Of course, some passcodes in excess of 20 characters may have very little entropy for the attacker. For example, suppose you chose To be or not to be, that is the question. or The quick brown fox jumped over the lazy dog. The only question for the attacker might be did you truncate somewhere along the way to avoid so much typing? Combine that with the old TENEX timing attack, being able to align passwords across page-fault boundaries to iteratively detect the correctness of the nth character, reducing the challenge to a linear search, and the attacker can have a linear field day. PGN] ------------------------------ Date: Sat, 26 Apr 2014 12:30:46 +0200 From: Erling Kristiansen <erling.kristiansen () xs4all nl> Subject: Re: The sky is falling! Hackers target satellites (Grimes, R-27.85) The article is not very clear about what exactly is targeted, but it seems to be services run over communication satellites, not the satellites as such. If so, the title is rather misleading. Hacking a satellite-based communication service comes in two flavours: 1. Hacking ground equipment and/or terrestrial "tail" networks. This is no different in principle from hacking other modems, routers etc. I think this is what the article is talking about. 2. Hacking the radio link. Some systems can be jammed or even spoofed with rather simple equipment, and it is true that many systems have little or no protection against this. Jamming ( transmitting a high-enough-power signal to drown out the legitimate signal), in particular, is quite hard to protect against. Hacking the satellites themselves is a different story. Most satellite systems are designed such that you need a powerful transmitter and a large antenna to send commands to the satellite, and you need intimate knowledge of the satellite and its telecommands to do any real harm. So it is out of reach of the amateur hacker. But certainly within reach of nation states and maybe other resourceful organizations. ------------------------------ Date: Fri, 25 Apr 2014 12:29:16 -0700 From: Henry Baker <hbaker1 () pipeline com> Subject: Re: heartbleed (Maziuk, RISKS-27.85) You'll have to forgive me for sounding like an old fart, but there hasn't been any excuse for unpredictable GC performance since 1978, 36 _years_ ago: List Processing in Real Time on a Serial Computer http://home.pipeline.com/~hbaker1/RealTimeGC.html http://home.pipeline.com/~hbaker1/RealTimeGC.ps.gz Re sockets & other resources: reference counting (properly done) can be both safe and real-time, so there is once again no excuse for using an unsafe language. Unsafe programming isn't a profession, it's a sport -- much like sky diving, rock climbing, motor racing, etc. It provides lots of fun, thrills & excitement, but it shouldn't be an insurable risk. ------------------------------ Date: Fri, 25 Apr 2014 15:03:16 -0500 From: Dimitri Maziuk <dmaziuk () bmrb wisc edu> Subject: Re: heartbleed (Baker, RISKS-27.86)
You'll have to forgive me for sounding like an old fart, but there hasn't been any excuse for unpredictable GC performance since 1978, 36 _years_ ago ...
1. You'll have to forgive me for sounding blunt but tell this to Gosling and Van Rossum. I get work with tools that are actually available. The best they do is the upper bound on when, and that's "when the vm terminates". Which in the case of always-on servers is "never".
Re sockets & other resources: reference counting (properly done) can be both safe and real-time,
2.a. Not universally true: they may exist outside of your reference-counted sandbox and therefore aren't safe to delete. 2.b. The fundamental problem is - at line 10 garbage collector decides that an object is garbage, e.g. its reference counter reaches 0, - at line 20 garbage collector deletes the object and collects its resources, - somewhere in between, say, at line 15. the object's finalizer (they don't call them destructors) runs and changes the object's reference count to 1. Or makes it "accessible" if you're using java's multi-level mark-and-sweep queue. - At line 30 the whole thing crashes and burns. Or at line 20 the garbage collector sees the ovbject's not collectable and doesn't delete it -- resulting in the exact memory leak we were trying to prevent in the first place. I.e. this is not about gc *performance* even though that is a factor that isn't helping any (#1). It's about the fact that you can either have "no dangling pointers" or "place to free up resources" but not both (#2.b). You're free to choose the less "unsafe" option.
there is once again no excuse for using an unsafe language
... other than users asking for code that does what they need. ------------------------------ Date: Mon, 28 Apr 2014 14:36:50 PDT From: "Peter G. Neumann" <neumann () csl sri com> Subject: Vulnerability in Technological Cultures (Hommels et al.) Anique Hommels, Jessica Messman, and Wiebe E. Bijker (editors) Vulnerability in Technological Cultures: New Directions in Research and Governanace MIT Press, 2014 xi+382 (+4 pages of other books in Bijker's Inside Technology series) The back cover says that ``The book explores case studies that range from agricultural practices in India to neonatal intensive care medicine in Western hospitals; these cases ... illustrate what vulnerability is and does. ... [and] elucidate its ambiguity, context dependence, and constructed nature. Finally, the book addresses the implications of these analyses for the governance of vulnerability, proposing a more reflexive way of dealing with vulnerability in technological cultures.'' The book has 15 chapters from 23 contributors. ``The contributors argue that viewing risk in terms of vulnerability offers a novel approach to understanding the risks and benefits of science and technology. Such an approach broadens conventional risk analysis by connecting to issues of justice, solidarity, and livelihood, and enabling comparisons between the global north and south.'' Particularly for RISKS readers who think primarily in terms of computers and their diverse applications, I believe there is much that can be learned from this book. It is remarkably holistic (e.g., total-system oriented) and far-sighted in its treatment of the concepts and the elaborated case studies. Even though the words `computer' and `vulnerability' are not included in the index, there are copious discussions of `trust', `safety', `security', `reliability', `robustness', `resilience', and even `interdependencies'. I have a hunch that many of us will have much to learn from the collected wisdom contained in this book. Indeed, there is much that is directly applicable to computer-related risks. ------------------------------ Date: Sun, 7 Oct 2012 20:20:16 -0900 From: RISKS-request () csl sri com Subject: Abridged info on RISKS (comp.risks) The ACM RISKS Forum is a MODERATED digest. Its Usenet manifestation is comp.risks, the feed for which is donated by panix.com as of June 2011. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. The mailman Web interface can be used directly to subscribe and unsubscribe: http://lists.csl.sri.com/mailman/listinfo/risks Alternatively, to subscribe or unsubscribe via e-mail to mailman your FROM: address, send a message to risks-request () csl sri com containing only the one-word text subscribe or unsubscribe. You may also specify a different receiving address: subscribe address= ... . You may short-circuit that process by sending directly to either risks-subscribe () csl sri com or risks-unsubscribe () csl sri com depending on which action is to be taken. Subscription and unsubscription requests require that you reply to a confirmation message sent to the subscribing mail address. Instructions are included in the confirmation message. Each issue of RISKS that you receive contains information on how to post, unsubscribe, etc. => The complete INFO file (submissions, default disclaimers, archive sites, copyright policy, etc.) is online. <http://www.CSL.sri.com/risksinfo.html> *** Contributors are assumed to have read the full info file for guidelines. => .UK users may contact <Lindsay.Marshall () newcastle ac uk>. => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => SUBMISSIONS: to risks () CSL sri com with meaningful SUBJECT: line. *** NOTE: Including the string `notsp' at the beginning or end of the subject *** line will be very helpful in separating real contributions from spam. *** This attention-string may change, so watch this space now and then. => ARCHIVES: ftp://ftp.sri.com/risks for current volume or ftp://ftp.sri.com/VL/risks for previous VoLume http://www.risks.org takes you to Lindsay Marshall's searchable archive at newcastle: http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue. Lindsay 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/> . ==> 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 is no longer maintained up-to-date except for recent election problems. *** NOTE: If a cited URL fails, we do not try to update them. Try browsing on the keywords in the subject line or cited article leads. ==> Special Offer to Join ACM for readers of the ACM RISKS Forum: <http://www.acm.org/joinacm1> ------------------------------ End of RISKS-FORUM Digest 27.86 ************************
Current thread:
- Risks Digest 27.86 RISKS List Owner (Apr 29)