We do often include affiliate links to earn us some pennies. See more here.

VUSec have published and shown an example of a newly discovered flaw present with both Intel and AMD processors when used with Linux.

BlindSide allows attackers to “hack blind” in the Spectre era. That is, given a simple buffer overflow in the kernel and no additional info leak vulnerability, BlindSide can mount BROP-style attacks in the speculative execution domain to repeatedly probe and derandomize the kernel address space, craft arbitrary memory read gadgets, and enable reliable exploitation. 

It's quite a wide-reaching security issue too which they mentioned testing being successful across Intel Skylake, Kaby Lake and Coffee Lake microarchitectures and additionally AMD Zen+ and Zen2 microarchitectures with their testing overcoming the latest mitigations too.

Going by what they said in the full paper, the issue is present in the Linux Kernel from v3.19 up to v5.8 so that's potentially a lot of systems. They said it means that "an attacker armed with a write vulnerability can perform BlindSide attacks on a wide range of recent production Linux kernel versions even when blind to the particular kernel version".

They showed off a demo of it in action too:

YouTube Thumbnail
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Accept Cookies & Show   Direct Link

The conclusion of their paper:

We presented BlindSide, a new exploitation technique that leverages an underexplored property of speculative execution (i.e., crash/execution suppression) to craft speculative probing primitives and lower the bar for software exploitation. We showed our primitives can be used to mount powerful, stealthy BROP-style attacks against the kernel with a single memory corruption vulnerability, without crashes and bypassing strong Spectre/randomization-based mitigations.

As always, ensure you're regularly checking for updates. It's better to be up to date and safe, than think some specific situations won't apply to you. Better safe than sorry.

You can see the full paper here and their blog post here. Hat tip to Phoronix.

Article taken from GamingOnLinux.com.
18 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
14 comments
Page: 1/2»
  Go to:

denyasis Sep 12, 2020
Interesting. IIRC, the spectre type mitigations we're rather theoretical (although still possible). This stuff is a little over my head, but how realistic if an attack vector is this? Like visiting a compromised website or downloading a compromised file?
gojul Sep 12, 2020
With fill ASLR which is now the standard on most dostros the issue is greatly reduced (source : the end of the paper)
denyasis Sep 12, 2020
Thanks, I tried to read a bit, but it was way over my head. I'm seriously jealous of this of you who can program and understand this stuff
TheSHEEEP Sep 12, 2020
View PC info
  • Supporter Plus
Quoting: denyasisI'm seriously jealous of this of you who can program and understand this stuff
I'm a programmer since 10+ years and even I barely understand half of it
GustyGhost Sep 12, 2020



To be fair, there are probably a shit ton of undiscovered vulns for Power9.
3zekiel Sep 12, 2020
Quoting: GustyGhost


To be fair, there are probably a shit ton of undiscovered vulns for Power9.

Actually, can you run steam games on powerpc with qemu usermod ?
3zekiel Sep 12, 2020
Quoting: denyasisThanks, I tried to read a bit, but it was way over my head. I'm seriously jealous of this of you who can program and understand this stuff

To make it simple, all these attacks are based on finding bits and pieces of information left in the CPU state.
These information can be various things: the presence of anything (or its absence) in your L1/L2/L3 cache, the state of the branch predictor in some spectre attacks, the state even of some specific cache (the tlb). All those caches are made to usually accelerate your cpu, whenever you do something costly, such as translating virtual to physical address, you put it in a cache in the hope that you will reuse it later (preferably soon).

Now, the problem is that, to go as fast as possible, when a program that does not have the right to access the data in theses caches tries to access the data, it still procedes almost the same as if it had the right to. The only difference is that at the very end an error will be raised. But the speed at which this error occurs will be faster if the data was here, or if the branch would have been taken etc etc.

So now, imagine that you execute a program on the same core as the program you want to attack, you would indeed share all those caches. As such, you will be able to measure time you take to get refused access to various data, with different types of accesses (direct access, branches, etc etc).
The result is that you can then infer a lot of stuff on the program. For branches in particular let's the say you write a code like "if(data != 0) then smthg else another thing" . Then if you can recover the "state" of that branch (what the branch predictor was corrected with), then you can deduce that data is 0 or not.
With other attacks, if you try to branch depending on the value of a private data for example, you might be able to deduce the value too. for example, you try if (forbidden_data == 0), and then you measure time of execution, or you find the state of the branch predictor afterwards (by trying to take the same branch and see if "taken" or "not taken" path is faster), and you can deduce that forbidden_data is equal to 0 or not. If you proceed byte by byte, you should only have to test 255 values at worst for each bytes. If you search for a 256bits AES key, that makes it 32 bytes, so 32 times 255. Even if you need multiple tries in reality, that really really not a lot.

For one of the spectre attack, what you essentially did was just make an access like this one:
read(array[forbidden_data]) where forbidden_data is a byte. The access will be refused, but the value at array[forbidden_data] will be cached by the cpu. Then you just read back every indices of the array, and the index which was represented by forbidden_data will have an access time that will be slightly faster than the rest of the array, telling you the exact value of forbidden data. You do need a bit of setup between each runs of the attack, (you need to load a large piece of data to make the cache filled with something else), but that's actually fairly efficient, a rogue javascript script could have begun guessing at what other scripts (such as the one where you put your passwords / credit card number...) were having in memory.

Hope this clarifies a little bit. But yeah, this is not so much programmer stuff as CPU architect / OS engineers stuff.


Last edited by 3zekiel on 13 September 2020 at 11:09 am UTC
GustyGhost Sep 12, 2020
Quoting: 3zekielActually, can you run steam games on powerpc with qemu usermod ?

Or a Wine accompaniment program called Hangover, IIRC. Although I don't personally have any interest in running proprietary gaming software.
Koopacabras Sep 12, 2020
I'm starting too look my old trusty Moto E2 with a lot of affection.
3zekiel Sep 13, 2020
Quoting: GustyGhost
Quoting: 3zekielActually, can you run steam games on powerpc with qemu usermod ?

Or a Wine accompaniment program called Hangover, IIRC. Although I don't personally have any interest in running proprietary gaming software.

Yeah, Hangover is also based on qemu user mode. If it works that's very cool :)
For me, I think games are art, as such, they don't really enter the "proprietary software" category. For the privacy part, I run steam in a sandbox.
I'm way more concerned with what "ring -1" stuff my CPU runs behind my back, because no sandbox and pretty much no analysis can save you from that ...
I'm just concerned by how usable the platform would be (Power based I mean).


Last edited by 3zekiel on 13 September 2020 at 11:14 am UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.