Risks Digest 32.75

[RISKS List Owner <risko () csl sri com>]

RISKS-LIST: Risks-Forum Digest  Sunday 4 July 2021  Volume 32 : Issue 75

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.75>
The current issue can also be found at
  <http://www.csl.sri.com/users/risko/risks.txt>

  Contents:
Power outage knocks Houston 911 call center offline for several hours
  (Houston Chronicle)
An apparent supply chain attack exploited Kaseya's IT management software to
  encrypt a "monumental" number of victims all at once (WiReD)
Major ransomware attack aimed at tech provider leaves other companies
  scrambling (CBC)
With cyberattacks growing more frequent and disruptive, a unified approach
  is essential (Techxplore.com)
Study finds variations in quantitative MRI scanners' measurements
  (medicalxpress.com)
Research lays groundwork for restoring lost oral functions with
  pacemaker-like devices (medicalxpress.com)
Rethinking Application Security in the API-First Era (The Hacker News)
In Sweden, a supermarket chain was forced to close 800 stores due to a
  cyber-attack (Eurnews)
Bypassing macOS TCC User Privacy Protections By Accident and Design
  (Sentinel One)
"Alexa, do this" (BBC)
Latency, overuse of cache, and integrity (Rob Slade)
On testing production voting systems (Douglas W Jones)
Re: Major Step Forward for Quantum Error Algorithms (Rob Slade)
Re: Supreme Court sides with credit agency (Steve Klein)
Re: Government Chatbots Now a Necessity for States, Cities, Counties
  (John Levine, Toebs Douglass)
Re: German States want compulsory pre-installed youth protection
   (Amos Shapir, elvis-85781)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Sat, 3 Jul 2021 21:45:00 +0000 ()
