[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)