RISKS-LIST: Risks-Forum Digest Tuesday 22 June 2021 Volume 32 : Issue 72 ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) Peter G. Neumann, founder and still moderator
***** 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/32.72> The current issue can also be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: GPS III's Long Journey Is Picking Up Speed (WiReD) Why the Mexico City Metro Collapsed (NYTimes) One stolen password gave hackers access to NYC's deepest secrets (NYTimes PGN-ed) Double-Encrypting Ransomware (WiReD) Optional is not always optional (Bob Gezelter) Facial Recognition Failures Are Locking People Out of Unemployment Systems (Vice) Doggie device prompts scare that closed CIA front gate, spokeswoman says (WashPost) This tech uses augmented reality to give surgeons 'superpowers' (cnn.com) Caps and Gowns and credit-card fraud (The Globe via David Tarabar) Hard to fathom this having been a design goal... (Geek via GG) Biomimetic resonant acoustic sensor detecting far-distant voices accurately to hit the market (Techxplore.com) Apple Says It's Time to Digitize Your ID, Ready or Not (WiReD) What If Doctors Are Always Watching, but Never There? (WiReD) End-to-End Verifiability Key to Future Election Security (unidentified author via Gabe Goldberg) Government Chatbots Now a Necessity for States, Cities, Counties (GovTech) Wabi-sabi software systems (Henry Baker) CoVID dream (Rob Slade) Bombshell Report Finds Phone Network Encryption Was Deliberately Weakened (Vice via Lauren Weinstein) Metrics and integrity -- and media? (Rob Slade) Fake surveys? Real surveys? Who knows? (Lauren Weinstein) Correlated errors in quantum computers emphasize need for design changes (Sarah Perdue) Apple's and Google's New AI Wizardry Promises Privacy, at a Cost (WiReD) The Efforts to Make Text-Based AI Less Racist and Terrible (WiReD) How Humans Think When They Think As Part of a Group (WiReD) One-billion-dollar Bangladesh cybertheft in 2016 foiled by faulty printer, random coincidence in street address, and a spelling error (and perhaps deductible -- BBC and techxplore.com) Re: Pipeline Investigation Upends Idea That Bitcoin Is Untraceable (Stephen E. Bacher) Re: New trains on Amtrak's Acela delayed a year by new round of testing (John Levine) Re: Encrypted Messaging App Run by the FBI Leads to Arrest of Over 100 Organized Crime Members (Stephen E. Bacher) Re: Single-point failure (Adam Shostack) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Sat, 19 Jun 2021 13:16:11 -0400 From: Gabe Goldberg <g...@gabegold.com> Subject: GPS III's Long Journey Is Picking Up Speed (WiReD) With the launch of a fifth new-generation satellite, the US finally has a constellation able to globally beam M-Code signals that are tough to spoof or jam. https://www.wired.com/story/gps-iiis-long-journey-is-picking-up-speed/ An autonomous ship's first effort to cross the Atlantic shows the difficulty of the experiment A nearly 50-foot-long ship set out on June 15 to sail from England to the United States autonomously. But a mechanical problem has forced its designers to return it to port. IBM and Promare had dispatched the 49-foot autonomous boat into the waters off the coast of Plymouth, England, on Tuesday. The robotic boat was set to traverse the seas alone for the next few weeks until it reached Plymouth, Mass., the town where pilgrim travelers settled in 1620. But overnight Thursday, the ship-shaped android developed a *minor mechanical issue*�that was significant enough for Promare to temporarily abort the mission. [.. So what went wrong? It's unclear. Early Friday morning, researchers monitoring the voyage realized that the vessel was operating at about half its optimal speed. The issue may be due to a cheap part untethering near the backup diesel engine, Phaneuf said. But it's hard to know since cameras pointed at the ship's internal components don't capture everything. ``We could probably just go ahead and plod along, but we're running into the Gulf Stream, we're running into a couple of storms. Ordinarily that wouldn't be a big deal. But if you don't have enough power to keep the boat going through wind currents and waves, we might have been stuck out there for a very long time'' Phaneuf added. https://www.washingtonpost.com/technology/2021/06/18/mayflower-ibm-autonomous-ship/ ------------------------------ Date: Sun, 13 Jun 2021 12:09:53 -0400 From: Gabe Goldberg <g...@gabegold.com> Subject: Why the Mexico City Metro Collapsed (NYTimes) A *Times* investigation shows the serious construction flaws and political pressure behind a tragedy that threatens two of Mexico's most prominent figures. �But evidence from the crash site indicates that the metro''s flaws ran much deeper than maintenance. Underneath the tracks, the line that carried more than a quarter of a million people around the Mexican capital every day was held together by bolt-like studs. Welded into steel and encased in concrete, they created a structure much stronger than either material on its own. The strength of the overpass depended on those studs -- they were an essential connection keeping it intact. But photographs of the rubble point to a fundamental lapse during construction: The welds holding everything together were far too weak. Photographs show that the studs broke clean off the steel beams, creating what engineers called an unstable structure incapable of supporting the train. https://www.nytimes.com/interactive/2021/06/12/world/americas/mexico-city-train-crash.html ------------------------------ Date: Sun, 20 Jun 2021 20:28:48 PDT From: Peter G Neumann <neum...@csl.sri.com> Subject: One stolen password gave hackers access to NYC's deepest secrets Ashley Southall, Benjamin Weiser and Dana Rubenstein *The New York Times*, 20 Jun 2021 Failure to use a simple and common security tool led to a breach Conclusion: They did not use MFA (Multi-Factor Authentication). [Simple? Not necessarily. Common? Not so much. Once again. so-called best practices are not good enough. Even if New York City's Law Department had used MFAs, the system was apparently configured so that once an attacker managed to get inside, they had access to everything. Principles such as Least Privilege, Compartmentalization, Separation of Roles/Duties/Permissions/etc., and lots more should be practiced, not just espoused. PGN] ------------------------------ Date: Tue, 15 Jun 2021 04:14:57 +0000 From: Bruce Schneier <schne...@schneier.com> Subject: Double-Encrypting Ransomware (WiReD) CRYPTO-GRAM, June 15, 2021 by Bruce Schneier, Fellow and Lecturer, Harvard Kennedy School schne...@schneier.com https://www.schneier.com A free monthly newsletter providing summaries, analyses, insights, and commentaries on security: computer and otherwise. For back issues, or to subscribe, visit crypto-gram's web page [https://www.schneier.com/crypto-gram/]. Risks-excerpted ToC; #5 follows 1. Is 85% of U.S. critical infrastructure in private hands? 5. Double-Encrypting Ransomware 6. AIs and fake comments 14. Vulnerabilities in weapons systems [2021.05.21] [https://www.schneier.com/blog/archives/2021/05/double-encrypting-ransomware.html] This seems to be a new tactic [https://www.wired.com/story/ransomware-double-encryption/] ** Double-Encrypting Ransomware Emsisoft has identified two distinct tactics. In the first, hackers encrypt data with ransomware A and then re-encrypt that data with ransomware B. The other path involves what Emsisoft calls a *side-by-side encryption* attack, in which attacks encrypt some of an organization's systems with ransomware A and others with ransomware B. In that case, data is only encrypted once, but a victim would need both decryption keys to unlock everything. The researchers also note that in this side-by-side scenario, attackers take steps to make the two distinct strains of ransomware look as similar as possible, so it's more difficult for incident responders to sort out what's going on. ------------------------------ Date: Sun, 20 Jun 2021 16:29:18 -0400 From: Bob Gezelter <gezel...@rlgsc.com> Subject: Optional is not always optional While it is common to mark webform fields as *Mandatory* or *Optional*, *Optional*s not always optional. Regulators require financial institutions to ``Know their customer.'' Knowing your customer generally includes an identity check against databases including driver's license, passports, and other identity documents, as well as information such as vehicle ownership, land ownership and other public records. I recently had occasion to fill out just such a form. The field for Middle Initial was marked as optional. Much to my surprise, the identity validation failed when I used my New York Driver's License. I tried again, using my US Passport. Validation failed again. Strange, I have been out of the country many times and never had a problem re-entering. As a lark while on hold for the help line, I tried entering my *Optional* Middle Initial. Success. If an input leads to an inaccurate or incorrect result, it is NOT optional. ------------------------------ Date: Sun, 20 Jun 2021 19:37:14 -0400 From: Gabe Goldberg <g...@gabegold.com> Subject: Facial Recognition Failures Are Locking People Out of Unemployment Systems (Vice) ID.me's CEO says unemployment fraud is costing taxpayers $400 billion, but his own company is denying claims because of problems with its tech, users say. https://www.vice.com/en/article/5dbywn/facial-recognition-failures-are-locking-people-out-of-unemployment-systems ------------------------------ Date: Sat, 19 Jun 2021 13:11:32 -0400 From: Gabe Goldberg <g...@gabegold.com> Subject: Doggie device prompts scare that closed CIA front gate, spokeswoman says (WashPost) Doggie device prompts scare that closed CIA front gate, spokeswoman says A remote control for a dog training collar was removed by law enforcement. The front gate of the CIA headquarters in McLean was briefly closed Friday afternoon as authorities investigated a small electronic device that was left outside the security perimeter, a spokeswoman said. It turned out to be a remote control for a dog training collar, the spokeswoman said, but that wasn't discovered before law enforcement teams were called to the scene and news helicopters were circling overhead. The device posed no threat. Video from a WJLA helicopter at the scene showed what appeared to be a law enforcement officer in a protective outfit using a long yellow pole to remove the item from the top of a white column on a sidewalk. A law enforcement robot was also in the area. https://www.washingtonpost.com/local/public-safety/cia--suspicious-package-probe-mclean/2021/06/18/26d953c2-d054-11eb-8014-2f3926ca24d9_story.html I understand sensitivity, given: https://en.wikipedia.org/wiki/CIA_headquarters_shooting ------------------------------ Date: Fri, 18 Jun 2021 17:29:28 +0800 From: Richard Stein <rmst...@ieee.org> Subject: This tech uses augmented reality to give surgeons 'superpowers' (cnn.com) https://edition.cnn.com/2021/06/17/health/augmented-surgery-syncar-technology-spc-hnk/index.html '"When you have your hands on something delicate, such as the brain, every minute and second matters. Every small movement matters," says Moty Avisar, CEO and co-founder of Surgical Theater. "If you have to pull your head away from the microscope to look at a display and then go backwards, it disturbs to continuity of the surgery."' These systems capture real-time radiological imaging and overlay them with augmented reality content -- patient tissue/anatomy, position/orientation of surgical instruments placed within, implanted electrodes, patient vitals (pulse, oxygen saturation, blood pressure, etc.) -- for rendering on a heads-up display or goggle mounted display to minimize a surgeon's head movements. The raw imaging + overlay is recorded. The FDA's TPLC platform reports over 280 manufacturers of approved medical devices that possess and perform "system, image processing, radiological" capabilities, a label assigned to devices with product code LLZ. See https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfTPLC/tplc.cfm?id=5558 (retrieved on 18JUN2021) for device and patient issues reported between 01JAN2016 and 31MAY2021. The number of deployed AR platforms, their frequency of use, surgery procedure specialties, etc. are unknown. I count 619 device malfunctions, 35 injuries, and 4 deaths per medical device reports (MDRs) between 01JAN2016 and 31MAY2021 for the LLZ product code classification. The top-10 Device Problems, in CSV format, are: Device Problems,MDRs with this Device Problem,Events in those MDRs Computer Software Problem,180,180 Loss of Data,137,137 Data Problem,108,108 Use of Device Problem,73,73 Patient Data Problem,52,52 Device Operates Differently Than Expected,47,47 Device Issue,37,37 Adverse Event Without Identified Device or Use Problem,27,27 Device Operational Issue,18,18 Application Program Problem: Parameter Calculation Error,17,17 The top-10 Patient Problems, in CSV format, are: Patient Problems,MDRs with this Patient Problem,Events in those MDRs No Known Impact Or Consequence To Patient,456,456 No Consequences Or Impact To Patient,69,69 No Clinical Signs,Symptoms or Conditions,55,55 No Patient Involvement,36,36 No Information,20,20 No Code Available,7,7 Misdiagnosis,6,6 Failure of Implant,4,4 Insufficient Information,4,4 Missing Value Reason,4,4 ------------------------------ Date: Sat, 12 Jun 2021 20:22:01 -0400 From: David Tarabar <dtara...@acm.org> Subject: Caps and Gowns and credit-card fraud Thousands of college grads who ordered caps and gowns from Herff Jones discovered that their credit-card info had been leaked. https://www.bostonglobe.com/2021/06/11/metro/bu-graduates-had-identities-stolen-while-buying-caps-gowns/?p1=BGSearch_Advanced_Results [Cap-itchulater, allocater? Gown but not ForCotton?. PGN] ------------------------------ Date: Sun, 13 Jun 2021 19:45:25 -0400 From: Gabe Goldberg <g...@gabegold.com> Subject: Hard to fathom this having been a design goal... ...might as well document how it turned out: *Note:* If you're logged in to a Microsoft account in your browser while changing your News widget settings but not logged in to the same Microsoft account in Windows 10, the settings on the MSN.com page will not work. In that case, you'll need to log out of your Microsoft account in your browser, reload the MSN widget settings page, and then make the changes again. Reload the widget to make the settings take effect. https://www.howtogeek.com/733709/how-to-configure-windows-10s-weather-news-taskbar-widget/ ------------------------------ Date: Tue, 15 Jun 2021 08:41:44 +0800 From: Richard Stein <rmst...@ieee.org> Subject: Biomimetic resonant acoustic sensor detecting far-distant voices accurately to hit the market (Techxplore.com) https://techxplore.com/news/2021-06-biomimetic-resonant-acoustic-sensor-far-distant.html "The flexible acoustic sensor has been miniaturized for embedding into smartphones and the first commercial prototype is ready for accurate and far-distant voice detection." "The error rate of speaker identification was significantly reduced by 56% (with 150 training datasets) and 75% (with 2,800 training datasets) compared to that of a MEMS condenser device." Voice biometric sensors can discriminate among multiple concurrent conversations to identify a known speaker. Deployment of sensitized voice activation gear, in certain environments (launch control, factory operation, open-outcry trading), may initiate unwanted events. ------------------------------ Date: Wed, 16 Jun 2021 14:36:33 -0400 From: Gabe Goldberg <g...@gabegold.com> Subject: Apple Says It's Time to Digitize Your ID, Ready or Not (WiReD) Digital driver's licenses have had a slow start in the US so far, but iOS 15 Wallet will give the nascent technology a serious push. If you've ever scanned a digital boarding pass directly from your phone at airport security, you can imagine how doing the same with your driver's license would make life a little easier. Beginning in iOS 15 this fall, Apple will enable just that, letting you store your state ID alongside your credit cards, loyalty programs, transit passes, and even door and car keys in Apple Wallet. By doing so, the company won't just introduce convenience; it may well be the tipping point that forces more states, the US government, and even Android to make digital driver's licenses the norm. Apple itself isn't launching a universal digital identification scheme; plenty of others have embarked on technically and geopolitically fraught efforts to create a new type of private and secure ID for everyone. And digital driver's licenses aren't entirely novel. States like Oklahoma, Delaware, and Arizona have recently worked with a company called IDEMIA to develop both the infrastructure and a companion app to support digital driver's licenses. And Colorado and Louisiana introduced digital IDs more than two years ago. It's still very much early days, though. Every state that allows for digital driver's licenses still requires you to carry the physical version, and some mobile licenses currently can't be used outside the state that issued them. That's partly because the federal government is in the process of introducing new design requirements to make driver's licenses harder to forge or manipulate, part of the REAL ID Act. Apple didn't speak to the issue directly, but will presumably build in the ability to use Wallet IDs out of state for flying. [...] One major question is how Apple users and law enforcement like TSA agents will actually interact with these digital IDs. If your driver's license is on your phone, you could potentially have to present your fully unlocked device to a law enforcement agent in a transaction like a traffic stop or at airport security. That could, in turn, expose you to incidental search of your data, social media accounts, or anything else the agent flicks to. Customs and border crossings are already fraught with digital privacy threats, even within the US. https://www.wired.com/story/apple-wallet-drivers-license-digital-id/ ...and will there be charging stations along TSA lines? ------------------------------ Date: Thu, 17 Jun 2021 01:12:24 -0400 From: Gabe Goldberg <g...@gabegold.com> Subject: What If Doctors Are Always Watching, but Never There? (WiReD) Remote technology could save lives by monitoring health from home or outside the hospital. It could also push patients and health care providers further apart. Author writes: This question stayed with me for years, as I started seeing patients in my own clinic. My desire to find better ways of really seeing what was happening with them was sharpened by the coronavirus pandemic. I wondered: How can we safely assess and monitor all these patients we now consult remotely, in their own homes? I set out to discover ways that technology might help me work more safely in the community, which led to a new piece of equipment that was initially developed for the Formula One racing circuit, and which is currently being piloted in intensive care to see if it picks up early signs of decline in children. [...] But while remote monitoring technologies will extend the frontiers of medicine into domestic, private spaces, will they also, paradoxically, push patients and health care workers further apart? With health care systems desperate to save money, this kind of innovation could give managers an excuse to load health care providers with more patients, or to cut nursing staff, hoping fewer people could do the same work by relying on digital tools. Duncan insists that her kit must assist, and not replace, human caregivers, but it is hard to see how this can be guaranteed. In a system where costs are measured and metered, it's unlikely that the time saved by using technology would be allocated to help care workers commune in invaluable but unprofitable ways, with their patients. In other words, remote patient monitoring may mean that doctors are always watching, but never there. I may be guilty of nostalgia; one could argue that remote monitoring is simply a predictable, and welcome, next step in finding safer ways to keep an eye on patients. But while the invention of the observation chart punted the doctor from the bedside to the foot of the bed, remote patient monitoring kicks us out of sight. Duncan says her team has tried to prevent this by requiring that patients get regular physical checks. ``I wouldn't set up a system that's fully automated, that didn't have somebody at least checking in once a day, if not twice a day, on these patients,'' she says. https://www.wired.com/story/can-remote-tech-save-lives/ ------------------------------ Date: Thu, 17 Jun 2021 16:32:29 -0400 From: Gabe Goldberg <g...@gabegold.com> Subject: End-to-End Verifiability Key to Future Election Security Author -- not me -- writes: With future elections likely to divide along stark partisan lines, and election security in question, end-to-end verifiability can let voters know that their ballots have been received and not tampered with. One solution to this problem is to introduce end-to-end (E2E) verifiability in elections. E2E allows voters to know that not only have election officials received their ballot, but also that no one has tampered with it along the way. E2E makes this possible by creating a unique tracking number that is cryptographically linked to how they cast their vote, ensuring that any attempt to alter their ballot could be detected. Moreover, E2E allows everyone -- news media, political parties, candidates, voters and outside observers -- to fully audit the results of an election, ensuring that all ballots are counted as cast, while still protecting voters' privacy. E2E enables this feature using homomorphic encryption. [...] Perhaps the best part of E2E is that it is a concept, not a single product, and multiple companies, researchers and election officials have devised E2E voting systems. And some even have substantial backing -- Microsoft, for example, released a free, open source software development kit that developers can use to integrate E2E into their voting systems. https://www.govtech.com/opinion/end-to-end-verifiability-key-to-future-election-security.htm Really? A high-tech concept will work for some voters, not for others... ------------------------------ Date: Thu, 17 Jun 2021 16:49:50 -0400 From: Gabe Goldberg <g...@gabegold.com> Subject: Government Chatbots Now a Necessity for States, Cities, Counties Before COVID-19, a few leading governments were dabbling in chatbot technology, using AI to address common resident queries. In 2021, it's hard to imagine government doing the people's business without them. [...] A lot of the jurisdictions surveyed used their chatbots for COVID-19-related purposes. Connecticut COVID chatbot, for example, built using technology from IBM Watson, logged nearly 40,000 interactions in a four-month period beginning last March. The state estimates that it did the work of four full-time employees during that time. But chatbots often proved useful well beyond COVID-19 needs as well. Placer County, Calif., for example, has a bot called *Ask Placer �capable of answering more than 375 questions. IT agencies in �San Joaquin County, Calif., an �Fairfax County, �San Joaquin Count Calif., and �Fairfax Count VA., both worked with other departments to figure out what their needs were and what their most frequent questions were so that they could build those into their chatbots. Minnesota has a similar approach, leaning on its IBM Watson chatbot to help Sanaddress general inquiries. Iowa's chatbot dates back to late 2018, and capabilities continue to be added as new needs arise. Seventeen agencies now use it, and so does the public. In May 2020, the state's chatbot tools, combined with its live chat function, saved an estimated 1,700 hours of staff time that would have been spent addressing those same inquiries using traditional tools. https://www.govtech.com/products/government-chatbots-now-a-necessity-for-states-cities-counties.html Having used chatbots since https://en.wikipedia.org/wiki/SmarterChild -- born in 2000 as ActiveBuddy -- I'm skeptical about their ability to be very intelligent. It would have been helpful having, alongside government staffers praising them, customer testimonials to their success. A frequent frustration is a chatbot being unable to answer a question but continuing to provide useless information, vs. fetching a human. Now the annoyance of telephone answering systems not allowing reaching a human will be matched by chatbots unwilling to fetch help. ------------------------------ Date: Fri, 18 Jun 2021 14:41:22 -0700 From: Henry Baker <hbak...@pipeline.com> Subject: Wabi-sabi software systems I've devoted a significant fraction of my computer science career trying to improve 'memory safety' in computer systems, and I believe that this particular article below (including its figures) is perhaps the best set of arguments I've ever seen for using a type-safe and memory-safe language for 'systems' programming. Garbage collection is great for memory safety, but we live in a TWO dimensional world of both constraints on access to particular areas of memory and constraints on access to particular moments in time of a computer's processor(s). Most garbage collectors solve the memory safety problem at the expense of DDOS'ing the CPU's time schedule, making it difficult -- if not impossible -- to assure continuous responsiveness. The Rust programming language seems to provide a decent compromise of memory safety AND predictable time scheduling. Hopefully, additional language/OS mechanisms will be developed to enable even better 'schedule safety' WITH 'memory safety' for future computer systems with thousands of cores. I'm looking forward to seeing Rust used to improve both Android- and Linux-powered computer systems. Perhaps Rust is 50 years too late to solve our very-near-term computer security problems, but better late than never! https://security.googleblog.com/2021/04/rust-in-android-platform.html (See also https://security.googleblog.com/2021/04/rust-in-linux-kernel.html) Rust in the Android platform April 6, 2021 Posted by Jeff Vander Stoep and Stephen Hines, Android Team Correctness of code in the Android platform is a top priority for the security, stability, and quality of each Android release. Memory safety bugs in C and C++ continue to be the most-difficult-to-address source of incorrectness. We invest a great deal of effort and resources into detecting, fixing, and mitigating this class of bugs, and these efforts are effective in preventing a large number of bugs from making it into Android releases. Yet in spite of these efforts, memory safety bugs continue to be a top contributor of stability issues, and consistently represent ~70% of Android's high severity security vulnerabilities. In addition to ongoing and upcoming efforts to improve detection of memory bugs, we are ramping up efforts to prevent them in the first place. Memory-safe languages are the most cost-effective means for preventing memory bugs. In addition to memory-safe languages like Kotlin and Java, we're excited to announce that the Android Open Source Project (AOSP) now supports the Rust programming language for developing the OS itself. Systems programming Managed languages like Java and Kotlin are the best option for Android app development. These languages are designed for ease of use, portability, and safety. The Android Runtime (ART) manages memory on behalf of the developer. The Android OS uses Java extensively, effectively protecting large portions of the Android platform from memory bugs. Unfortunately, for the lower layers of the OS, Java and Kotlin are not an option. Lower levels of the OS require systems programming languages like C, C++, and Rust. These languages are designed with control and predictability as goals. They provide access to low level system resources and hardware. They are light on resources and have more predictable performance characteristics. For C and C++, the developer is responsible for managing memory lifetime. Unfortunately, it's easy to make mistakes when doing this, especially in complex and multithreaded codebases. Rust provides memory safety guarantees by using a combination of compile-time checks to enforce object lifetime/ownership and runtime checks to ensure that memory accesses are valid. This safety is achieved while providing equivalent performance to C and C++. The limits of sandboxing C and C++ languages don't provide these same safety guarantees and require robust isolation. All Android processes are sandboxed and we follow the Rule of 2 to decide if functionality necessitates additional isolation and deprivileging. The Rule of 2 is simple: given three options, developers may only select two of the following three options. For Android, this means that if code is written in C/C++ and parses untrustworthy input, it should be contained within a tightly constrained and unprivileged sandbox. While adherence to the Rule of 2 has been effective in reducing the severity and reachability of security vulnerabilities, it does come with limitations. Sandboxing is expensive: the new processes it requires consume additional overhead and introduce latency due to IPC and additional memory usage. Sandboxing doesn't eliminate vulnerabilities from the code and its efficacy is reduced by high bug density, allowing attackers to chain multiple vulnerabilities together. Memory-safe languages like Rust help us overcome these limitations in two ways: Lowers the density of bugs within our code, which increases the effectiveness of our current sandboxing. Reduces our sandboxing needs, allowing introduction of new features that are both safer and lighter on resources. But what about all that existing C++? Of course, introducing a new programming language does nothing to address bugs in our existing C/C++ code. Even if we redirected the efforts of every software engineer on the Android team, rewriting tens of millions of lines of code is simply not feasible. The above analysis of the age of memory safety bugs in Android (measured from when they were first introduced) demonstrates why our memory-safe language efforts are best focused on new development and not on rewriting mature C/C++ code. Most of our memory bugs occur in new or recently modified code, with about 50% being less than a year old. The comparative rarity of older memory bugs may come as a surprise to some, but we've found that old code is not where we most urgently need improvement. Software bugs are found and fixed over time, so we would expect the number of bugs in code that is being maintained but not actively developed to go down over time. Just as reducing the number and density of bugs improves the effectiveness of sandboxing, it also improves the effectiveness of bug detection. Limitations of detection Bug detection via robust testing, sanitization, and fuzzing is crucial for improving the quality and correctness of all software, including software written in Rust. A key limitation for the most effective memory safety detection techniques is that the erroneous state must actually be triggered in instrumented code in order to be detected. Even in code bases with excellent test/fuzz coverage, this results in a lot of bugs going undetected. Another limitation is that bug detection is scaling faster than bug fixing. In some projects, bugs that are being detected are not always getting fixed. Bug fixing is a long and costly process. Each of these steps is costly, and missing any one of them can result in the bug going unpatched for some or all users. For complex C/C++ code bases, often there are only a handful of people capable of developing and reviewing the fix, and even with a high amount of effort spent on fixing bugs, sometimes the fixes are incorrect. Bug detection is most effective when bugs are relatively rare and dangerous bugs can be given the urgency and priority that they merit. Our ability to reap the benefits of improvements in bug detection require that we prioritize preventing the introduction of new bugs. Prioritizing prevention Rust modernizes a range of other language aspects, which results in improved correctness of code: Memory safety enforces memory safety through a combination of compiler and run-time checks. Data concurrency prevents data races. The ease with which this allows users to write efficient, thread-safe code has given rise to Rust's Fearless Concurrency slogan. More expressive type system helps prevent logical programming bugs (e.g., newtype wrappers, enum variants with contents). References and variables are immutable by default -- assist the developer in following the security principle of least privilege, marking a reference or variable mutable only when they actually intend it to be so. While C++ has const, it tends to be used infrequently and inconsistently. In comparison, the Rust compiler assists in avoiding stray mutability annotations by offering warnings for mutable values which are never mutated. Better error handling in standard libraries -- wrap potentially failing calls in Result, which causes the compiler to require that users check for failures even for functions which do not return a needed value. This protects against bugs like the Rage Against the Cage vulnerability which resulted from an unhandled error. By making it easy to propagate errors via the ? operator and optimizing Result for low overhead, Rust encourages users to write their fallible functions in the same style and receive the same protection. Initialization -- requires that all variables be initialized before use. Uninitialized memory vulnerabilities have historically been the root cause of 3-5% of security vulnerabilities on Android. In Android 11, we started auto initializing memory in C/C++ to reduce this problem. However, initializing to zero is not always safe, particularly for things like return values, where this could become a new source of faulty error handling. Rust requires every variable be initialized to a legal member of its type before use, avoiding the issue of unintentionally initializing to an unsafe value. Similar to Clang for C/C++, the Rust compiler is aware of the initialization requirement, and avoids any potential performance overhead of double initialization. Safer integer handling -- Overflow sanitization is on for Rust debug builds by default, encouraging programmers to specify a wrapping_add if they truly intend a calculation to overflow or saturating_add if they don’t. We intend to enable overflow sanitization for all builds in Android. Further, all integer type conversions are explicit casts: developers can not accidentally cast during a function call when assigning to a variable or when attempting to do arithmetic with other types. Where we go from here Adding a new language to the Android platform is a large undertaking. There are toolchains and dependencies that need to be maintained, test infrastructure and tooling that must be updated, and developers that need to be trained. For the past 18 months we have been adding Rust support to the Android Open Source Project, and we have a few early adopter projects that we will be sharing in the coming months. Scaling this to more of the OS is a multi-year project. Stay tuned, we will be posting more updates on this blog. Thanks Matthew Maurer, Bram Bonne, and Lars Bergstrom for contributions to this post. Special thanks to our colleagues, Adrian Taylor for his insight into the age of memory vulnerabilities, and to Chris Palmer for his work on *The Rule of 2* and *The limits of Sandboxing*. ------------------------------ Date: Sat, 19 Jun 2021 08:51:48 -0700 From: Rob Slade <rsl...@gmail.com> Subject: CoVID dream I don't normally remember many of my dreams. I know that everyone dreams, and I know that "CoVID dreams" have definitely been plentiful during the pandemic. I remember only one, from the early days of the pandemic. Well, now I've had the second that I recall. I'm teaching. (Probably the CISSP seminar.) I'm in a large venue, possibly a hotel ballroom. But all the people are seated at high tables or bars (as in a pub), on high bar stools. If I stand on the floor, I can't see the whole room. However, when I try to stand on a table or a bar stool, so I can see everyone, the legs of the table or stool telescope, so that the table or stool collapses back to the floor. Somehow I know, the way you know things in dreams, that this collapse has to do with the technology of the table/stool legs. You don't have to be Sigmund Freud to figure out what the dream means. With all the "remote"/"virtual" seminars and teleconferences I've been doing this year, I have all too many examples of where Zoom, Discord, Meet, Teams, GoToWebinar and all of their electronic ilk have collapsed under the demands of the full process of teaching. Thirty-six years ago I ran the technical side (and some of the presentations) of the World Logo Conference, the world's first conference to fully integrate on-site and on-line conferencing. It's disappointing to see how little we have progressed in all that time. ------------------------------ Date: Thu, 17 Jun 2021 15:07:12 -0700 From: Lauren Weinstein <lau...@vortex.com> Subject: Bombshell Report Finds Phone Network Encryption Was Deliberately Weakened I've always assumed these algorithms were weakened. -L https://www.vice.com/en/article/4avnan/bombshell-report-finds-phone-network-encryption-was-deliberately-weakened ------------------------------ Date: Sat, 19 Jun 2021 11:56:07 -0700 From: Rob Slade <rsl...@gmail.com> Subject: Metrics and integrity -- and media? OK, this seems weird. The UK is seeing a spike in cases, and is reporting that it is because of the Delta variant. Ontario is reporting that Delta is becoming the major variant. Other jurisdictions are reporting the same. The Economist has a chart which shows that Delta is two and a half times as infectious as the original SARS-CoV-2. For the most recent week for which detailed data is available, BC had a little over a thousand new cases, and only 6% of those were Delta. (About 90% of new cases were Alpha and Gamma, so the original strain is almost non-existent.) OK, BC is, and almost always has been, in a relatively good state during the pandemic. And BC has a high vaccination rate (for first doses). But supposedly single-shot protection against Delta is only 33%, so the disparity doesn't seem to make sense. And then I see yet another news report about how Delta is taking over in the US. And, buried in that story, they quote a doctor who is seeing a surge in cases, and is *assuming* that it is because of Delta. And I recall that the error bars on that Economist chart were *huge.* Is it possible that all of these "reports" of Delta taking over rely on the "assumptions" of people who don't want to admit that a 43% vaccination rate is not good enough for "herd immunity" and that too many people are sick of taking any pandemic precautions and are just giving up? ------------------------------ Date: Thu, 17 Jun 2021 20:15:15 -0700 From: Lauren Weinstein <lau...@vortex.com> Subject: Fake surveys? Real surveys? Who knows? It's hilarious (in a sick kind of way) that major firms still contract with third parties to send out surveys that recipients have absolutely no way to know are legit! Out of the blue you get a "FOO wants your feedback!" and unless it references a specific transaction that you can recognize -- which these usually don't -- there's no way to know if it's legit or a phishing scam. We've spent years trying to train users not to click on random unauthenticated email links, but *major firms* still use these third party survey firms in ways that make it impossible to respond safely given the information at hand. And the persons who do respond under these conditions may represent a seriously skewed sample set. ------------------------------ Date: Fri, 18 Jun 2021 12:17:11 -0400 (EDT) From: ACM TechNews <technews-edi...@acm.org> Subject: Correlated errors in quantum computers emphasize need for design changes (Sarah Perdue) Sarah Perdue, University of Wisconsin-Madison News, 16 Jun 2021 via ACM TechNews, 18 Jun, 2021 A team led by researchers at the University of Wisconsin-Madison found clues that errors correlate across an entire superconducting quantum computing chip, which must be addressed to develop fault-tolerant quantum computers. After observing in previous experiments that multiple qubits were flipping at the same time, the researchers set out to determine whether the flips were independent or correlated. The team designed a four-qubit superconducting chip and measured fluctuations in offset charge for each qubit; they found sudden increases in offset charge following long periods of relative stability, and that the closer together two qubits were, the more likely they were to jump simultaneously. The researchers said the qubit flips were correlated across the entire chip as the energy spread. https://orange.hosting.lsoft.com/trk/click?ref=znwrbbrs9_6-2b86bx22be43x068316& ------------------------------ Date: Mon, 21 Jun 2021 19:33:21 -0400 From: Gabe Goldberg <g...@gabegold.com> Subject: Apple's and Google's New AI Wizardry Promises Privacy, at c cost (WiReD) The companies revealed upgrades for their phones that protect data and reduce reliance on the cloud. It also binds users more tightly to their ecosystems. https://www.wired.com/story/apple-googles-ai-wizardry-promises-privacy-cost/ ------------------------------ Date: Mon, 21 Jun 2021 19:36:25 -0400 From: Gabe Goldberg <g...@gabegold.com> Subject: The Efforts to Make Text-Based AI Less Racist and Terrible (WiReD) Language models like GPT-3 can write poetry, but they often amplify negative stereotypes. Researchers are trying different approaches to address the problem. https://www.wired.com/story/efforts-make-text-ai-less-racist-terrible/ ------------------------------ Date: Mon, 21 Jun 2021 20:00:30 -0400 From: Gabe Goldberg <g...@gabegold.com> Subject: How Humans Think When They Think As Part of a Group (WiReD) The fancy word for it is "entitativity," and it’s produced when people act and feel together in close proximity. We need it more, but we’re getting it less. After several days conducting military drills off the coast of California, the USS Palau was headed home. The massive aircraft carrier, large enough to transport 25 helicopters, was steaming into San Diego Harbor at a brisk clip. Inside the pilothouse -- located on the navigation bridge, two levels up from the flight deck -- the mood was buoyant. Members of the crew would soon be disembarking and enjoying themselves on shore. Conversation turned to where they would go for dinner that night. Then, suddenly, the intercom erupted with the voice of the ship’s engineer. ``Bridge, Main Control,'' he barked. ``I am losing steam drum pressure. No apparent cause. I'm shutting my throttles.'' A junior officer, working under the supervision of the ship's navigator, moved quickly to the intercom and spoke into it, acknowledging, ``Shutting throttles, aye.'' The navigator himself turned to the captain, seated on the port side of the pilothouse. ``Captain, the engineer is losing steam on the boiler for no apparent cause,'' he repeated. Everyone present knew the message was urgent. Losing steam pressure effectively meant losing power throughout the ship. The consequences of this unexpected development soon made themselves evident. Just 40 seconds after the engineer’s report, the steam drum had emptied, and all steam-operated systems ground to a halt. A high-pitched alarm sounded for a few seconds; then the bridge fell eerily quiet, as the electric motors in the radars and other devices spun down and stopped. But losing electrical power was not the full extent of the emergency. A lack of steam meant the crew had no ability to slow the ship's rate of speed. The ship was moving too fast to drop anchor. The only way to reduce its momentum would have been to reverse the ship's propeller -- operated, of course, by steam. On top of that, loss of steam hobbled the crew's ability to steer the ship, another consequence that soon became painfully evident. Gazing anxiously out over the bow of the ship, the navigator told the helmsman to turn the rudder to the right ten degrees. The helmsman spun the wheel, but to no effect. ``Sir, I have no helm, sir!'' he exclaimed. https://www.wired.com/story/how-humans-think-when-they-think-group/ Fascinating, but scary for a large ship to have single point of catastrophic failure. ------------------------------ Date: Mon, 21 Jun 2021 00:23:08 -0700 From: Rob Wilcox <robwilco...@gmail.com> Subject: One-billion-dollar Bangladesh cybertheft in 2016 foiled by faulty printer, random coincidence in street address, and a spelling error (BBC) BBC journalists tell the story of an attempt by suspected North Korean cyber criminals to steal $1 billion from the US central bank account at the Bangladesh central bank. The heist was planned to occur over overlapping bank holidays in a sequence of involved countries. The plot was first revealed when bank workers restarted the secure printer which makes a paper trail of transactions. That freed messages the hackers had blocked on the servers. The hackers set up a sequence of downstream transactions to move the money. One of the banks had a street address name which was the same name as an entity embargoed by the US. The matching names, which were completely unconnected, triggered an enquiry by the US central bank. That caused the bulk of the transaction to be delayed. Finally, a spelling error caused one of the remaining downstream transactions to be reversed. As a result, only $81 million was successfully stolen by the hackers. The story is a fascinating combination of human failures and successes. Article and link to podcast: The Lazarus heist: How North Korea almost pulled off a billion-dollar hack In 2016 North Korean hackers planned a $1bn raid on Bangladesh's national bank and came within an inch of success -- it was only by a fluke that all but $81m of the transfers were halted. https://www.bbc.com/news/stories-57520169 [Richard Stein noted a quote iin the same item; https://techxplore.com/news/2021-06-ransomware-payment-deductible.html "I would counsel a client to take a deduction for it," says Scott Harty, a corporate tax attorney with Alston & Bird. "It fits the definition of an ordinary and necessary expense." Risk: Incentive to not prioritize infosec investment See "How to Succeed in Business Without Really Trying" for an early lesson on scaling the corporate ladder. BBC item also noted by Rob Wilcox, as well as a podcast at https://www.bbc.com/news/stories-57520169 PGN] ------------------------------ Date: Sun, 13 Jun 2021 10:38:00 -0700 From: "Stephen E. Bacher" <seb...@verizon.net> Subject: Re: Pipeline Investigation Upends Idea That Bitcoin Is Untraceable (NYTimes) This raises some unaddressed questions about the "recovering" the ransom money. Let's say it wasn't cryptocurrency but an account in an actual bank. Would the FBI have the authority to hack into the bank account and transfer the funds electronically? Or if the money was stashed in a physical location. Would the FBI be expecting to break into the location and physically remove the cash? This may all seem OK because DarkSide is a bunch of "bad guys." But what if it's less clear who the perpetrators are? Are we going to see more of these sorts of "recovery" operations, say for civil asset forfeiture? ------------------------------ Date: 12 Jun 2021 21:08:10 -0400 From: "John Levine" <jo...@iecc.com> Subject: Re: New trains on Amtrak's Acela delayed a year by new round of testing (RISKS-32.71) >The 1800s-design curvy track wasn't noticed when designing the new trains? Of course it was, but railway equipment design is complicated, and it's even more complicated when they modified a design from one system to be used on another. The difference isn't just that our tracks are old and twisty, it's that US passenger trains have to be much heavier than European ones due to US regulations that assume US high-speed trains are sharing tracks with freight trains and have to be able to survive crashing into one. (In Europe high speed rail mostly uses dedicated tracks, or they're time separated, passenger during the day, freight at night.) We also have differently designed overhead wire. What this means is that they modify the trains to match the new conditions, but there are invariably surprises when they do test runs. Sometimes the surprises are small, sometimes as in this case they're larger. It would be really surprising if they got everything right on the first try. This sort of problem happens in any large engineering project. On the Isle of Wight, off the southern coast of England, there is a short rail line which uses old London underground equipment adapted for the line. It had been using cars from the 1930s which, while historic and quaint, are totally worn out so now they're upgrading with retired underground stock from the 1970s. The new cars are bigger than the old ones so they've adjusted the underpasses and platforms, and run test trains with plastic frames of the size of the new(er) trains: https://pbs.twimg.com/media/Eoa0tpWXEAAlNWE?format=jpg Nonetheless everyone held their breath on the first test run of the new trains last week through the tunnel at the east end of the line: https://pbs.twimg.com/media/E3hUiBLXEAIbjKD?format=jpg All the planning paid off, and it did indeed fit. For one more example of trying to get the bits of a train system to fit, see this famous (in the train biz) 2014 story of new French trains which didn't fit because they forgot that the platforms at 1300 old stations had less clearance than modern ones: https://www.bbc.com/news/world-europe-27497727 ------------------------------ Date: Sun, 13 Jun 2021 10:46:21 -0700 From: "Stephen E. Bacher" <seb...@verizon.net> Subject: Re: Encrypted Messaging App Run by the FBI Leads to Arrest of Over 100 Organized Crime Members (RISKS-32.71) "A goal of the Trojan Shield investigation is to shake the confidence in this entire industry because the FBI is willing and able to enter this space and monitor messages." Are they sure this is a good move, the FBI blowing its own cover and obviating their ability to use this technique again? We saw a similar RISK when the major social media companies suppressed extremist groups' accounts; they merely moved to other platforms which were less monitored, and we lost general visibility into these groups' plans. Now the criminals will avoid messaging apps entirely and come up with some other means of communication (not necessarily technical) even harder to crack. ------------------------------ Date: Sun, 13 Jun 2021 09:57:55 -0700 From: Adam Shostack <a...@shostack.org> Subject: Re: Single-point failure (Slade, RISKS-32.71) <http://catless.ncl.ac.uk/Risks/32/71#subj3> Rob Slade (Risks 8 June) is right about the causes of many failures that have serious consequences. >From my own long experience, most managers do not understand what causes failures and what design processes can reduce their frequency. The recent history of Boeing is one illustration of the failure of management to understand the need for quality control in design as well as production. In design, the best-known process is the Failure Mode and Effects Analysis (FMEA), which despite its cost is the cheapest way to prevent in-service failure. In production the methods are well known, and easily subverted by managers who give orders to "Never mind that quality control nonsense, get it out quickly and cheaply" with effects that soon cost billions. Efficiency is rather different; it is good for a large-scale production process with few design changes. But emphasis on efficiency is always at the expense of flexibility and adaptability. I did not find management sympathetic to that point. Roderick Rees ------------------------------ Date: Mon, 1 Aug 2020 11:11:11 -0800 From: risks-requ...@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: The mailman Web interface can be used directly to subscribe and unsubscribe: http://mls.csl.sri.com/mailman/listinfo/risks => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line that includes the string `notsp'. Otherwise your message may not be read. *** This attention-string has never changed, but might if spammers use it. => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you never send mail where the address becomes public! => 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! => OFFICIAL ARCHIVES: http://www.risks.org takes you to Lindsay Marshall's searchable html archive at newcastle: http://catless.ncl.ac.uk/Risks/VL.IS --> VoLume, ISsue. Also, ftp://ftp.sri.com/risks for the current volume/previous directories or ftp://ftp.sri.com/VL/risks-VL.IS for previous VoLume If none of those work for you, the most recent issue is always at http://www.csl.sri.com/users/risko/risks.txt, and index at /risks-32.00 ALTERNATIVE ARCHIVES: http://seclists.org/risks/ (only since mid-2001) *** 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. Apologies for what Office365 and SafeLinks may have done to URLs. ==> Special Offer to Join ACM for readers of the ACM RISKS Forum: <http://www.acm.org/joinacm1> ------------------------------ End of RISKS-FORUM Digest 32.72 ************************