From: "danny burstein" <dannyb () panix com>
Subject: Power outage knocks Houston 911 call center offline for several
  hours (Houston Chronicle)

  [... 'cuz, well, Texas]

A power outage knocked Houston's 911 system offline for several hours
Saturday afternoon, officials said.

The incident began when the Houston Emergency Center lost power mid-day
Saturday, Houston Fire Chief Sam Peña said. Generators restored power, but
when the regular power came back on, a technical malfunction prevented the
call center from restoring power to its computer aided dispatch system, he
said.

https://www.houstonchronicle.com/news/houston-texas/houston/article/Power-outage-knocks-Houston-911-call-center-16292077.php

------------------------------

Date: Fri, 2 Jul 2021 15:40:33 -0700
From: "Lauren Weinstein" <lauren () vortex com>
Subject: An apparent supply chain attack exploited Kaseya's IT management
  software to encrypt a "monumental" number of victims all at once (WiReD)

An apparent supply chain attack exploited Kaseya's IT management
software to encrypt a "monumental" number of victims all at once

https://www.wired.com/story/kaseya-supply-chain-ransomware-attack-msps/

------------------------------

Date: Sun, 4 Jul 2021 14:16:15 -0600
From: "Matthew Kruk" <mkrukg () gmail com>
Subject: Major ransomware attack aimed at tech provider leaves other
  companies scrambling (CBC)

https://www.cbc.ca/news/world/cyberattack-ransomware-kaseya-1.6089578

Businesses around the world rushed Saturday to contain a ransomware attack
that has paralyzed their computer networks, a situation complicated in the
U.S. by offices lightly staffed at the start of the Fourth of July holiday
weekend.

It's not yet known how many organizations have been hit by demands that they
pay a ransom in order to get their systems working again. But some
cybersecurity researchers predict the attack targeting customers of software
supplier Kaseya could be one of the broadest ransomware attacks on record.

------------------------------

Date: Thu, 1 Jul 2021 12:07:31 +0800
From: "Richard Stein" <rmstein () ieee org>
Subject: With cyberattacks growing more frequent and disruptive, a unified
  approach is essential (Techxplore.com)

https://techxplore.com/news/2021-06-cyberattacks-frequent-disruptive-approach-essential.html

'"Historically, nations do not settle arms race until a mutual assured
destruction situation presents itself. Russian cyberattacks could be viewed
as an attempt to reach this point. Until we get closer to the mutual assured
destruction point, do not expect an international treaty anytime
soon. Instead, expect more cyberattacks and data losses.  Organizations and
governments need to get serious and buckle up -- it's going to be a rough
ride."'

Not hard to imagine scenarios that might quickly escalate.

Here's one: one nation's favorite junk food supplier is knocked out by a
malicious, and misattributed, cyber assault; popular outrage compels
political leadership to reciprocate.

"Staines, get Premier Kissoff on the hot line!"

------------------------------

Date: Thu, 1 Jul 2021 12:16:23 +0800
From: "Richard Stein" <rmstein () ieee org>
Subject: Study finds variations in quantitative MRI scanners' measurements
  (medicalxpress.com)

https://medicalxpress.com/news/2021-06-variations-quantitative-mri-scanners.html

"Earlier efforts to use T1 values to categorize brain tumors were impeded by
technical inconsistencies and found to be unreliable. But recent advances in
quantitative measurement methods have led to improvements in accuracy,
repeatability and acquisition speed. The new study is a step toward applying
diagnostic threshold T1 measurement across multiple clinical sites."

Risk: Inconsistent MRI data weights skew diagnostic accuracy.

------------------------------

Date: Thu, 1 Jul 2021 14:15:22 +0800
From: "Richard Stein" <rmstein () ieee org>
Subject: Research lays groundwork for restoring lost oral functions with
  pacemaker-like devices (medicalxpress.com)

https://medicalxpress.com/news/2021-06-groundwork-lost-oral-functions-pacemaker-like.html

"Within the mouth, also referred to as the intra-oral cavity, there is a
rich supply of both sensory and motor nerves. In particular, sensorimotor
nerves in the soft palate and tongue coordinate several intraoral movements
related to swallowing, speech and respiration. And so, damage to either the
sensory or motor nerve fibers due to neurotrauma or disease can compromise
these essential functions, reducing the quality of life of those afflicted.

"Electrical nerve stimulation might help jumpstart the nerves into action,
much like how a pacemaker can electrically stimulate nerves in the heart,
causing the heart muscle to contract. But unlike a pacemaker, the details on
the frequency and amplitude of the electrical currents needed for proper
stimulation of different parts of the mouth have not been investigated."

An implanted medical device to re-enable paralyzed intraoral muscular
actions. Like a pacemaker or ICD (signal processor plus discharge
batteries), there's inappropriate shock risk.

The stimulated mandibular contraction might shatter teeth or dislodge
fillings if the electrical pulse is too strong or not subject to duty cycle
restraint or fail-safe. Infection risk from implantation/explanation, broken
electrodes, battery depletion, oral bacteria migrating into the body can be
especially fatal, etc.  -- Richard M. Stein rmstein () ieee org

------------------------------

Date: Fri, 2 Jul 2021 12:23:49 -1000
From: geoff goodfellow <geoff () iconia com>
Subject: Rethinking Application Security in the API-First Era
  (The Hacker News)

Securing applications it the API-first era can be an uphill battle. As
development accelerates, accountability becomes unclear, and getting
controls to operate becomes a challenge in itself. It's time that we rethink
our application security strategies to reflect new priorities, principles
and processes in the API-first era. Securing tomorrow's applications begins
with assessing the business risks today.  The trends and risks shaping
today's applications

As the world continues to become more and more interconnected via devices —
and the APIs that connect them — individuals are growing accustomed to the
frictionless experience that they provide. While this frictionless reality
is doubtlessly more user-friendly, i.e., faster and more convenient, it also
requires a trade-off. This convenience demands openness, and openness is a
risk when it comes to cybersecurity.

According to Sidney Gottesman <https://www.linkedin.com/in/sidneygottesman/>,
Mastercard's SVP for Security Innovation, the above situation leads to one
of the biggest trends shaping the security posture for today's
applications: A crisis of trust between individuals and the applications
they use.

A second major trend is that of the supply chain. Simply handling your own
risks isn't enough, as attacks increasingly penetrate internal systems via
3rd party, vendor-supplied components. In digital products and even
connected hardware products, supply chains are now composed of different
services bundled together in the final product through APIs, creating a new
type of integration risk rooted in the supply chain. [...]

https://thehackernews.com/2021/07/rethinking-application-security-in-api.html

------------------------------

Date: Sun, 4 Jul 2021 11:46:52 -1000
From: geoff goodfellow <geoff () iconia com>
Subject: In Sweden, a supermarket chain was forced to close 800 stores due
  to a cyber-attack (Eurnews)

This is reported by Svenska Dagbladet <https://www.svd.se/>.

“One of our subcontractors was affected by a computer attack, and for this
reason, our cash registers are no longer working,” Coop Sweden, which
represents about 20% of the sector in the Nordic country, said in a press
release. [...]
https://eurnews.net/in-sweden-a-supermarket-chain-was-forced-to-close-800-stores-due-to-a-cyber-attack/

------------------------------

Date: Sun, 4 Jul 2021 10:53:49 -1000
From: geoff goodfellow" <geoff () iconia com>
Subject: Bypassing macOS TCC User Privacy Protections By Accident and Design
  (Sentinel One)

Executive Summary

   - TCC is meant to protect user data from unauthorized access, but
   weaknesses in its design mean that protections are easily overridden
   inadvertently.
   - Automation, by design, allows Full Disk Access to be *backdoored*
   while also lowering the authorization barrier.
   - Multiple partial and full TCC bypasses are known, with at least one
   actively exploited in the wild.
   - TCC does not prevent processes reading and writing to *protected*
   locations, a loophole that can be used to hide malware.

Introduction

In recent years, protecting sensitive user data on-device has become of
increasing importance, particularly now that our phones, tablets and
computers are used for creating, storing and transmitting the most sensitive
data about us: from selfies and family videos to passwords, banking details,
health and medical data and pretty much everything else.

With macOS, Apple took a strong position on protecting user data early on,
implementing controls as far back as 2012 in OSX Mountain Lion under a
framework known as *Transparency, Consent and Control*, or TCC for short.
With each iteration of macOS since then, the scope of what falls under TCC
has increased to the point now that users can barely access their own data
-- or data-creating devices like the camera and microphone -- without
jumping through various hoops of giving *consent or *control* to the
relevant applications through which such access is mediated.

There have been plenty of complaints about what this means with regards to
usability, but we do not intend to revisit those here. Our concern in this
paper is to highlight a number of ways in which TCC fails when users and IT
admins might reasonably expect it to succeed.

We hope that by bringing attention to these failures, users and admins might
better understand how and when sensitive data can be exposed and take that
into account in their working practices.  Crash Course: What's TCC Again?
[...]

https://labs.sentinelone.com/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/

------------------------------

Date: Fri,  2 Jul 2021 01:47:16 -0400 (EDT)
From: Mark Brader <msb () Vex Net>
Subject: "Alexa, do this" (BBC)

http://www.bbc.co.uk/news/technology-57680173

  [Parents of children named Alexa are complaining to Amazon.  PGN]

------------------------------

Date: Thu, 1 Jul 2021 12:01:02 -0700
From: Rob Slade <rslade () gmail com>
Subject: Latency, overuse of cache, and integrity

I love libraries.  I love books, I love information, and I love free access
to information.

I love my local library.  It uses Bibliocommons.  If you use online
services related to your library, you may be familiar with it, even if you
don't realize it, because Bibliocommons seems to be/sell/provide a sort of
"Interface-as-a-Service" to libraries.  As such, I have become accustomed
to sending Bibliocommons bug reports to our local library IT guy.

One of the services Bibliocommons supports is a "For Later Shelf."  This is
a list, that you can populate, of items you'd like to look at some time,
but not put on hold right now.  I usually run with about 250 items on my
list.  As a result of Gloria asking that I vary some of our DVD fare, I did
some searching and added about another 75 items to my list yesterday.

At which point, I couldn't find a whole bunch of stuff that had been on my
list for some time.  I tried various ways to recover pages of items that I
knew must be there, to no avail.  I even tried logging out and back in
again, and still couldn't see the whole list.  (During some of my attempts
I started to see pages duplicating what had already been shown, even when I
asked for something else.  It was very strange.)

