You can sign up to get a daily email of our articles, see the Mailing List page!

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.
19 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more here.
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.
See more from me
15 comments
Page: 1/2»
  Go to:

denyasis 12 Sep
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 12 Sep
With fill ASLR which is now the standard on most dostros the issue is greatly reduced (source : the end of the paper)
mirv 12 Sep
View PC info
  • Supporter Plus
Quoting: denyasisInteresting. 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?

On the one hand, it's less of a target to a single home user - but on the other hand it's probably not as easily detected (because no techie looking at why a server load has suddenly gone a little strange).

Note that this attack is something that "requires a stack vulnerability and a service that restarts after a crash". BlindSide can be thought of as widening or increasing the scope and seriousness of an attack; it's main feature is giving additional information that isn't normally available.

More critically, this attack basically makes one feature of closed binaries obsolete: security through obscurity. The main goal explained here is to "write exploits without any knowledge of target binary or source code". There are also mitigations that can be performed to reduce the effectiveness.

In summary, don't panic, and apply updates on a regular basis. The usual basically.
denyasis 12 Sep
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 12 Sep
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 12 Sep
To be fair, there are probably a shit ton of undiscovered vulns for Power9.


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


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 12 Sep
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 12 Sep
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.
I'm starting too look my old trusty Moto E2 with a lot of affection.
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

We have no adverts, no paywalls, no timed exclusive articles. Just 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!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.

Livestreams & Videos
Community Livestreams
Latest Forum Posts