You can do it while using microcode patches and software mitigations or not: it’s a hardening measure because SMT usually shares TLBs and L1s between threads.
No SMT, no sharing of TLBs and L1s (I know that writing it this way is a gross oversimplification).
While I'm sure there are folks that would appreciate the mitigation provided by that package, I'm not sure it provides any mitigation to this _specific_ exploit.
If you are a paid subscriber you get extra bits from VirusTotal.
One of which is you can see what files are "parents" of the sample. In this case, there are a bunch of zip files that contain this file, all named Immunity Canvas or similar. Canvas is a pentesting tool where they publish exploits, so I guess he's saying you can attribute it to Immunity.
And yes, VirusTotal lets you download the file if you pay. It's the foundation of the "threat-intelligence" industry :)
> And yes, VirusTotal lets you download the file if you pay
Indeed, so it is critical to never upload any binaries to them that you do not have full permission to redistribute. Nowadays they are very open about the sharing, but in the past this was kind of hidden.
What the other gentlepeople are saying is that if Arnold Schwarzenegger paid VirusTotal two dollars and fifty cents, he would not have to watch porn, (See the movie 'Read Heat') or exclaim Capitalism. He could just root your box. For two dollars fifty. Think the bad-guys don't subscribe to VirusTOTAL? <arnoldvoicepredator1>Think again.</arnoldvoicepredator1>
Based on the write up, I suspect you could do the attribution very quickly by downloading the binary (if you’re a VirusTotal subscriber?) and running “strings” on the file.
certainly an interesting read. says it was written in 2015 which could explain why it doesn't support modern ubuntu/fedora or maybe it was fixed in recent kernels? latest kernels i see are from the mid/late 4.x series
> - To what extend is this fixed by the mitigations which the kernel provides [0] for the Intel bugs? What do I have to add to my kernel command line?
The key part of this post is "In my lab, on a vulnerable Fedora" which means that the author is using an old, known-vulnerable version of Fedora on which to do their testing.
You don't have to do anything other than be running a reasonably modern version of the kernel that gets updates from -stable or from your distro.
BTW, this is a Spectre-v1-style exploit. These are EXTREMELY widespread across lots of processors with conditional branch speculation. It's (relatively) unrelated to the family of things like MDS or Spectre-v2 where microcode updates were issued.
Disclaimer: I work on Linux at Intel, occasionally on mitigation for this stuff.
So are the Linux kernel spectre mitigations broken or useless? I thought this was mostly patched away with a combination of microcode updates and kernel workarounds?
The author doesn't explicitly mention turning off the mitigations for testing the exploit, but that might be the case here. The article is certainly vague enough to not know for sure.
> Amusingly, this method is still working on an up to date Linux
This may refer to the whole thing working, or just the KASLR bypass part.
It's not worth it on older CPUs. I turned them off.
I understand browsers already have some protection against them now. I don't see the point in slowing down the entire system, either I trust the apps I have or I don't.
I don't believe a magic packet containing a melted down spectre is going to smash through my router and everything else and turn into skynet on my humble PC.
But you could imagine that an exploit might exist that would defeat the existing countermeasures, and that exploit would probably still be described as a "spectre exploit." So without that explicit context in the article, it's left to the reader to fret over :)
A quick web search shows that a lot of everyday users are interested in turning off mitigations on their machine “to test performance” - both on Linux and Windows 10.
In the wild exploits are almost certainly hitting vulnerable machines.
While there are ways to disable mitigation against many of the side-channel issues, this is not one of them. I believe this one is mitigated by the "sbb;and" sequence here:
This is not really in the wild or even the "wild" by any reasonable definition:
1. The exploit isn't by a real attacker. It comes from a pen-testing firm (white hats).
2. It was patched years ago, probably written years ago. Article doesn't say what happens when the kernel is newer than 2018 but presumably, it doesn't work? Spectre is still relevant for programs sandboxing code within themselves like browsers, but for normal patched systems, it doesn't seem to matter.
3. There are still no known cases of real attackers using Spectre, even though we have just seen an attack that Microsoft claimed may have had more than 1000 developers working on it (the Solar Winds supply chain attack). Spectre just doesn't seem like a very interesting way in for attackers compared to other types of vulnerability.
55 comments
[ 857 ms ] story [ 1916 ms ] threadHuh? It isn't to me. Can someone clarify on this?
Also:
- To what extend is this fixed by the mitigations which the kernel provides [0] for the Intel bugs? What do I have to add to my kernel command line?
- Where did he get the binary from? VirusTotal doesn't allow arbitrary people to download binaries which someone else uploaded, does it?
[0] https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/i...
Only the people that pay them.
Paranoid users of Ubuntu and Debian can install this package: https://packages.debian.org/bullseye/hardening-runtime . Then reboot.
It disables SMT, so independently of mitigations you won’t be vulnerable, but of course Hyper-Threading will be gone.
No SMT, no sharing of TLBs and L1s (I know that writing it this way is a gross oversimplification).
The in-kernel Spectre-v1 mitigations, like:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
are cheap and ubiquitous. You don't have to turn them on, and they're so cheap you can't even turn them off if you wanted.
Disclaimer: I work on Linux at Intel.
I'd favor the kernel command line path over using a package, any ideas on which are needed to fix this particular exploit kit at hand?
Supports Fedora, Arch, Debian, and openSUSE.
Has GNOME, Firefox, kernel cmdline, sysctl, firewalld, NetworkManager, and systemd unit hardening among other things.
Goes well with firejail (am a developer of): https://github.com/netblue30/firejail
One of which is you can see what files are "parents" of the sample. In this case, there are a bunch of zip files that contain this file, all named Immunity Canvas or similar. Canvas is a pentesting tool where they publish exploits, so I guess he's saying you can attribute it to Immunity.
And yes, VirusTotal lets you download the file if you pay. It's the foundation of the "threat-intelligence" industry :)
I remember Immunity advertising about an exploit for spectre they have, and it's easy to find: https://twitter.com/immunityinc/status/959155986098421760
Very likely that this is what the top poster found.
Indeed, so it is critical to never upload any binaries to them that you do not have full permission to redistribute. Nowadays they are very open about the sharing, but in the past this was kind of hidden.
Not sure if that's good, bad, or something else, though. :)
<arnold>good luck</arnold>
The Linux one at least is from the CANVAS product by Immunity Inc.
https://www.reddit.com/r/netsec/comments/lv5qal/spectre_expl...
/home/user/Downloads/Immunity Canvas 7.26/Immunity Canvas 7.26/exploits/local/unix/spectre_file_leak/bin
$sha256sum spectre
6461d0988c835e91eb534757a9fa3ab35afe010bec7d5406d4dfb30ea767a62c spectre
Can confirm.
The key part of this post is "In my lab, on a vulnerable Fedora" which means that the author is using an old, known-vulnerable version of Fedora on which to do their testing.
You don't have to do anything other than be running a reasonably modern version of the kernel that gets updates from -stable or from your distro.
BTW, this is a Spectre-v1-style exploit. These are EXTREMELY widespread across lots of processors with conditional branch speculation. It's (relatively) unrelated to the family of things like MDS or Spectre-v2 where microcode updates were issued.
Disclaimer: I work on Linux at Intel, occasionally on mitigation for this stuff.
You can test your (linux/bsd) system with the following:
https://github.com/speed47/spectre-meltdown-checker
A shell script to tell if your system is vulnerable against the several "speculative execution" CVEs that were made public since 2018.
> Amusingly, this method is still working on an up to date Linux
This may refer to the whole thing working, or just the KASLR bypass part.
I understand browsers already have some protection against them now. I don't see the point in slowing down the entire system, either I trust the apps I have or I don't.
I don't believe a magic packet containing a melted down spectre is going to smash through my router and everything else and turn into skynet on my humble PC.
Gee, I hope my machine has more spectre countermeasures enabled than your lab. This is a crucial omission, IMO.
This isn't some exciting leak.
It's correct at the bottom.
In the wild exploits are almost certainly hitting vulnerable machines.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
There is no way to enable or disable this particular mitigation. That's probably because it's an extremely cheap mitigation.
Disclaimer: I work on Linux at Intel.
https://github.com/google/safeside
1. The exploit isn't by a real attacker. It comes from a pen-testing firm (white hats).
2. It was patched years ago, probably written years ago. Article doesn't say what happens when the kernel is newer than 2018 but presumably, it doesn't work? Spectre is still relevant for programs sandboxing code within themselves like browsers, but for normal patched systems, it doesn't seem to matter.
3. There are still no known cases of real attackers using Spectre, even though we have just seen an attack that Microsoft claimed may have had more than 1000 developers working on it (the Solar Winds supply chain attack). Spectre just doesn't seem like a very interesting way in for attackers compared to other types of vulnerability.