I did, finally, get my full list back, by starting at the beginning, and
stepping through the entire list.  Obviously nothing had happened to the
data, but the display had been very strange through numerous attempts.

I've seen something similar, in a much smaller way, when I have *removed*
items from the "For Later" list.  Frequently, when I do so, and look at
other pages, the subsequent pages still seem to assume that the removed
item is still there, and display accordingly.

Bibliocommons has a definite problem with latency.  Logging on can take
over a dozen seconds, even though it's a very simple (and not *terribly*
secure) process.  Requesting the next page in a list can take even longer.
I strongly suspect that, in an effort to reduce latency, Bibliocommons
makes extensive (probably *very* extensive) use of caching.  But the result
is that the information the system gives back is slightly incorrect.

Which raises an issue for applications security.  There are generally
unintended consequences to our "fixes" for a given problem.  I am reminded
of a quote from Larry Wall: "Optimizations always bust things, because all
optimizations are, in the long haul, a form of cheating, and cheaters
eventually get caught."

------------------------------

Date: Wed, 30 Jun 2021 22:27:42 +0000
From: "Jones, Douglas W" <douglas-w-jones () uiowa edu>
Subject: On testing production voting systems

My old research group's work was motivated by the fact that every single
tabulation system I have ever examined for RCV/IRC/STV schemes has been
incorrect.

