News: 1615245747

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Google engineer urges web devs to step up and secure their code in this data-spilling Spectre-haunted world

(2021/03/09)


After the disclosure of the [1]2018 Spectre family of vulnerabilities in modern microprocessor chips, hardware vendor and operating system makers scrambled to reduce the impact of data-leaking side-channel attacks designed to exploit the way chips try to predict future instructions.

Intel and others rolled out firmware patches, Linux kernel maintainers added capabilities like STIBP (Single Thread Indirect Branch Predictors), and browser makers took steps like reducing the precision of timers.

[2]

Now web security professionals are asking developers to do their part by recognizing that Spectre broke the old threat model and by writing code that reflects the new one.

Intel CPU interconnects can be exploited by malware to leak encryption keys and other info, academic study finds [3]READ MORE

[4]

Last month, Mike West, a Google security engineer, drafted a note titled, " [5]Post-Spectre Web Development ," and Mozilla's Daniel Veditz of the W3C's Web Application Security Working Group asked the group to come to a consensus on supporting the recommendations. While the group has yet to formally accept the proposal, the responses on the group's mailing list suggest the advice will be adopted as a set of best practices.

West argues that Spectre demonstrated the assumptions of the web security model need to be rethought, for both browser vendors and web developers. Citing post-Spectre [6]Chromium project guidelines , he said the open source browser project now assumes that "'active web content … will be able to read any and all data in the address space of the process that hosts it.'"

For browsers, this has meant projects like [7]Site Isolation and [8]Project Fission , which put web sites and associated code into separate processes so websites can't meddle with one another. And now developers have some work to do.

"The bad news is that this is going to be a lot of work, much of it falling on the shoulders of web developers," writes West. "The good news is that a reasonable set of mitigation primitives exists today, ready and waiting for use."

We should mention that we've yet to see a Spectre exploit being used in the wild to attack and steal data from a significant number of victims, so this advice seems to us more to be heading off potential future danger.

Five step program

West makes five general recommendations, which require devs to pay attention to the walls, or lack thereof, between different web resources.

First, developers should decide when their code responds or doesn't respond to incoming requests by examining incoming request headers, in accordance with the desired [9]resource isolation policy .

Second, they should set a cross-origin resource policy ( [10]CORP ) to restrict an attacker's ability to load your data as a subresource.

Third, web devs should prevent attackers from framing website data using [11]framing protections .

Academics in Israel have [12]documented , in a published paper, a method to defeat browsers' side-channel defenses using just CSS and HTML . "Avoiding JavaScript features makes our techniques architecturally agnostic," the team noted, "resulting in microarchitectural website fingerprinting attacks that work across hardware platforms including Intel Core, AMD Ryzen, Samsung Exynos, and Apple M1 architectures."

Fourth, they're advised to make sure attackers can't obtain a reference or handle to a site's window object by setting a cross-origin opener policy ( [13]COOP ).

And fifth, they're directed to implement defenses against MIME-type confusion attacks using mechanisms like cross-origin read blocking ( [14]CORB ) and opaque response blocking ( [15]ORB ) to set appropriate defensive Content-Type headers.

Without defenses like these, an attacker, for example, might be able to craft a malicious web page that refers to a JSON file as a linked image. When the page is visited, the file data would be passed to the browser's render process but wouldn't be rendered because it's not properly formatted image data. Nonetheless, the JSON could be read in memory through a Spectre exploit, potentially leading to a breach of confidentiality or security.

CORB, in this instance, could prevent the JSON from being stored in memory because it doesn't have the MIME-type of an image.

[16]

Now it's just a matter of convincing web devs to take the time to make sure their code is secure. We'll let you know when that happens. ®

Get our [17]Tech Resources



[1] https://www.theregister.com/2018/01/04/intel_amd_arm_cpu_vulnerability/

