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…
I've been meaning to submit this for the past few days, and finally found a few spare moments: How Russian Propaganda Spread from a Parody Website to Fox News Neil MacFarquahar and Andrew Rossback *The New York Times*, 8 June 2017 Here's the time sequence described in the article: * Parody website (Made-up Russian attack on a U.S. shop * Facebook (Parody article shared) * Russian TV (Invented a quote from a U.S. Air Force general) * The Sun (Reported on the Russian TV story) * FoxNews.com (Article reprinted with only hints of skepticism)
"Despite the alarms raised by these revelations in recent days, there has been little discussion of solutions. But the way forward is relatively clear. Protecting our elections against foreign attackers ultimately requires the will to squarely address known vulnerabilities—a will that has been lacking in Washington." http://www.slate.com/articles/technology/future_tense/2017/06/congress_needs_to_act_now_to_secure_our_election_systems.html
At the Roambee factory in Santa Clara, California, one or more thieves (the kind who are dumb enough to leave their own blood and other evidence behind them) stole a box of 100 of what they thought were cellphone chargers. Actually they were Roambee Bees, which are GPS-based trackers that broadcast their location. (Their intended use is that a company shipping goods puts one in each shipment and can always know where it is.) And they can't be turned off. It wasn't long before police recovered the stolen goods and made an arrest, and meanwhile the Roambee company got some free advertising... http://www.mercurynews.com/2017/06/06/sjm-roambee-0607/ http://www.sfgate.com/bayarea/article/any-11204181.php
It says here:
http://www.tdbank.com/bank/tdvoiceprint.html
http://www.td.com/ca/products-services/investing/td-direct-investing/trading-platforms/voice-print-system-enroll.jsp
that customers of the Toronto-Dominion Bank can arrange to have the bank's
computer identify them, in part, by recognizing their voice on the phone.
(I therefore presume that other banks are now doing this also.)
It says here:
http://www.cbc.ca/news/any-1.4084423
that a new Canadian company called Lyrebird has produced software which
(they say), given a 1-minute high-quality recording of anyone's voice, can
produce a highly accurate simulation of that person saying anything the user
chooses. And given a 5-minute recording, the quality would be extremely
hard to tell from the real thing.
And someone thought that this was a GOOD idea?
[I presume Mark is referring to the Toronto-Dominion Bank phone voice
scheme rather than the Lyrebird scheme. The latter is obviously a good
idea, because it clearly points to the stupidity of the former. PGN]
https://arstechnica.com/security/2017/06/internet-cameras-expose-private-video-feeds-and-remote-controls/
https://arstechnica.com/tech-policy/2017/06/police-automatic-face-recognition/
https://arstechnica.com/security/2017/06/task-force-tells-congress-health-it-security-is-in-critical-condition/
http://www.nejm.org/doi/full/10.1056/NEJMp1706754
https://www.nytimes.com/2017/06/06/technology/hackers-ransomware-bitcoin-ponzi-wannacry.html As more of our lives go online, online attackers are finding increasingly creative ways to wreak havoc using ransomware, and now, pyramid schemes.
https://arstechnica.com/security/2017/06/sneaky-hackers-use-intel-management-tools-to-bypass-windows-firewall/
[PGN has merges multiple items into one message:] https://www.nytimes.com/2017/06/07/technology/google-self-driving-cars-handoff-problem.html Robot Cars Can't Count on Us in an Emergency Scientists call it the *handoff* problem. How do you keep humans focused enough to take control of a self-driving car in an emergency? [This is an old argument that Don Norman has addressed. Partial automation is risky. On the other hand, if total automation allows overrides, it is really only partial automation, and risky! PGN] https://www.nytimes.com/2017/06/07/technology/autonomous-car-technology-challenges.html A Guide to Challenges Facing Self-Driving Car Technologists The underlying technology of autonomous vehicles has made dramatic strides in recent years. But there are still plenty of issues to be worked out. https://www.nytimes.com/2017/06/07/technology/why-car-companies-are-hiring-computer-security-experts.html Why Car Companies Are Hiring Computer Security Experts: Researchers have proved a car can be remotely hacked. Now imagine if that car was being driven entirely by a computer. https://www.nytimes.com/2017/06/07/technology/electronic-setups-of-driverless-cars-vulnerable-to-hackers.html Electronic Setups of Driverless Cars Vulnerable to Hackers: As cars become more like computers, cybercriminals will have more ways to get into their important systems.
... and also Re: Untold story of QF72: What happens when 'psycho' automation
leaves pilots powerless? (RISKS-30.30)
To paraphrase an old joke:
In the future, the cockpit of an airplane will have a computer, a pilot,
and a dog.
It's the computer's job to fly the plane.
It's the pilot's job to watch over the computer.
It's the dog's job to bite the pilot if he tries to touch the controls.
[Indeed, an old joke, but we have lots of young readers, so it might
be okay to run it every 20 years:
In November 1997, RISKS-19.47 had this line from Robert Dorsett:
"With autopilots, who needs a dog to keep an eye on the pilot?"
(This was in a delightful item of a plane that took off without its pilot
after he got out to crank the propeller.)
Incidentally, in its early days, NASA insisted that computers had to be
buried under layers of equipment so that it would be very difficult for
astronauts to fiddle with the hardware. There was one later case where an
in-space repair actually had to be made. However, software is easy to
remediate without physical access. PGN]
> ... How bad would the state need to be before this last option starts > looking good? Far, far worse than it does now, frankly. One issue that is often overlooked in this debate is that of application affinity. I work in financial services; it's scary how many applications will not work on anything more modern than Windows XP, or rely on appallingly out-of-date and deprecated versions of Java. A friend of mine works in healthcare in IT; she faces a similar problem with certain applications that are used to monitor patient well-being in ICU. Forcibly turning off non-supported OSes, frameworks or languages that the given applications require? What could possibly go wrong?
As synchronicity would have it, RedHat has recently fixed a security problem in Remote Procedure Calls detailed in CVE-2017-8779: ".. a memory leak can occur when parsing specially crafted XDR messages. An attacker sending thousands of messages to rpcbind could cause its memory usage to grow without bound, eventually causing it to be terminated" The "fix" is causing rpcbind to crash 4 seconds after starting. By now probably the largest user of RPC is file sharing via Network File System (NFS) and the result of the "fix" is network shares disappearing. If remember my NFS correctly, this would not affect already connected shares, so the problem may possibly go unnoticed for quite some time. We downgraded our rpcbind and are waiting for the fix of the fix. In the meantime other patches are not getting installed so as to not accidentally reinstall the bad one. Funny enough, the "older unpatched" RHEL 5 systems are not very vulnerable to this particular problem because they're EOL and not receiving any fixes anymore. Including bad ones. The vulnerability itself requires a skilled attacker inside your security perimeter sending "thousands of specially crafted messages" to eventually accomplish the exact thing that RedHat did in 4 seconds with a single patch.
> knowledgeable Windows 7 users block automatic patches [...] > They wait a week or more to see what other experience with > new patches before accepting them. The patch for the bug in SMB was marked as "critical, wormable". Whoever calls him/herself "knowledgeable" and waits with installing that kind of patch, should be called by others in a completely different way. Waiting to install a patch that fixes a typo in a context-menu is one thing but ignoring a patch fixing a wormable bug is something completely different. That's an announced shot into your own foot or - taking real consequences into account - potentially killing people in the UK because they couldn't be treated due to the hospitals' computers got affected.
> ... sometimes with disastrous results. But sometimes without. In this article, William Langewiesche credits the successful ditching of US 1549 as much to the Airbus flight automation as to the skill of the pilot. http://www.vanityfair.com/culture/2009/06/us_airways200906 The question is whether the pilot or the software is more likely to go nuts. The answer is not obvious to me, particularly in cases like the Air France flight off Brazil where the instruments went nuts in a way that would have been harmless if the crew ignored them, but instead the crew did exactly the wrong thing and lost the plane.
Does Prof. Leveson also refuse to go near roads? This is a wonderful illustration of people who should know better still optimising away the tiniest risks that seem controllable while ignoring other greater but less-newsworthy risks. I can well believe that the Boeing philosophy is safer, but I'd take the deaths per passenger-mile in an Airbus over just about any other form of transport including a taxi to the airport. In light of terrorism vs car crashes, Airbus vs heart attacks, sharks vs falling out of bed, one could almost make a generalisation that "if everyone is frightened of it, it's probably not a threat to you". Same thing seems to apply in infosec: all the panic over 0-days, APT, etc vs people not bothering to apply vendors' patches and reusing the same password on 50 different websites.
Please report problems with the web pages to the maintainer