Microcode exploits thread - spectre, meltdown, the list goes on...

siva · 2018-05-07 13:24:20

I take a personal interest in computer/network security; it's integral to my technology philosophy. Back in January, during the initial microcode pandemonium, Schneier said, "more [exploits] are coming, and they'll be worse. 2018 will be the year of microprocessor vulnerabilities, and it's going to be a wild ride." I intend to follow this claim as 2018 continues, and then look back to evaluate steps taken by vendors, along with lessons learned (versus lessons that were documented and ignored by users and vendors alike), and new best practices for modern computing. I am particularly interested to discover the degree to which these exploits change the way we use technology, along with implications for the "Internet of Things" (also criticized in the Schneier article).

I thought it might be fruitful to dedicate a thread to microcode-based exploits, since the fundamental nature of them resides in modern processor design. Feel free to share knowledge, papers, thoughts, and the like.

Backstory: Many of these recent exploits have a long history of x86 infrastructure errors being ignored. Lots are documented under the KPTI/x86 section of this website entry. Two articles in particular are of interest: one from 1995 and another from 2015. The 2015 blog post, "x86 is a high-level language", notes a foreboding conclusion:

"...any attempt to get smooth, predictable execution out of the processor is very difficult. That means "side-channel" attacks on x86 leaking software crypto secrets may always be with us..."

This insight brings into question the entire framework of some Linux users: the use of older hardware. The warning, back in 1995, is clear: be wary of x86. Server admins, lend an ear.
Two decades of pretext lent itself to another 2015 article, also mentioned in the Cromwell link, titled "Intel x86 is considered harmful." Its introduction leaves a notable question:

This raises an interesting question: once we realize firmware, and (some) hardware, should be treated as untrusted, can we still build secure, trustworthy computer systems?

Three years later, admins everywhere were forced to give answer.

January: The two big players back in November 2017 - January 2018 were Meltdown and Spectre (variants 1 and 2). Some important findings were that Spectre remains unpatched and a threat to all modern processors, and the Meltdown patches (KPTI), avialable on amd64 kernels 4.14.14+ (and backported to older debian kernel versions), might not ever be available for i386. (This came straight from the patch developers).

Not long after, a website claimed the unveiling of two new speculative exploits: skyfall and solace. Neither exploit is documented, and both have been disregarded as hoaxes or trolls. Not to say they died without merit, however: the nonexistent attacks served as a warning to anyone who bandwagons news stories without researching their credibility -- perhaps a human form of speculative exploit.

February: Another set of exploits, MeltdownPrime and SpectrePrime, were also unveiled. One finding (from the abstract) is of particular note:

As a proof of concept, we implemented SpectrePrime as a C program and ran it on an Intel x86 processor. Averaged over 100 runs, we observed SpectrePrime to achieve the same average accuracy as Spectre on the same hardware—97.9% for Spectre and 99.95% for SpectrePrime.

In short, to support the findings above, and KPTI developer claims, x86 is quite vulnerable. I have been told that x86's design flaws is "old news." Nevertheless, here are modern examples. (In the paper, I did not see any tests on x86_64 hardware.)