[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YEcA6dcMYEAuXv9jLFkFzwAAAEk&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[3] https://www.theregister.com/2021/03/08/intel_ring_flaw/

[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YEcA6dcMYEAuXv9jLFkFzwAAAEk&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[5] https://mikewest.github.io/post-spectre-webdev/

[6] https://chromium.googlesource.com/chromium/src/+/master/docs/security/side-channel-threat-model.md

[7] https://www.chromium.org/Home/chromium-security/site-isolation

[8] https://wiki.mozilla.org/Project_Fission/Memory

[9] https://xsleaks.dev/docs/defenses/isolation-policies/resource-isolation/

[10] https://fetch.spec.whatwg.org/#http-cross-origin-resource-policy

[11] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

[12] https://orenlab.sise.bgu.ac.il/p/PP0?k

[13] https://html.spec.whatwg.org/multipage/origin.html#cross-origin-opener-policies

[14] https://fetch.spec.whatwg.org/#corb

[15] https://github.com/annevk/orb

[16] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YEcA6dcMYEAuXv9jLFkFzwAAAEk&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[17] https://whitepapers.theregister.com/

Doomed

Throatwarbler Mangrove

A friend of mine just got back into development after years of teaching high school and is getting back up to speed on coding Web applications. I suspect his focus will be on getting his code to work at all. The application he's writing might net him a small paycheck, but his focus is going to be on nailing down future employment opportunities. I suspect that the odds of him ruthlessly sanitizing his inputs according to this model are slim. Not saying that he's not to be held accountable for secure coding, but what are the new programmers (or old, set-in-their-ways, programmers) to do? What's being described sounds like a lot of hard, painstaking work of the sort that management won't care about when it gets in the way of adding features or hitting release targets. I know that the readership of El Reg are literally the best programmers on Earth (in their own minds, at least), so what's the answer, guys?

Re: Doomed

Martin Gregorie

A new hardware and OS architecture bearing a strange resemblance to the hardware rings of protection used by operating systems like ICL's VME/B (and possibly also the Burroughs B-series and IBM/s progressively renamed Future Series->System/38->AS/400->I-Series hardware) could be as good as way as any of preventing this sort of cross-process data-stealing bug.

I've designed systems and written code for VME/B systems and never heard even a rumour of process-process interference occurring. Same for the AS/400.

CORS and other holes by design

b0llchit

Actually, most of the CORS concept and the current " we'll get code, data and content anywhere we damn please " attitude are the main problem. Any sane development and deployment would reduce the attack surface by serving your own (vetted) code from your own server(s). But that does not fit into the current strategy, which calls for bloating a site with foreign references and more uncontrolled data and code imports with patches stacked layer upon layer.

The whole idea of KISS has been lost on web-development and the complexity mountain has become so high and heavy that the base is sinking into the ground. What we require is more simplicity so it becomes easier to see through. It also would make most stuff much faster in the process and reduce traffic. A back to basics approach should be welcomed.

Re: CORS and other holes by design

TFL

I can't say that I disagree, at least to the extent that this behaviour seems to have become the norm these days.

To the extent that there may be benefits in using some of these other services, could devs not simply white-list only the things that are allowed? Defining these things should be a matter of doing it once (for a site, say), and serving up the expected headers on every damn page as part of whatever templates are used.

While each specified hole adds some element of risk, the process of documenting that arrangement and those risks should suffice with minimal maintenance.

There will be a certain set of marketing folk who will scream bloody murder of course, since they're likely responsible for having dozens of trackers and ads attached to a site, but TFB.

In the course of reading Hadamard's "The Psychology of Invention in the
Mathematical Field", I have come across evidence supporting a fact
which we coffee achievers have long appreciated: no really creative,
intelligent thought is possible without a good cup of coffee. On page
14, Hadamard is discussing Poincare's theory of fuchsian groups and
fuchsian functions, which he describes as "... one of his greatest
discoveries, the first which consecrated his glory ..." Hadamard refers
to Poincare having had a "... sleepless night which initiated all that
memorable work ..." and gives the following, very revealing quote:

"One evening, contrary to my custom, I drank black coffee and
could not sleep. Ideas rose in crowds; I felt them collide
until pairs interlocked, so to speak, making a stable
combination."

Too bad drinking black coffee was contrary to his custom. Maybe he
could really have amounted to something as a coffee achiever.