[32532] in RISKS Forum
Risks Digest 32.72
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Wed Jun 23 01:06:21 2021
From: RISKS List Owner <risko@csl.sri.com>
Date: Tue, 22 Jun 2021 22:05:05 PDT
To: risks@mit.edu
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 <gabe@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 <gabe@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 <neumann@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 <schneier@schneier.com>
Subject: Double-Encrypting Ransomware (WiReD)
CRYPTO-GRAM, June 15, 2021
by Bruce Schneier, Fellow and Lecturer, Harvard Kennedy School
Schneier@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 <gezelter@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 <gabe@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 <gabe@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 <rmstein@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 <dtarabar@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 <gabe@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 <rmstein@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 <gabe@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 <gabe@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 <gabe@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 <gabe@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 <hbaker1@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 <rslade@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 <lauren@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 <rslade@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 <lauren@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-editor@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 <gabe@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 <gabe@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 <gabe@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 <robwilcoxjr@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" <sebmb1@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" <johnl@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" <sebmb1@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 <adam@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-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: 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
************************