May: This past Saturday, there were also reports of a Spectre-NG. The source of these findings roots back to the German website Heise.de. (I don't know much about the credibility of this source, as I am unfamiliar with it.) The author of the Tom's Hardware article on the topic reached out to Intel and received no response, presumably because Google Project Zero gives vendors a 90-day head start before releasing information. According to the Heise article, Linux developers are aware and working on the exploit. Intel patches may remain vulnerable until as late as August 2018.

Last edited by siva (2018-05-10 15:18:11)

emanym · 2018-05-07 16:06:01

Heise/C'T magazin are entirely credible -- the magazine has been around since
the '80s and (still) offers high quality technical information.

Update today here:

https://www.heise.de/security/meldung/S … 43790.html

short summary:

patches and dislosure delayed

8 different advisories

affects not just pc/servers, but tablets, phones & embedded as well

most dangerous problem won't be fixed before august...

hth

siva · 2018-05-07 16:36:11

Thank you. I updated the original posting.

rivenathos · 2018-05-10 04:30:27

Your posts and links have kept me reading and researching for hours. Thank you for sharing.

Panopticon · 2018-05-10 13:12:26

Very interesting thanks for posting this up. I own a nehelem intel laptop and they haven't patched this one yet afaik but ive read info that they plan to, so a chip that is over ten years old warrants patching!. Has there been any attacks/cracks reported due to these exploits yet?

siva · 2018-05-10 19:17:22

Panopticon wrote:

Has there been any attacks/cracks reported due to these exploits yet?

I'm not aware of any publicly-disclosed information about successful attacks. I do find it interesting that all of these CVE's are coming from Google, at a time when the company is investing in ridiculous processors.

If you're concerned about your own system, have a look at this, which I'm sure is in the ASCII repos: https://packages.debian.org/stretch-bac … wn-checker

figdev · 2018-05-25 02:13:37

i have it on authority (certainly not mine) that many things like this are only a problem if youre running non-free software.

you have a right to be sceptical of this claim-- i share your scepticism!

however, the person who tells me this is quite a bright fellow and associated with the free software foundation, and youve probably heard of his work. i am being "secretive" probably without the need-- i look forward to something public about this i can share. i wouldnt mention this if i didnt think it relevant and if i wasnt also waiting to hear more.

again, im not asking you to take my word for it.

but i do think its interesting if its even possibly true.

Last edited by figdev (2018-05-25 02:14:31)

siva · 2018-05-25 13:18:40

I'm sure that nonfree software will make it easier to pull off an exploit. Intel's ME is an example of nonfree software built into the bios. Also, this is the first time anyone has made that claim, so it might be helpful if that person were in this conversation or if a source were shared.

figdev · 2018-05-25 16:27:36

siva wrote:

Also, this is the first time anyone has made that claim, so it might be helpful if that person were in this conversation or if a source were shared.

i dont want to give the name of someone currently working on a paper that im not sure is announced publically. i have emailed you the name of the person so you can ask them yourself.

unless ive already said to much, im sure they will be happy to reply about this. they might even give you an update on the timeframe, which i would love to hear. i would say based on experience that a 3-6 day delay is a good range to wait for a reply; you might get one faster.

golinux · 2018-05-25 16:31:33

golinux is guessing RMS

figdev · 2018-05-25 16:40:57

golinux wrote:

golinux is guessing RMS

excellent guess and youre not far off, because rms would be the first to say something like that. rms was the original lead developer for the entire gnu operating system, though hurd was more of a design based on the mach kernel (afaik-- and so is the darwin kernel in macos) than an original work.

what im saying is that i dont think of rms as a guy mostly into lower-level matters like microcode, and the person im referring to is more likely to speak with authority on this.

im not deliberately being coy actually, im trying to talk about this without spoiling someones research paper.

though if siva sends that email out, maybe this will encourage them to announce it or get it finished more quickly. that would be a nice bonus. i feel like the whole idea is central enough to free software (i dont want to run non-free microcode updates if they arent needed) that its worth leaking what i did so far. if i am even "leaking" anything at all.

Last edited by figdev (2018-05-25 16:43:12)

siva · 2018-05-25 17:26:05

I didn't see your email. This network is acting flakey with my email client. I'll check it and follow-up later.

The officially official Devuan Forum!

#1 2018-05-07 13:24:20

Microcode exploits thread - spectre, meltdown, the list goes on...

#2 2018-05-07 16:06:01

Re: Microcode exploits thread - spectre, meltdown, the list goes on...

#3 2018-05-07 16:36:11

Re: Microcode exploits thread - spectre, meltdown, the list goes on...

#4 2018-05-10 04:30:27

Re: Microcode exploits thread - spectre, meltdown, the list goes on...

#5 2018-05-10 13:12:26

Re: Microcode exploits thread - spectre, meltdown, the list goes on...

#6 2018-05-10 19:17:22

Re: Microcode exploits thread - spectre, meltdown, the list goes on...

#7 2018-05-25 02:13:37

Re: Microcode exploits thread - spectre, meltdown, the list goes on...

#8 2018-05-25 13:18:40

Re: Microcode exploits thread - spectre, meltdown, the list goes on...

#9 2018-05-25 16:27:36

Re: Microcode exploits thread - spectre, meltdown, the list goes on...

#10 2018-05-25 16:31:33

Re: Microcode exploits thread - spectre, meltdown, the list goes on...

#11 2018-05-25 16:40:57

Re: Microcode exploits thread - spectre, meltdown, the list goes on...

#12 2018-05-25 17:26:05

Re: Microcode exploits thread - spectre, meltdown, the list goes on...

Board footer