• Risks Digest 32.75

    From RISKS List Owner@21:1/5 to All on Mon Jul 5 02:46:49 2021
    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
    ************************

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)