Meltdown/Spectre: Unauthorized Disclosure of Kernel Memory

[watersb]

I found a fork of the Spectre demo that was tweaked for Mac PowerPC, and warped it very slightly to compile on Linux with GCC 7.3.0 -- mostly a matter of replacing calls to ppc_intrinsics with their GCC_builtin equivalents.

Spectre Demo Source.c via Github Gist

The minimal set of CFLAGS that would toggle the success of the Spectre demo were

Code: Select all

-O2 -fno-plt -fno-common

. I don't know if that holds up in general. I was also able to mitigate against the demo attack with -Og.

Note that this attack relies upon cached data; it is interesting (for some value of...) to run the demo binary repeatedly, and see how the snooped data comes and goes. Optimization levels below -O2 or -Og and the secret string shows up almost immediately, if not then it converges on the secret string. With -O2, any portions of the secret string seem to quickly get flushed out: the hack can't get to the secret, and repeated attempts seem to make it less successful rather than more so.

Code: Select all

CFLAGS = -std=c99 -D__POWERPC__

MITIGATE = -O2 -pipe -fno-plt -fno-common

PROGRAM = spectre.out
SOURCE  = Source.c

all: $(PROGRAM)

$(PROGRAM): $(SOURCE) ; $(CC) $(CFLAGS) -o $(PROGRAM) $(SOURCE)

clean: ; rm -f $(PROGRAM)

safe: $(SOURCE)
	$(CC) $(CFLAGS) $(MITIGATE) -o $(PROGRAM) $(SOURCE)

"make safe" to compile with those additional flags, or just "make" to build the demo without them.


----
Linux g2ppc-mini 4.15.3-gentoo #1 Tue Feb 13 20:18:30 MST 2018 ppc 7447A, altivec supported PowerMac10,1 GNU/Linux

[mv]

The minimal set of CFLAGS that would toggle the success of the Spectre demo were

Code: Select all

-O2 -fno-plt -fno-common

I can confirm that this also suffices on x86_64 (for the unforked code).

[watersb]

Thanks mv for your per-package CFLAGS system.

I am able to set a global CFLAGS for Spectre Mitigation, but I have already run into some packages that run afoul of multiple symbol definitions with -fno-common.

/etc/portage/package.cflags makes it easy to filter CFLAGS.

Code: Select all

net-misc/openntpd        +fno-common

[mv]

some packages that run afoul of multiple symbol definitions with -fno-common.

The file portage-env-mv/package.cflags/all-systems contains filtering rules for this (and several other flags); flags with more exceptions (pie, flto, ...) are covered in separate flies in portage-env-mv.

[tholin]

Spectre Demo Source.c via Github Gist

The minimal set of CFLAGS that would toggle the success of the Spectre demo were

Code: Select all

-O2 -fno-plt -fno-common

. I don't know if that holds up in general. I was also able to mitigate against the demo attack with -Og.

The vulnerable code (victim_function) and the attacking code (readMemoryByte) are in the same program and are compiled with the same flags. You don't know if the CFLAGS makes the vulnerable code less vulnerable or the attacking code less potent. Even if the CFLAGS somehow makes the vulnerable code less vulnerable that's just by chance. The demo is a PoC for Spectre V1 and the compiler/toolchain mitigations are for Spectre V2. To mitigate V1 in the compiler you would have to identify all vulnerable code paths using static analysis but that's impossible since the compiler have no way of knowing which inputs are untrusted. Mitigating all conditional branches is possible but the slowdown would be enormous.

[mv]

Even if the CFLAGS somehow makes the vulnerable code less vulnerable that's just by chance.

True: there is no guarantee that the code is non-vulnerable, only because certain CFLAGS are used.
But if these CFLAGS make the compiler produce less vulnerable code in at least some typical exploit scenarios, one should better use these.

[watersb]

You don't know if the CFLAGS makes the vulnerable code less vulnerable or the attacking code less potent. Even if the CFLAGS somehow makes the vulnerable code less vulnerable that's just by chance. The demo is a PoC for Spectre V1 and the compiler/toolchain mitigations are for Spectre V2. To mitigate V1 in the compiler you would have to identify all vulnerable code paths using static analysis but that's impossible since the compiler have no way of knowing which inputs are untrusted. Mitigating all conditional branches is possible but the slowdown would be enormous.

(emphasis mine)

Yes. Crucial to understand these flags are not everything needed, and that we cannot defend against all such attacks with compile-time settings.

