RISKS Forum mailing list archives

Risks Digest 31.92


From: RISKS List Owner <risko () csl sri com>
Date: Sat, 30 May 2020 17:26:04 PDT

RISKS-LIST: Risks-Forum Digest  Saturday 30 May 2020  Volume 31 : Issue 92

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

  Contents:
Russian hackers exploiting bug that gives control of U.S. servers
  (Ars Technica)
Google cautions EU on AI rule-making (techxplore)
The mobile testing gotchas you need to know about (Functionize)
You're sold on load testing. But for what "unreasonable" load should you
  test? (Functionize)
SaltStack authorization bypass (f-secure)
Dangerous SHA-1 crypto function will die in SSH linking millions of
  computers (Ars Technica)
Choosing 2FA authenticator apps can be hard. Ars did it so you don't have to
  (Ars Technica)
Twitter's decision to label Trump's tweets was two years in the making
  (WashPost)
The Underground Nuclear Test That Didn't Stay Underground (Atlas Obscura)
Re: Misinformation (Henry Baker)
Re: Zoom security / updates / crypto (Monty Solomon)
Abridged info on RISKS (comp.risks)

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

Date: Sat, 30 May 2020 09:43:38 -0400
From: Monty Solomon <monty () roscom com>
Subject: Russian hackers exploiting bug that gives control of U.S. servers
  (Ars Technica)

Sandworm group uses emails to send root commands to buggy Exim servers.

https://arstechnica.com/information-technology/2020/05/russian-hackers-are-exploiting-bug-that-gives-control-of-us-servers/

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

Date: Sat, 30 May 2020 01:12:00 -1000
From: geoff goodfellow <geoff () iconia com>
Subject: Google cautions EU on AI rule-making (techxplore)

Google warned on Thursday that the EU's definition of artificial
intelligence was too broad and that Brussels must refrain from
over-regulating a crucial technology.

The search and advertising giant made its argument in feedback to the
European Commission, the EU's powerful regulator that has reached out to big
tech as it draws up ways to set new rules for AI.

The EU has not decided yet on how to regulate AI, but is putting most of its
focus on what it calls "high risk" sectors, such as healthcare and
transport.

It's plans, to be spearheaded by EU commissioners Margrethe Vestager and
Thierry Breton, are not expected until the end of the year.

"A clear and widely understood definition of AI will be a critical
foundational element for an effective AI regulatory framework," the company
said in its 45-page submission.

The EU's own definition of AI was so broad that it "effectively puts all
contemporary software potentially in scope," it said. [...]
https://techxplore.com/news/2020-05-google-cautions-eu-ai-rule-making.html

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

Date: Fri, 29 May 2020 23:52:02 -0400
From: Gabe Goldberg <gabe () gabegold com>
Subject: The mobile testing gotchas you need to know about (Functionize)

Testing applications on mobile devices has its own set of perils.  For how
many of these are you prepared?

https://www.functionize.com/blog/the-mobile-testing-gotchas-you-need-to-know-about/

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

Date: Fri, 29 May 2020 23:46:22 -0400
From: Gabe Goldberg <gabe () gabegold com>
Subject: You're sold on load testing. But for what "unreasonable" load
  should you test? (Functionize)

Load testing --– where you discover the point at which a computer system
fails -– is based on preparing for (graceful) failure by knowing its
breaking point.  Successful load testers anticipate high demand -- but at
what point do you pass from *high demand* to *ridiculous*? The guideline:
Expect the unexpected.

https://www.functionize.com/blog/youre-sold-on-load-testing-but-for-what-unreasonable-load-should-you-test/

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

Date: Sat, 30 May 2020 09:42:16 -0400
From: Monty Solomon <monty () roscom com>
Subject: SaltStack authorization bypass (f-secure)

The vulnerabilities described in this advisory allow an attacker who can
connect to the "request server" port to bypass all authentication and
authorization controls and publish arbitrary control messages, read and
write files anywhere on the "master" server filesystem and steal the secret
key used to authenticate to the master as root. The impact is full remote
command execution as root on both the master and all minions that connect to
it.

The vulnerabilities, allocated CVE ids CVE-2020-11651 CVE-2020-11652, are of
two different classes. One being authentication bypass where functionality
was unintentionally exposed to unauthenticated network clients, the other
being directory traversal where untrusted input (i.e. parameters in network
requests) was not sanitized correctly allowing unconstrained access to the
entire filesystem of the master server.

https://labs.f-secure.com/advisories/saltstack-authorization-bypass

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

Date: Sat, 30 May 2020 10:12:59 -0400
From: Monty Solomon <monty () roscom com>
Subject: Dangerous SHA-1 crypto function will die in SSH linking millions
  of computers (Ars Technica)

Lagging far behind others, SSH developers finally deprecate aging hash
function.

https://arstechnica.com/information-technology/2020/05/dangerous-sha-1-crypto-function-is-about-to-die-in-ssh/

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

Date: Sat, 30 May 2020 10:21:33 -0400
From: Monty Solomon <monty () roscom com>
Subject: Choosing 2FA authenticator apps can be hard. Ars did it so you
  don't have to (Ars Technica)

Losing your 2FA codes can be bad. Having backups stolen can be worse. What
to do?

https://arstechnica.com/information-technology/2020/05/choosing-2fa-authenticator-apps-can-be-hard-ars-did-it-so-you-dont-have-to/

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

Date: Fri, 29 May 2020 23:50:37 -0400
From: Monty Solomon <monty () roscom com>
Subject: Twitter’s decision to label Trump's tweets was two years in the making
  (WashPost)

