• Risks Digest 32.72 (2/2)

    From RISKS List Owner@21:1/5 to All on Wed Jun 23 05:07:30 2021
    [continued from previous message]

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

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