Spectre exploits in the "wild" | Hacker News Reader

Spectre exploits in the "wild"

dustri.org

193 pointstodsacerdoti53 comments

> Attribution is trivial and left as an exercise to the reader.

Huh? 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...

> Where did he get the binary from? VirusTotal doesn't allow arbitrary people to download binaries which someone else uploaded, does it?

Only the people that pay them.

> What do I have to add to my kernel command line?

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.

That is besides processor's microcode mitigations right? Which can be applied using respective ucode packages and grub on Linux.

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.

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.

Thanks!

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?

hardening-runtime modifies the Linux kernel command line (as well as the sysctl config), hence the need to reboot.

I have a much more up-to-date and comprehensive GPL-3.0 package called 'brace' available here: https://github.com/divestedcg/brace

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

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 :)

Oh this is interesting context.

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.

nice, I hadn't spotted that. Not much to go on in the screenshot but what is there looks similar to the sample in the linked article

> 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.

Sounds like the RIAA or similar would still be all over them, if they become aware of the practice.

Not sure if that's good, bad, or something else, though. :)

They're free to download and execute any files... Just to be sure.

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.

Not very trivial to this reader without a VT account (:

A comment I found on reddit:

The Linux one at least is from the CANVAS product by Immunity Inc.

https://www.reddit.com/r/netsec/comments/lv5qal/spectre_expl...

$pwd

/home/user/Downloads/Immunity Canvas 7.26/Immunity Canvas 7.26/exploits/local/unix/spectre_file_leak/bin

$sha256sum spectre

6461d0988c835e91eb534757a9fa3ab35afe010bec7d5406d4dfb30ea767a62c spectre

Can confirm.

So... Is this working with mitigations on?

Too lazy to test it without grsec, but perhaps the helper script will give you an idea http://ix.io/2Rjn

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

That's just the copyright line. It was created in 2018

How much does canvas cost these days?

$0 :)

> - 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.

> - 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?

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.

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.

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.

That would be interesting to know more about. What's the point of paying the speed hit of spectre (and meltdown?) mitigations if they are ineffective?

Because the current mitigations were believed to attack the known affected code paths.

mitigations? you mean exploits?

s/attack/protect/

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.

The mitigations are breaking this particular exploit.

Google's SafeSide project published a number of practical demonstrations of leaking data through side-channels.

https://github.com/google/safeside

> In my lab, the exploit is successfully dumping /etc/shadow in a couple of minutes.

Gee, I hope my machine has more spectre countermeasures enabled than your lab. This is a crucial omission, IMO.

The whole point of the machine in my lab was to test the exploit…

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 cracked version of the CANVAS software package which includes this exploit is widely available to download on various hacking forums.

This isn't some exciting leak.

Nobody said otherwise.

The first sentence of the blog post implies otherwise.

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.

Through web browsers, or by running a specially crafted native executable?

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:

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.

Thanks!

In the face of these (and who knows what future) security issues, how are people still running on shared/cloud/vps servers?

As a side note, very nice glitch CSS.

Thanks ♥

Assuming you're the author, your Twitter link is broken.

Only at the top of the page.

It's correct at the bottom.

Fixed, thanks!

Reply on news.ycombinator.com