The social media giant for the first time this week labeled three of the
president's tweets

https://www.washingtonpost.com/technology/2020/05/29/inside-twitter-trump-label/

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

Date: Fri, 29 May 2020 23:21:33 -0400
From: Gabe Goldberg <gabe () gabegold com>
Subject: The Underground Nuclear Test That Didn't Stay Underground
  (Atlas Obscura)

  [Old item, but a reminder that we don't know what we don't know,
  and when we think we know it, we still don't.  PGN]

Three and half minutes into the test, it was clear that something had gone
wrong.

At 7:30 a.m. on 18 Dec 1970, the Baneberry test began at the Nevada Test
Site. A nuclear bomb had been lowered into a hole a little more than seven
feet in diameter. More than 900 feet underground, the bomb -- relatively
small for a nuclear bomb -- was detonated.

Less than a decade before, after the U.S. signed onto the Partial Test Ban
Treaty, nuclear testing had gone underground. The treaty was meant to stop
the venting of nuclear materials into the atmosphere and limit human
exposure to radioactive fallout. But the Baneberry test, named for a desert
shrub, did not go as planned.

https://www.atlasobscura.com/articles/do-underground-nuclear-tests-have-fallout

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

Date: Sat, 30 May 2020 09:30:06 -0700
From: Henry Baker <hbaker1 () pipeline com>
Subject: Re: Misinformation (Walker, RISKS-31.91)

Re: "I'm sure that those making professional use of MC methods know all
about ..."

Andy Walker is certainly correct that slow convergence of Monte Carlo
methods can be improved through various mitigation techniques, including
"biasing" techniques.

However, his assumption that those behind the Imperial model "know all about
..." may be unreasonably generous, as the Imperial model has already been
shown to produce dramatically varying results depending upon the random
numbers used.  If these mitigation techniques had worked well in the
Imperial model, this dependence on the particular sequence of random numbers
should have averaged out over enough runs, but they didn't.

Both my toy "Bernoulli" model and my toy lognormal model for the *product*
of independent random samples have closed form solutions, so toy systems can
often be mathematically tractable when a more "realistic" model such as the
Imperial model cannot be.  I claim that attempting Walker's mitigations for
the Imperial model would require a proof that the mitigations only improve
convergence and would not change the eventual answers.

Walker has still not addressed the basic mathematical fact that
distributions with gigantic variances have no useful predictive value, and
hence do not fit the definition of 'science'.

E.g., my toy Bernoulli product model can be represented exactly with a
*probability generating function*:

  [PGN has inserted "|" at the beginning of lines that might break old
  digest undigestifiers.  PLEASE IGNORE EACH  "|".]

G(z,p,q,a,b,n):

 n
====     k                     i  n-i
\                    i  n-i  a  b
  binomial(n, i) p  q    z
/
====
i = 0

where p=1/100,q=99/100,a=98,b=2,n=10.

Mean(G):
           10
(b q + a p)

I.e., mean^10 of a single Bernoulli sample, as
expected.

With p=1/100,q=99/100,a=98,b=2, this mean is:

  4923990397355877376
| -------------------  ~  51631.78154897835
    95367431640625

Var(G),p=1/100,q=99/100,a=98,b=2:

  909494701748682556481786171327006234749251354624
| ------------------------------------------------
            9094947017729282379150390625

rounded to an integer is:

99999999997334159134 ~ 10^20

This is an astoundingly high variance, which indicates that the probability
density is almost zero almost everywhere.

Similarly, my toy lognormal distribution L(m,v):

                       2
         (log(x) - m n)
       - -------------
             2 n v
       %e
|  -----------------------------
  sqrt(2) sqrt(%pi) sqrt(n v) x

has mean:

  n v
  --- + m n
   2
%e            ~ 51631.78154897708

and variance:

   n v        n v + 2 m n
(%e    - 1) %e             ~ 9.9999999997E+19

The value of the lognormal pdf at the mean is:

          5 n v
        - ----- - m n
            8
        %e
  --------------------------- ~ 7.4643385877E-8
  sqrt(2) sqrt(%pi) sqrt(n v)

i.e., 1/13397034, a probability density of 1 in ~14 million.

Thus, the pdf is almost *flat*, as well as almost infinitesimal, from some
small fraction of the mean to some large multiple of the mean.

Thus, there is nothing to particularly choose the 'mean' over any other
'nearby' (or in this case, no-so-nearby) value as 'the answer'.

This is a generic problem with exploding variances, which cannot be
mitigated, because it is an essential feature/bug resulting from
exponentiating large variance random variables.

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

Date: Fri, 29 May 2020 23:55:37 -0400
From: Monty Solomon <monty () roscom com>
Subject: Re: Zoom security / updates / crypto

Reminder on Zoom 5.0 — update your clients before May 30

Zoom 5.0 became generally available on April 27, and a system-wide account
enablement to AES 256-bit GCM encryption will occur on May 30, 2020. Only
Zoom clients on version 5.0 or later, including Zoom Rooms, will be able to
join Zoom Meetings starting that day. We urge all users to update to Zoom
5.0 or higher today, if you have not done so already.

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

Date: Mon, 14 Jan 2019 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
     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-31.00
  Lindsay has also added to the Newcastle catless site a palmtop version
  of the most recent RISKS issue and a WAP version that works for many but
  not all telephones: http://catless.ncl.ac.uk/w/r
  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 31.92
************************


Current thread: