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…
Perhaps Target's is the first major CEO head to roll because of bad IT security; maybe other CEO's will finally "get the memo" regarding Internet security & privacy. On the other hand, I don't hold out much hope that the banking regulators "get it" yet. I've been trying to estimate the size of loss that would finally get regulators' attention; given the $trillion or so that sloshed around during the recent recession before ending up as bonuses, I'm afraid that the loss would have to be about that same order of magnitude. A major loss of this size would test just how effective those recently installed financial "systemic risk" mitigation measures really are. (I haven't checked, but I don't recall a major theft being part of the banking system "stress tests".) Target's decision to go with chip&pin is curious, since it isn't at all clear that chip&pin would have been effective against the recent attack; a Target chip&pin system would presumably protect only Target cards, while non-Target, non-chip&pin cards would still be at risk. [PLEASE check out a forthcoming Inside Risks article by Ross Anderson and Steven Murdoch, EMV: Why Payment Systems Fail, what lessons might we learn from the chip cards used for payments in Europe, now that the U.S. is adopting them too? This is in the June issue of the CACM, and will appear on 22 May <http://www.csl.sri.com/neumann/insiderisks.html> on my Inside Risks website. PGN] Elizabeth A. Harris, *The New York Times*, 5 May 2014 Target's Chief Resigns in Wake of Data Breach [PGN-pruned for RISKS] http://www.nytimes.com/2014/05/06/business/target-chief-executive-resigns.html Gregg Steinhafel, the chairman and chief executive of Target, resigned on Monday, the latest in a series of moves made by the company as it struggles to recover from last year's extensive data breach of customer information. The company's board made the announcement, saying that the resignation of Mr. Steinhafel, who had been with Target for 35 years, occurred after extensive discussions and that the board wanted new leadership. Known for promoting up through the ranks, the major retailer, one of the country's largest, said it would conduct a search for Mr. Steinhafel's successor. In the interim, it named John Mulligan, Target's chief financial officer, to be president and chief executive, while Roxanne S. Austin, a Target board member, will serve as nonexecutive chairwoman. [...]
One company recognized quite clearly that merchants need to be careful about their credit card processing and to prevent data breaches. The following appeared in one of their publications: If our efforts to protect the security of personal information about our guests and team members are unsuccessful, we could be subject to costly government enforcement actions and private litigation and our reputation could suffer. The nature of our business involves the receipt and storage of personal information about our guests and team members. We have a program in place to detect and respond to data security incidents. To date, all incidents we have experienced have been insignificant. If we experience a significant data security breach or fail to detect and appropriately respond to a significant data security breach, we could be exposed to government enforcement actions and private litigation. In addition, our guests could lose confidence in our ability to protect their personal information, which could cause them to discontinue usage of REDcards, decline to use our pharmacy services, or stop shopping with us altogether. The loss of confidence from a significant data security breach involving team members could hurt our reputation, cause team member recruiting and retention challenges, increase our labor costs and affect how we operate our business. You can find the above on page 7 of the Securities and Exchange Commission form 10-K, filed by Target Corporation in 2012. Paul Robinson <paul@paul-robinson.us> http://paul-robinson.us
Ryan Gorman, *Daily Mail*, 26 April 2014 Courtney Sanford (32-year-old North Carolina woman) was dead after slamming her car head-on into a truck while posting selfies and a Facebook update about how happy she was while listening to a Pharrell song. She died only seconds after her final post. http://www.dailymail.co.uk/news/article-2614151/The-happy-song-makes-HAPPY-32-year-old-woman-dead-Facebook-post-driving-leads-crash.html
http://www.dwheeler.com/essays/heartbleed.html Wheeler's 21-page paper considers "static analysis", "dynamic analysis", "test suites", etc. He also considers "run-time assertions" and "safer" languages. Hopefully, the Heartbleed bug will provide the impetus to implement formal methods (AKA mathematical proofs), in much the same way that the "Pentium FDIV bug" provided the impetus for formal methods in hardware design: http://www.csl.sri.com/papers/computer96/computer96.html However, Wheeler's long & thoughtful analysis obscures the simple truth about formal methods for software systems. Basically, a computer software system implements a mathematical *abstraction*, which is a formal model with axioms and rules of inference. The *implementation* of such a software system must be vetted to make sure that it faithfully follows these axioms and rules of inference. Unfortunately, proving that such a software system faithfully implements the model is *undecidable* for essentially *every interesting system*. This means that it is *hopeless* to expect any language or compiler or type-checking system to be able to a priori guarantee faithfulness *for all inputs*. The practical implication is that *dynamic checking will ALWAYS be required*, and that many/most abstraction violations can *only be detected during run-time*. A corollary of this is that *type systems are undecidable*, and that "input validation" is also UNDECIDABLE. Another corollary is that any decidable type system or decidable input validator won't be strong enough to protect you from all abstraction violations. In particular, "static analysis" can't protect you. Thus, Wheeler's "aggressive run-time assertions" is the *only* solution to catching abstraction violations. ALL FORMAL ANALYSIS IS THEREFORE "MERELY" *OPTIMIZATION*. Formal analysis *can't* be used to prove the *program* correct, it can only used to prove correct the *optimizations* that remove run-time checks. We note that test suites & fuzzers merely serve to move the discovery of abstraction violations forward in time, so that the program can be re-arranged to handle such violations in a smoother manner. The steps to safety are therefore: 1. Document *every* assumption with aggressive run-time assertions, NO MATTER HOW INSIGNIFICANT. Use higher level languages, macros, subroutines, etc., to make sure that these run-time assertions are liberally and religiously inserted. 2. Utilize *safe* optimizations to remove, or at least move out of loops, as many of these run-time checks for run-time assertions as possible. Safe optimizations may include inlining of subroutines, so that optimizations have more context to operate. That's it. *You aren't allowed to disable any run-time assertion checking unless the compiler can prove mechanically that that run-time check will ALWAYS fail*. No proof, no disabled checks. PERIOD. If this system isn't "efficient" enough for you, *get a better theorem prover* so you can *safely* remove more of these run-time checks. Of course, there will still be risks from compiler bugs, library bugs, and operating system bugs, but these will be present independent of this particular software system. (Compiler bugs are particularly pernicious, since most compilers haven't themselves followed the above advice. Compilers often implement "optimizations" that work properly only "most" of the time. Thus, it may be necessary to vet the output of the compiler *after every compilation*, since new compiler optimizations can cause new bugs in old codes.) (We also note that computer hardware—e.g., the Pentium FDIV bug -- doesn't have the luxury to fail a run-time abstraction violation check. This means that the hardware has to be simplified in such a way that human-aided mechanical a priori proofs can be obtained. As you might expect, this can be a very expensive process, but necessary for hardware.)
Dan Goodin, Ars Technica, 5 May 2014 It took just a day for the Internet-connected device to be under attackers' spell. http://arstechnica.com/security/2014/05/infecting-dvrs-with-bitcoin-mining-malware-even-easier-you-suspected/ It took just one day for a low-end, Internet-connected digital video recorder to become infected with malware that surreptitiously mined Bitcoins on behalf of the quick-moving attackers. The feat, documented in a blog post published Monday by researchers at the security-training outfit Sans Institute, was all the more impressive because the DVR contained no interface for downloading software from the Internet. The lack of a Wget, ftp, or kermit application posed little challenge for the attackers. To work around the limitation, the miscreants used a series of Unix commands that effectively uploaded and executed a Wget package and then used it to retrieve the Bitcoin miner from an Internet-connected server. Monday's observations from Sans CTO Johannes Ullrich are part of an ongoing series showing the increasing vulnerability of Internet-connected appliances to malware attacks. In this case, he bought an EPCOM Hikvision S04 DVR off eBay, put it into what he believes was its factory new condition, and connected it to a laboratory "honeypot" where it was susceptible to online attackers. In the first day, it was probed by 13 different IP addresses, six of which were able to log into it using the default username and password combination of "root" and "12345." One of the attackers went even further. After gaining root control of the video recorder, the hacker used standard Unix "echo" commands entered through the telnet interface to install a Bitcoin-mining app. Theoretically, the DVR was now solving the complex cryptographic problems required for the operators to mint new digital coins. Using packet-sniffing software to monitor the data the compromised box was sending over the Internet, Ullrich was able to determine it was connecting to a mining server that relies on large numbers of machines to carry out the work. "Throughout the day, the server periodically pushes parameters to the miner, but I haven't seen the miner return anything yet, which probably underscores the fact that these miners are pretty useless due to their weak CPUs," Ullrich wrote. "The DVR did get infected multiple times, but none of the attackers changed the default password, or removed prior bitcoin miners." The Hikvision DVR joins a growing list of other devices, including Android smartphones and routers made by Linksys, D-Link, and Asus with Bitcoin-mining malware. As Ullrich notes, the stripped-down hardware contained in these devices makes them an unlikely host for such demanding apps. It's possible attackers are targeting the devices deliberately under the theory that even low-powered devices will deliver results if enough of them are enslaved at one time. It's also possible attackers are indiscriminately taking control of large numbers of devices for laughs or simply because they can. ...
Himanshu Arora, TechSpot, 5 May 2014 http://www.techspot.com/news/56643-us-government-to-study-bitcoin-as-possible-terrorist-threat.html The US Department of Defense is investigating whether Bitcoin and other virtual currencies are a potential terrorist threat, according to an IBTimes report. The Combating Terrorism Technical Support Office (CTTSO), a division within DOD that identifies and develops counter terrorism abilities and investigates irregular warfare and evolving threats, has listed Bitcoin among its topics for research and mission critical analysis related to terrorism. Back in January, Bitcoin Magazine unearthed an unclassified memo detailing some of the CTTSO projects. "The introduction of virtual currency will likely shape threat finance by increasing the opaqueness, transactional velocity, and overall efficiencies of terrorist attacks=94, the memo said. The biggest concern associated with Bitcoin is the anonymity built into the virtual currency's architecture. Although transactions are public, the parties involved are kept anonymous. Bitcoins can allow illegal operations with the ease and speed of the Internet, but with the secrecy of a cash deal. The virtual currency came under the scanner after several high profile cases came into light. Back in October last year, the FBI closed down the Silk Road, a digital black market that allowed users to purchase drugs, guns, and more. The website accepted only Bitcoin for payments. In another incident, BitInstant CEO Charlie Shrem, who was also the chairman of the Bitcoin Foundation, was arrested in January on charges of money laundering with Bitcoins. Although a Treasury department probe found no evidence of virtual currencies like Bitcoin being used to finance terrorism, the threat still remains. In addition to Bitcoin and other virtual currencies, CTTSO=92s list of terrorism research topics also included Android, Motorola, social media, virtual reality, and more.
Jon Brodkin, Ars Technica, 5 May 2014 Network operator Level 3, which has asked the FCC to protect it from "arbitrary access charges" that ISPs want in exchange for accepting Internet traffic, today claimed that six consumer broadband providers have allowed a state of "permanent congestion" by refusing to upgrade peering connections for the past year. Level 3 and Cogent, another network operator, have been involved in disputes with ISPs over whether they should pay for the right to send them traffic. ISPs have demanded payment in exchange for accepting streaming video and other data that is passed from the network providers to ISPs and eventually to consumers. When the interconnections aren't upgraded, it can lead to congestion and dropped packets, as we wrote previously regarding a dispute between Cogent and Verizon. In a blog post today, Level 3 VP Mark Taylor wrote: ... http://arstechnica.com/information-technology/2014/05/level-3-claims-six-isps-dropping-packets-every-day-over-money-disputes/
Jon Brodkin, Ars Technica, 1 May 2014 Yahoo yesterday announced that it will stop complying with Do Not Track signals that Web browsers send on behalf of users who wish to not be monitored for advertising purposes. "As of today, web browser Do Not Track settings will no longer be enabled on Yahoo," a company blog said. "As the first major tech company to implement Do Not Track, we've been at the heart of conversations surrounding how to develop the most user-friendly standard. However, we have yet to see a single standard emerge that is effective, easy to use and has been adopted by the broader tech industry." When users click the Do Not Track setting in their browser, an HTTP header is sent to websites to state the user's preference not to be tracked. "While some third parties have committed to honor Do Not Track, many more have not," the project website states. "In February 2012, the major online advertising trade groups pledged at the White House to support Do Not Track by year-end; that promise remains unfulfilled. Efforts to standardize Do Not Track in the World Wide Web Consortium have resulted in deadlock, despite frequent urging by American and European policymakers." ... http://arstechnica.com/information-technology/2014/05/yahoo-is-the-latest-company-ignoring-web-users-requests-for-privacy/
Sean Gallagher, Ars Technica, 5 May 2014 Hands on: Pwnie Express takes Ars through its new Android phone for white hat hackers. Mobile technology has made it possible for people to do an amazing amount with tablets and smartphones within the workplace-including hacking the living daylights out of the corporate network and other people's devices. Pwnie Express is preparing to release a tool that will do just that. Its Pwn Phone aims to help IT departments and security professionals quickly get a handle on how vulnerable their networks are in an instant. All someone needs to do is walk around the office with a smartphone. Pwnie Express' Kevin Reilly gave Ars a personal walk-through of the latest Pwn Phone, the second generation of the company's mobile penetration testing platform. While the 2012 first-generation Pwn Phone was based on the Nokia N900 and its Maemo 5 Linux-based operating system, the new phone is based on LG Nexus 5 phone hardware. However, it doesn't exactly use Google's vanilla Android. ... http://arstechnica.com/security/2014/05/android-based-pwn-phone-is-prepared-to-do-evil-for-your-networks-own-good/
Tom Brewster, BBC, 14 April 2014 A new age of connected machines will improve our lives in many ways. But one downside could be our devices overburden broadband and open up homes to hackers. http://www.bbc.com/future/story/20140413-why-ghosts-haunt-the-internet
"But the government hopes this universal ID can replace people's logins
for various places on the Internet in the future. Obviously, not everyone
will be thrilled by this development; after all, we're now very much aware
of the NSA's love for snooping. Plus, it's risky using just a single
log-in for various services like banking and social security. If you're
one of those people, then cross your fingers and hope that NSTIC's
completely voluntary, like what the government promised during the
project's inception." (Engadget via NNSquad_
http://www.engadget.com/2014/05/06/nstic-government-internet-id/
I ripped apart NSTIC when it was announced. And given events since then,
anyone who willingly participates in this is—to use the vernacular—an
idiot.
Woody Leonhard,| InfoWorld, 6 May 2014 Early runs of yesterday's patch are not encouraging: not only does it fail to work in many instances, but it also brings up a handful of new errors http://www.infoworld.com/t/microsoft-windows/the-new-kb-2919355-windows-81-update-causes-more-problems-it-fixes-242016
Apparently, detailed flight plans can be too detailed. Reportedly, the numerous way points on a U-2's flight plan were responsible for the problem that shut down LAX for half a day this past Wednesday. Apparently, the path prediction software did not deal well with the numerous way points. It would appear that the specifications did not match the real-world requirements. The CNN report can be found at: http://www.cnn.com/2014/05/05/us/california-ground-stop-spy-plane-computer/index.html - Bob Gezelter, http://www.rlgsc.com
I think you will find that the remaining U2s are assigned to the 9th Reconnaissance Wing at Beale AFB near Yuba City. My best guess is that the glitch will turn out to be related to altitude, i.e., that the software failed to filter out objects at altitudes significantly greater than those used by commercial traffic, but also misinterpreted the 60,000 ft altitude of the U2 as presenting a collision hazard with aircraft at much lower altitudes. Fortunately, I very much doubt that ERAM or any other FAA system feeds into a Launch Control Center network. Some data may feed other Fed networks. If the system is changed to ignore very high altitude traffic, and Google drones operate at beyond that ceiling, that may not be a problem. I'd be more concerned about such things as the Amazon delivery drones. A 20 to 100 lb. drone in or near commercial airspace _could_ pose a hazard. What logic is required to determine that a specific drone does not? I suppose a transponder requirement for drones could help, but imho would not eliminate the hazard. Complete avoidance of controlled airspace may not be practical due to range limitations.
Is there any estimate of what this incident cost? What was the underlying fault? Would it have been cheaper for the software developers to use development methods that gave high assurance that this class of fault could not exist or that it could not lead to a system failure? I hope someone does this analysis and publishes a report. It's one way that an engineering profession can learn from mistakes.
I recall that the epidemic was already declining when the handle was removed. Curiously the wiki reference given by Henry says this: Although this action has been popularly reported as ending the outbreak, the epidemic may have already been in rapid decline, as explained by Snow himself: There is no doubt that the mortality was much diminished, as I said before, by the flight of the population, which commenced soon after the outbreak. Thus have well-designed experiments been frustrated by Nature. I pictured Snow & Whitehead trudging thru the streets, talking to each household.
> Perhaps the modern equivalent of that pump handle is "gcc". Gcc may have to > be forceably removed from programmers' cold, dead hands in order to get them > to program in safer languages. But we don't like LISP! (http://kuoi.org/~kamikaze/read.php?id=11) Dimitri
Reference counting cannot correctly handle circular references. One can end up with disconnected subgraphs where each node has a non-zero reference count but the entire subgraph is unreachable. This isn't an issue for objects which do not contain references (e.g. strings), or where the objects form a hierarchy such that any object can only contain references to objects lower down the hierarchy. Glynn Clements <glynn@gclements.plus.com>
Please report problems with the web pages to the maintainer