I do like to explore the compiler results, and simple Proof-of-Concept toys are fun for me; I lack the experience which might lead me to spot vulnerabilities myself. As the toolchain gets better at explaining potential errors, I try to learn from the warnings and look at source code.

If the mitigations lead to better-behaved code, then that's a win. I hope. Alas, "better-behaved" is of course not the same for all of this code: adheres to formal spec? doesn't crash? rejects insane input?

Thanks, tholin, for the does of reality.

[blopsalot]

here's my little update. i have added '-mindirect-branch*' to ALLOWED_FLAGS and have been testing using -mindirect-branch=thunk-inline universally. i am stabilizing gold and lto as well, so i cannot say safe for production yet, but I have experienced ZERO build failures as a result of using thunk-inline with otherwise safe flags.

ps: here's everything u need to know about setting per package compiler options:
https://wiki.gentoo.org/wiki//etc/portage/package.env
https://wiki.gentoo.org/wiki/Clang

[mv]

added '-mindirect-branch*' to ALLOWED_FLAGS

How did you do that? Did you patch the gentoo repository locally?

[blopsalot]

yes, it's in flag-o-matic.

[mv]

yes

I meant: How do you prevent that your change to the eclass is removed with every sync? Do you modify the eclass manually (or by a script) after every sync? Or do you maintain and merge your own git branch?

[P.Kosunen]

https://newsroom.intel.com/news/latest- ... available/

[Tony0945]

yes

I meant: How do you prevent that your change to the eclass is removed with every sync? Do you modify the eclass manually (or by a script) after every sync? Or do you maintain and merge your own git branch?

IIRC, an eclass in /usr/local/portage will override one in /usr/portage. I have some old ebuilds with eclasses that have been removed from the tree in my /usr/local/portage. Also, you could add a script to postsync_hooks (sic?) that copies the altered eclass over after every sync.

[pickd.mask]

Hello.

When I was checking my system vulnerabilities using Spectre and Meltdown mitigation detection tool v0.35, it also said that:

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel has array_index_mask_nospec: YES (1 occurence(s) found of 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch: NO
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)

I've tried to find info about this patch myself, but it seems like it's either hard to find or my english makes it hard.

So i'm curious if anybody knows what this patch is and if we, Gentoo users, actually need it or not.
Any advice would be appreciated.

[mv]

IIRC, an eclass in /usr/local/portage will override one in /usr/portage.

I haven't checked, but I doubt it. For instance, one can configure portage to store the repository in /srv/... or /var/...; from where should the overrides come? Still some hard-coded /usr/local/portage?
It is possible to specify the repository's masters, but unfortunately, this information is stored in the repository itself: This can be overridden, but then you also have to override e.g. every layman repository you use. (Moreover, I think the repository itself is checked for the eclasses before checking the masters, so perhaps it won't even work to override eclasses but just to provide removed eclasses. With this restriction it also makes sense why that information is stored in the repository itself.)

Also, you could add a script to postsync_hooks

Yes, this is one of the ideas I mentioned in my post, but it is a horrible hack which one day will fall back on you. (It might also conflict with git syncing...) Also, it breaks the md5 cache, so the metadata information of the ebuilds becomes worthless and has to be regenerated.

[Hossie]

Hello.

When I was checking my system vulnerabilities using Spectre and Meltdown mitigation detection tool v0.35, it also said that:

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel has array_index_mask_nospec: YES (1 occurence(s) found of 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch: NO
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)

I've tried to find info about this patch myself, but it seems like it's either hard to find or my english makes it hard.

So i'm curious if anybody knows what this patch is and if we, Gentoo users, actually need it or not.
Any advice would be appreciated.

As far as I can tell, the "redhat patch" is just the addition of IBRS and IBPB. This is also consistent with the comments in the script (see comments in the function check_redhat_canonical_spectre). This is the "intel way" in addition with microcode updates, the same as linus rejected.

The patch itself is not needed, but you possibly have VMs running with this patch, so hypevisor support for IBRS (with microcode) is still needed.

Dont take this all as facts, just my state of knowledge.

[pickd.mask]

As far as I can tell, the "redhat patch" is just the addition of IBRS and IBPB. This is also consistent with the comments in the script (see comments in the function check_redhat_canonical_spectre). This is the "intel way" in addition with microcode updates, the same as linus rejected.

