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:
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.
Quoting: denyasisI'm seriously jealous of this of you who can program and understand this stuffI'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.
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 ?
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.
Quoting: GustyGhostQuoting: 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
GustyGhost Sep 13, 2020
Quoting: 3zekielYeah, 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).
Being totally open, here are the hurdles that I hit moving from Debian amd64 to Debian ppc64le:
1. Some Debian packages I use were not yet buildable for PowerPC (the PowerPC repository has successful builds for 95% of packages, compared to x86), so I must build the programs for source for now.
2. Firefox had to be updated to 68 before it was fully usable. This was only a problem for Debian 10.0 and 10.1.
3. Only the cli (whiptail "GUI") installer is available on the ppc64le image, although I always install from cli anyway. This might be an issue for most others however.
Patreon
PayPal
See more from me