This brings to mind two stories:
  [The first one is based on information from Joe Kiniry.  This entire item
  is reproduced from a private list, with permission from both Joe and Doug.
  PGN]

1) J Paul Gibson, from Ireland but more recently on the faculty at Telcom
   Sudparis (France) investigated the STV voting system in use in Ireland.
   One thing he determined was that the official Irish law setting out the
   rules for tabulating the election, in Gaelic, had been somewhat
   mistranslated into English.  Then, the Delphi software used to implement
   those rules -- written from the English version of the law, contained
   errors.  So, he took the question to the Irish Supreme Court.

Their ruling horrified him.  They ruled that the software was the law.  This
was an expedient ruling, because it eliminated the possibility that the
ruling would call any past elections into question.  However, given that the
code is not easy to understand and not immortal, it means that anyone trying
to port the code to a newer platform will have to port the errors and
misunderstandings in that code and not merely implement what is in one or
the other versions of the law.

2) My students and I were asked by the Student Senate at the University of
   Iowa to write IRV tabulation software for student government elections.
   So, of course, we asked them what the rules for an IRV election were.
   They said, in effect, that it was simple, you just run multiple rounds
   eliminating the loser in each round.  So, of course, I asked the
   dangerous question: What if there is a tie for loser?  Who do you
   eliminate then?  Their answer boiled down to "duh..."

The problem is, I can think of several rules: Eliminate all who tie for
loser.  Eliminate the one who had the fewest votes in the most recent
previous round where they differed (look back).  Eliminate the one who will
have the fewest votes in the next round if you eliminate the others who tied
(look forward).  Eliminate one at random.  Of course, these can be combined,
so I can imagine this rule:

In case of tie, eliminate the candidate who had the least votes in some
previous round where they differed, unless they were tied in all previous
rounds.  In that case, eliminate the candidate who would receive the fewest
new votes if the other tied candidates were eliminated.  If that does not
resolve the tie, throw the dice to pick the loser.

The student government response was: "but ties are improbable!"  There, they
were certainly wrong.  We're talking about ties for loser, not ties for
winner.  In any election with more than a few candidates, most of them will
receive only a very small number of votes.  Ties for loser are far more
likely than ties for winner.

After we hashed that out, my students wrote the software to process the CVRs, and I (working independently) counted the 
votes by hand (with machine assist -- I used vi plus sort to do it on a Unix system).  The winner was the one who'd 
have won by straight plurality based on the first round, but the election went for 3 rounds before anyone got 50%.

It is remarkably hard for typical software engineers to codify tabulation
algorithms based upon statutory descriptions of complex election schemes.

Amen, and that certainly doesn't imply that those who wrote the statute
understood what they wrote!

------------------------------

Date: Thu, 1 Jul 2021 12:20:46 -0700
From: Rob Slade <rslade () gmail com>
Subject: Major Step Forward for Quantum Error Algorithms (RISKS-32.74)

"Researchers at the University of Sydney have raised the threshold
for correcting quantum calculation errors with the help of the
Gadi supercomputer of Australia's National Computational Infrastructure
(NCI) organization. The researchers used Gadi to run about 87
million simulations for all possible qubit arrangements and aligned the
threshold with the actual error rates of physical quantum computing
systems."