The patch itself is not needed, but you possibly have VMs running with this patch, so hypevisor support for IBRS (with microcode) is still needed.

Dont take this all as facts, just my state of knowledge.

Thanks, that's valuable info

[MaDDeePee]

Sry if this is a stupid question....but may i ask:

Is this current problem the reason why all kernels since 4.9.76 are still marked "testing"?
We're at 4.15.4 right now...
https://packages.gentoo.org/packages/sy ... oo-sources

Thanks

[benchaney]

Sort of. There was an unrelated issue that cause all 4.14 kernels to be marked as unstable. But I do think that this issue is related to why we some other versions are slow to make it in to stable.

[Luke-Jr]

Spectre Demo Source.c via Github Gist

The minimal set of CFLAGS that would toggle the success of the Spectre demo were

Code: Select all

-O2 -fno-plt -fno-common

. I don't know if that holds up in general. I was also able to mitigate against the demo attack with -Og.

The vulnerable code (victim_function) and the attacking code (readMemoryByte) are in the same program and are compiled with the same flags. You don't know if the CFLAGS makes the vulnerable code less vulnerable or the attacking code less potent.

This doesn't make sense to me. The victim is the "secret" variable, not code. If you "fix" victim_function, an attacker could always make their own victim_function without the fix applied, no? Am I missing something?

I modified the sample code to read from a write-only mmap (https://gist.github.com/f90e7b91c847e7a ... fffd1cdffd). Assuming the attacker can use assembly, I don't see any way to get effective protection against this attack... :/

[mv]

If you "fix" victim_function, an attacker could always make their own victim_function without the fix applied, no?

If he could make this, he could simply read the data directly. For real exploits the victim runs in a different context than the attacker (either with different privileges, or the attacker is somehow otherwise limited by a sandbox of some sort, e.g. in a browser).

[Luke-Jr]

If you "fix" victim_function, an attacker could always make their own victim_function without the fix applied, no?

If he could make this, he could simply read the data directly. For real exploits the victim runs in a different context than the attacker (either with different privileges, or the attacker is somehow otherwise limited by a sandbox of some sort, e.g. in a browser).

Does that mean my mmap example is actually new Spectre variant?

[mv]

If you "fix" victim_function, an attacker could always make their own victim_function without the fix applied, no?

If he could make this, he could simply read the data directly. For real exploits the victim runs in a different context than the attacker (either with different privileges, or the attacker is somehow otherwise limited by a sandbox of some sort, e.g. in a browser).

Does that mean my mmap example is actually new Spectre variant?

??? Your question has not the slightest relation with my answer. Your "victiim" simply runs in a context which can read the mmap anyway.

[tholin]

If you "fix" victim_function, an attacker could always make their own victim_function without the fix applied, no?

That assumes the attacker can put arbitrary code in a process, but if that is possible the attacker can read the process memory even without specter vulnerabilities. That PoC only demonstrates that the cpu got the spectre v1 vulnerably. C code is used and the vulnerable code and attacking code is put in the same program because it's easier to demonstrate the vulnerability that way. Assuming that an attacker can't put arbitrary machine code in a process the attacker has to get the vulnerable code snippet into the victim some other way. Perhaps it was there all along because the programmer put it there without realizing it's dangerous or perhaps the attacker can inject it using the victims own JIT compiler. That's how google's PoC worked.

To fix the vulnerability you have to do something like this to all vulnerable code patterns.

Code: Select all

 void NOINLINE victim_function(size_t x) {
   if (x < array1_size) {
+    _mm_lfence();
     temp &= array2[array1[x] * 512];
   }
 }

Assuming the lfence instruction is serializing this will prevent the vulnerable code pattern from being speculatively executed before the boundcheck completes.

I modified the sample code to read from a write-only mmap (https://gist.github.com/f90e7b91c847e7a ... fffd1cdffd)

X86 page tables doesn't have the concept of write-only mappings. Only a single bit is used for the permission. If it's set the page is R+W and if it's clear RO. If you set PROT_WRITE you'll get a R+W mapping even without setting PROT_READ.

[Luke-Jr]

I modified the sample code to read from a write-only mmap (https://gist.github.com/f90e7b91c847e7a ... fffd1cdffd)

X86 page tables doesn't have the concept of write-only mappings. Only a single bit is used for the permission. If it's set the page is R+W and if it's clear RO. If you set PROT_WRITE you'll get a R+W mapping even without setting PROT_READ.

But the program segfaults if I try to read directly from it...?