The thing is, that we are using a supercomputer, and calculations that
we can't possibly check for errors, ourselves, to figure out whether
quantum computers, when we finally get them, are telling us the truth.

I am afraid that the concept of "trusted platform," already seriously
bruised, is really going to be
hammered over this type of thing ...

------------------------------

Date: Wed, 30 Jun 2021 21:34:48 -0400
From: "Steve Klein" <steven () klein us>
Subject: Re: Supreme Court sides with credit agency (WashPost, RISKS-32.74)

Before we go slamming the Supreme Court of the United States, I think it’s
worth clarifying an important point.

Yes, TransUnion had records on about 8,000 people that erroneously
identified them as terrorists or drug traffickers.  And yes, for some small
number of people, TransUnion share that information with third parties.

Those people were not the subject of this case, and their class action
lawsuit against TransUnion stands.

The court simply ruled that the people whose faulty records that were never
shared couldn't be part of the class, because they could not have suffered
any damages.

Put another way: No harm, no foul.

------------------------------

Date: 30 Jun 2021 20:43:34 -0400
From: "John Levine" <johnl () iecc com>
Subject: Re: Government Chatbots Now a Necessity for States, Cities, Counties
  (Douglass, RISKS-32.74)

> I have never, *not once*, had a useful interaction with a chatbot.

I have, but only in very specific contexts.

One time I bought a case of Vegemite (I like it, so sue me) from Amazon
which was poorly packed and some of the bottles broke.  Their chatbot
walked me through a straightforward process to identify the item  I was
asking about.  Then, since it was obviously a chatbot, I just typed some
keywords, something like badly packed broken bottles.

OK, it said, we'll give you a full refund.  Since 9 of the 12 bottles
weren't broken, I didn't argue.

I agree that once you get out of situations like this where there's
not many things you're likely to say, they turn into frustration loops.

------------------------------

Date: Thu, 1 Jul 2021 11:37:36 +0200
From: "Toebs Douglass" <risks () winterflaw net>
Subject: Re: Government Chatbots Now a Necessity for States, Cities, Counties
  (Levine, RISKS-32.74)

I have just had a personal experience of a particular bot-related weakness.

I have bank accounts in various countries.

It turns out the bot for the particular bank I am at this moment using does
not understand English... ...and I, being a heathen native English speaker,
do not, of course, speak any other language (well, not more than enough to
make hapless locals ears bleed, and certainly anyway only to speak, not to
write).

Now, if it were an FAQ, I could use Google Translate to get something I
could understand, but I can't use Google Translate to get something the bot
understands.

------------------------------

Date: Thu, 1 Jul 2021 18:05:38 +0300
From: "Amos Shapir" <amos083 () gmail com>
Subject: Re: German States want compulsory pre-installed youth protection
  filters (RISKS-32.74)

It seems that these legislators cannot distinguish between an operating
system and a browser.  They still think in terms of one device connected by
a wire to a single server where a file is stored.

Just for example, the contents of the news report page cited here, are
loaded from dozens of web sources, some of which are generated on the fly
while the page is being displayed.

On the receiving end, on my standard Windows system, there are about 20
icons of popular applications on the desktop; just out of these, I counted
10 which are capable of accessing web addresses and displaying their
contents.

How do they think they can include all of these in their filtering scheme?

------------------------------

Date: Thu, 01 Jul 2021 22:26:26 +0100
From: elvis-85781 () notatla org uk
Subject: Re: German States want compulsory pre-installed youth protection
  filters (Koenig, RISKS-32.74)

As seen in "Rethinking Public Key Infrastructures and Digital Certificates:
Building in Privacy" (by Stefan Brands) verification of age (or other
properties) does not require disclosing the age.  Since the book is over 20
years old (the link does disclose the age) any patent obtained then should
have expired.
<https://www.amazon.com/Rethinking-Public-Infrastructures-Digital-Certificates/dp/0262024918/>

Even without such innovation I don't know why the website (as opposed to the
browser/user-agent) would need to know whether the user is above a given
age.

------------------------------

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.75
************************