Spectre and Meltdown Attacks

After a week or so of rumors, everyone is now reporting about the Spectre and Meltdown attacks against pretty much every modern processor out there.

These are side-channel attacks where one process can spy on other processes. They affect computers where an untrusted browser window can execute code, phones that have multiple apps running at the same time, and cloud computing networks that run lots of different processes at once. Fixing them either requires a patch that results in a major performance hit, or is impossible and requires a re-architecture of conditional execution in future CPU chips.

I’ll be writing something for publication over the next few days. This post is basically just a link repository.

EDITED TO ADD: Good technical explanation. And a Slashdot thread.

EDITED TO ADD (1/5): Another good technical description. And how the exploits work through browsers. A rundown of what vendors are doing. Nicholas Weaver on its effects on individual computers.

EDITED TO ADD (1/7): xkcd.

EDITED TO ADD (1/10): Another good technical description.

Tags: , , , ,

Posted on January 4, 2018 at 6:28 AM • 81 Comments

Comments

nwildner • January 4, 2018 7:15 AM

And here, is the official AMD statement on this issue:

https://www.amd.com/en/corporate/speculative-execution

Also, it’s time to grab a big bucket of popcorn and watch the internet burn, cause the blaming game started. Tom Lendacky, AMD dev at LKML:

“AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.”

https://lkml.org/lkml/2017/12/27/2

VinnyG • January 4, 2018 7:27 AM

Wow. Mega litigation to follow, as sure as shite draws flies in Summer… In possibly related news, I see that Intel CEO Brian Krzanich sold off 24MM USD of his Intel shares and options in late November 2016, after Intel was aware of this issue. Could that be coinky dink? Sure, I don’t know what the best ethical practice would be if Krzanich was already planning those transactions for legit reasons, then was told of the flaws. Proceed as planned, or (possibly) take it on the chin for appearances? I think I’d be more inclined toward the latter solution, possibly first informing the board that I expected to be suitably compensated somewhere down the road for my high-mindedness. Nevertheless, the timing of the events doesn’t leave Krzanich or Intel looking very good.
http://www.businessinsider.com/intel-ceo-krzanich-sold-shares-after-company-was-informed-of-chip-flaw-2018-1

@Salamn – thanks for the Sophos link – most complete digestible analysis I’ve found so far.

CallMeLateForSupper • January 4, 2018 8:09 AM

(A la “boxers or briefs?”) Are you Meltdown or Spectre?

I’m Spectre, thank-you-very-much. 😉

Alejandro • January 4, 2018 8:30 AM

From one of the write ups:

Re: Intel CPUs: “effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013).”

Also, ARM and AMD.

Oh my!

Alejandro • January 4, 2018 8:35 AM

Clarification:

“Spectre (works )on Intel, AMD, and ARM processors.”, but “unclear” as to Meltdown.

Ninja • January 4, 2018 9:07 AM

Seems Spectre is not as bad as Meltdown even if it doesn’t have an immediate patch. In any case I’m looking at the millions and millions of Android phones and IoT stuff that have been abandoned by everybody in the chain and will be attacked in the future and turned into further attack vectors.

Bumpy ride ahead, ladies and gentleman.

ShavedMyWhiskers • January 4, 2018 9:40 AM

As of last night one informed report noted that most hardware has yet to be tested but must be assumed to have a problem for now.
The problem is so big that no current patch tests to see which device it is on so in short order all systems will be hobbled and slowed with hardware aware selective patches. The differences for software are messy.

The first player to deliver silicon clear of this problem will sell a lot of parts.
At the high end clean silicon with the previous OS faster design could get a free 30% performance advantage so archive stable kernel code from a week ago.

CoLo services and cloud services that allow th3 user to run code inside a VM or container have a lot of exposure.
Anti virus companies will be hard put to help.

This is a big deal….
I was so shopping for an 8th gen upgrade, now on hold.
BitCoin miners may not care.
BitCoin exchanges will have a lot of work to stay secure.

The good news is the goal to slam the door shut before here are exploits is a prudent move.

I have made a stock market move buying options on popcorn and butter.

AJWM • January 4, 2018 11:15 AM

So I see in various forums (fora?) that some people are discounting Spectre since it only seems to leak in-process memory.

While that actually remains to be determined (I’ve seen one comment where it could leak between different userspace apps), that could still be a concern if it’s exploitable via javascript…at least in browsers where the script runs in the same process space where the browser is helpfully remembering usernames/passwords for other websites.

echo • January 4, 2018 11:24 AM

I note both the Meltdown and Spectre papers were in part funded by the European Union. The Spectre paper received additional funding from US sources.

“This work was supported in part by the European Research Council (ERC) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 681402)”

and

“Daniel Genkin was supported by NSF awards #1514261 and #1652259, financial assistance award 70NANB15H328 from the U.S. Department of Commerce, National Institute of Standards and Technology, the 2017-2018 Rothschild Postdoctoral Fellowship, and the Defense Advanced Research Project Agency (DARPA) under Contract #FA8650-16-C-7622.”

(Quotes edited for formatting.)

https://ec.europa.eu/programmes/horizon2020/en/what-horizon-2020

The EU Horizon scheme contains a security group:

https://ec.europa.eu/programmes/horizon2020/en/h2020-section/secure-societies-%E2%80%93-protecting-freedom-and-security-europe-and-its-citizens

“This Challenge is about undertaking the research and innovation activities needed to protect our citizens, society and economy as well as our infrastructures and services, our prosperity, political stability and wellbeing. “

echo • January 4, 2018 11:36 AM

@AJWM

Chrome 63 has an option which enables site isolation. This avoids issues such as shared Javascript running within the same process.

https://arstechnica.com/gadgets/2017/12/chrome-63-offers-even-more-protection-from-malicious-sites-using-even-more-memory/

Chrome 63 introduces a new mode called “Site Isolation.” In Site Isolation mode, this sharing is eliminated and the browser applies a much stricter policy to ensure that individual sites remain in separate processes. Even pages that were formerly “related” (and hence eligible for a shared process) will be separated, and a long browsing session within a tab that spans several different sites will get a new process each time a new domain is visited. The process sharing due to having a large number of processes is also disabled with this mode.

and

“Naturally, this greater use of multiple processes incurs a price; with this option enabled, Chrome’s already high memory usage can go up by another 10 to 20 percent. As such, it’s not enabled by default; instead, it’s intended for use by enterprise users that are particularly concerned about organizational security.”

Alyer Babtu • January 4, 2018 11:58 AM

As a comment on the LWN page linked at the bottom of this article points out, computer architecture books (e.g. Hennessy) stress that permission checks need to be made before speculative execution begins. That is the security environment of the process needs to be maintained consistently for the life of the process. Apparently IEEE’s insistent bias of old towards care (see machine arithmetic) was deprecated by manufacturers when it came to modern out of order processing.

How about IBM’s POWER line of chips ?

Insider • January 4, 2018 1:30 PM

Bruce: See section 8.0 from the Orange Book. It’s quick to read the one typewritten page at the link below. Summary: The DoD fully expects there to be information leakage and they want it limited to, ideally, 1bps. They consider 100bps to be “high” bandwidth leakage because that’s how fast terminals ran back in the 80’s. (It is arguable that they are only talking about leakage between cooperative processes that are not otherwise allowed to communicate and that they’re not talking about leakage between an attacker and victim, though I think that the concepts are the same.)

The main news is that this attack leaks 16Kbps which is far above 100bps. The fact that this category of attack exists at all and that the leakage is more than zero should not be news.

If this hole is plugged then attackers will just leverage another shared resource. Unless different contexts are completely isolated and have no shared resources (branch prediction, caches, on-chip interconnect bandwidth, memory bandwidth) at all, it is always possible for an attacker to glean some information about what’s happening.

https://csrc.nist.gov/csrc/media/publications/conference-paper/1998/10/08/proceedings-of-the-21st-nissc-1998/documents/early-cs-papers/dod85.pdf

Gerard van Vooren • January 4, 2018 1:46 PM

@ Who?

OpenBSD may have fixed these bugs years ago.

… and Linus Torvalds held his little pep talk.

(I like the OpenBSD approach more)

Dan H • January 4, 2018 1:57 PM

SPARC isn’t vulnerable and has always been my favorite platform, running Solaris. Although I am going to have to try Plan 9 and Inferno on my SPARC machine.

Bad Juju • January 4, 2018 2:16 PM

“Also, ARM and AMD.”

AMD is only the Opteron-A chips affected by Melt, everything else isn’t. AMD is basically fine.
Intel’s initial “explanations” were patent Intel dishonesty, downplaying and equivocating.

The patch will slow both AMD and Intel chips however, though AMD doesn’t need it.
So AMD will re-patch after that patch to whitelist AMD chips and undo the penalty.

What Intel doesn’t tell folks is that ALL their procs back to P3 days are affected by meltdown, and they’re only going back 5 years with the patch due to EOL. While that makes certain sense that means older boxes are going to be 100% insecure no matter what OS.

The performance penalty for Intel is insignificant compared to the damage they’ve once again managed to do to their reputation in the handling of this. And of course this is on top of the Intel ME debacle that is also ongoing.

“Yeah it’s everybody’s fault…” – No Intel, it’s not. You’re *holes.

Alyer Babtu • January 4, 2018 2:17 PM

Bring back Fortress Rochester and the iSeries. Frank Soltis, where are you when we need you ?

mrfox • January 4, 2018 2:27 PM

From the meltdown paper,

Serializing the permission
check and the register fetch can prevent Meltdown,
as the memory address is never fetched if the permission
check fails. However, this involves a significant overhead
to every memory fetch…

Can someone explain where the significant overhead comes from? Once the physical address for a memory read is known, whether or not the memory is protected should also be known? Surely checking that single bit against the CPU mode should be orders of magnitude faster than actually loading the contents into a register. What am I missing?

Doing the permission check after the value has already been shoved into a register sounds like asking for trouble.

Symphero • January 4, 2018 2:27 PM

One thing that I haven’t seen addressed is the relative priority of updating guest OSes versus host OSes. It may be that use of VT-x processing changes the nature of the game, but I’m just not sure. Are the virtualized instructions being executed by VMs equally exposed to these vulnerabilities as the host OS, and will it really make any difference to patch the guest OS if the host is still vulnerable?

bad juju • January 4, 2018 2:39 PM

“and will it really make any difference to patch the guest OS if the host is still vulnerable?”

The CPU has cubbies for each VM.

If OS is vulnerable the code running on it can reach into any cubby, and if the OS is not vulnerable it can only reach into its own. So patching the OS prevents that OS/VM from being trivially exploited to reach in to other VM memory, but doesn’t prevent other VM/OS from doing that without a microcode HW update. (I think?)

echo • January 4, 2018 3:17 PM

@Bad Juju

With regard to Intels liability expiration and due diligence, this commentary notes legal time limits of up to six years from date of supply, verification, and post-marketing duties. It also covers expertise and the scientific knowledge of the time. (I won’t copy all the interesting paragraphs as this is a security blog not a law blog plus my opinion is as good or ill as anyone elses.)

British Institute of International and Comparative Law
https://www.biicl.org/files/1123_overview_uk.pdf

gordo • January 4, 2018 3:30 PM

The Spectre of an Advertising Meltdown: What You Need to Know
By Nicholas Weaver Thursday, January 4, 2018

The information security world is focused on two new security vulnerabilities, “Spectre” and “Meltdown”, that represent vulnerabilities embedded in computer hardware. Lawfare readers should respond in two ways: keep their operating systems up to date and, critically, install an ad-blocker for your web browser. (Here are guides on how to do so in Chrome and Firefox.) In fact, a proper response to Spectre should involve ad-blocking on all government computers. Other than that, don’t worry.

https://lawfareblog.com/spectre-advertising-meltdown-what-you-need-know

Alejandro • January 4, 2018 3:34 PM

So then, are NEW Intel chips OK/fixed or will they be sold patched and thus slow?

How slow?

Shouldn’t there be a class action suit?

$$$$$$$$$$$$$$!

Grauhut • January 4, 2018 4:31 PM

@mrfox “Doing the permission check after the value has already been shoved into a register sounds like asking for trouble.”

If i got it right they asked for trouble by opportunistic speculative execution, checking permissions only if the speculative part is really used. If an attacker is able to push well formed evil code into the speculative execution stack, than this code can access memory areas it shouldnt be allowed to access and shovel data from there to regularily accessible addresses.

The name “Meltdown” hits that nail perfectly centered on the head. 🙂

(And fck, we still have a lot of sandy bridge stuff running…)

Deirdre • January 4, 2018 4:45 PM

@VinnyG

Sure, I don’t know what the best ethical practice would be if Krzanich was already planning those transactions for legit reasons, then was told of the flaws. Proceed as planned, or (possibly) take it on the chin for appearances?

Best practice is to set up the trades ahead of time:
“SEC Rule 10b5-1 also created for insiders an affirmative defense if the insider can demonstrate that the trades conducted on behalf of the insider were conducted as part of a pre-existing contract or written binding plan for trading in the future.”

The same paragraph states “the prohibition against insider trading does not require proof that an insider actually used material nonpublic information when conducting a trade; possession of such information alone is sufficient to violate the provision”. So we’re not talking about some optional “ethical practice” here. He could be in some trouble if he knew when setting up the trade, if the SEC is inclined to investigate.

holy_cow • January 4, 2018 5:14 PM

@VinnyG @Deidre:

Intel’s CEO planned the sale of those shares on October 30th. (The trades were executed on Nov 29).
Its now being reported that at least some variants of these flaws were reported to Intel about 5 months before that, so it sure looks like classic insider trading.
https://arstechnica.com/information-technology/2018/01/intel-ceos-sale-of-stock-just-before-security-bug-reveal-raises-questions/

Whether the SEC will actually investigate him, I couldn’t guess.

Clive Robinson • January 4, 2018 6:00 PM

@ Albert,

You are quoted (linked, but not named) here:

Obviously the author of the article “Geoff Dutton” either did not want the fame to go to my head, or for me to die in shame over the typo 😉

But if he only knew what I used to get upto on the Arpanet, his hair might turn as white as “the badger in my beard”. Let’s just say I was not a “‘good’ old boy” as the first two words need inverting for back then and said in a “Pythonesque voice” B-)

Either way our host @Bruce gets the real benifit as it will hopefully raise the number of interested readers. And seriously, at the end of the day getting the message out is more important than the messenger.

@ Bruce,

Boston is a long way for me to go to pick up my fee of “a drink” perhaps if you bump into “Geoff Dutton”[1] during your travels you can get him to buy you two drinks. One for you as our genial host who makes things possible and the other one for my payment, that you can give to any deserving cause you might find that needs a little encoragment call it “Clive’s TEA grant” or some such and let them wonder what the TEA stands for 😉 I’m sure the readers here could come up with many suggestions, some might even be publishable 😀

[1] https://www.counterpunch.org/author/geodut5674/

echo • January 4, 2018 7:36 PM

Google have developed a binary modification technique to mitigate one of the major threats. Reading through material on the threats and considering OS and perhaps third party solutions which the anti-virus companies have the skills to provide I wondered if something of this kind was possible.

Google Says CPU Patches Cause ‘Negligible Impact On Performance’ With New ‘Retpoline’ Technique
https://tech.slashdot.org/story/18/01/04/2230207/google-says-cpu-patches-cause-negligible-impact-on-performance-with-new-retpoline-technique
https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html
https://www.theverge.com/2018/1/4/16851132/meltdown-spectre-google-cpu-patch-performance-slowdown
https://support.google.com/faqs/answer/7625886

Zorg • January 4, 2018 7:50 PM

@Grauhut @mrfox @nwildner :
Interestingly, although there is no exploit yet, it seems AMD and ARM are not completely out of the woods regarding Meltdown. Specifically, the statement from AMD’s Tom Lendacky: “The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault” may not be entirely accurate. To wit, this excerpt from the Meltdown paper (page 13, 6.4): “However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed”.
I suspect that in AMD and ARM, the speculative data fetch actually occurs and triggers an L1D cache load, but the illegal access is detected early enough thereafter to abort subsequent speculative execution, thus disabling the “Step 2: Transmitting the secret” part of the exploit. A different transmission mechanism that is workable on these processors may yet be found…

Clive Robinson • January 4, 2018 8:33 PM

@ Gerard van Vooren,

… and Linus Torvalds held his little pep talk.

The fact that Linus Torvalds is talking in a polite measured way not his more normal “Annoyed Fireworks” should be ringing very large bells very rapidly in peoples ears.

Likewise,

@ Who?,

OpenBSD may have fixed these bugs

Yes those erata Theo de Raadt talks about have been around for a long time and like as not will be around in other ways for a very long time to come. But it’s not a case of “may have fixed” but more “may have got lucky this time”. Read Theo’s words on what he thinks the future holds, he fully well knows that at some point he and OpenBSD are going to fall afoul of those erata, it’s only a question of “when” not “if”.

@ ALL,

Over on this weeks squid page I posted a couple of comments on the issue.

Firstly I mentioned this paper,

https://arxiv.org/pdf/1710.00551

And said of it,

    And it opens a whole world of nightmares for those that know how to look at things even slightly hinky…

This event is but one of those many nightmares, which will nodoubt “Come to a place near you real soon now”.

I then mentioned again my now getting long in the tooth but ever more relavant “Efficiency -v- Security” saw.

All of this and the other “nightmares to come” are because of the way we “sleepwalked” into the situation. The design engineers will in all probability have given due warning over the years, about complexity but would have been ignored by Marketing and Managment who “Want bread today, not Ambrosia tommorow”. Likewise there have been one or two largely ignored papers on how the MMU and other internals in IAx86 make a “Turing Compleat” state machine, and talked about how it makes what appears a “virtual computer” that due to where it is basically comes in at ring -X as it has full unfeatered access to the entirety of RAM…

The fact that so very few ever look below the Instruction Set Architecture (ISA) level in the computing stack, let alone work there has enabled this very very significant and real “Technical Debt” to build up into a tsunami of pain, we are just starting to feel the pre-shocks of.

Imoortabtly the fact that Intel led the dance and others followed their lead tells you exactly where the problem originates…

But at the end of the day “Efficiency” is a multidimensional space, and “Security” another. Neither space maps neatly to the other and the relationship is thus quite complex.

The practical result is that if you increase “Efficiency” in one dimension something has to give in another dimension or space. Think of it if you will like the “Time-Memory trade off” we see in Crypto, but a lot lot more complex and distinctly unfavourable. Worse unless you manage all of the “Efficiency” space dimensions you will open up “Security” space issues in more than one dimension.

The easiest to see is when you increase “throuput” you also open up “bandwidth” which inturn opens up “transparancy” thus you create bigger faster side channels as a consequence. If you then do not add the correct counter measures those side channels will hemorrhage information that can leak secrets even through the best of firewalls and guards… Thus drastically reduce or entirely obviate any “security” that’s been designed into a system.

In hardware, side channels exist in many basic forms, in general those to do with capacitive and inductive coupling, shared current sources etc you do not get to even know of if you always work above the ISA level in the computing stack. You do however get to see those in the time, frequency and even wavelet dimensions but without the proper tools and knowledge they will pass you by sight unseen.

One reason for this “blindness” is the US IC and SigInt entities and their views on “offensive capabilities”. We think it’s a modern affliction with “Cyber-weapons” being the only aberrant domain. It’s actually atleast as old as WWI so a century or so that the US has blocked defensive capability from those who realy need it (ie their citizens and the economy they make).

One such area is EmSec and it’s sub field of TEMPEST. The USG tried doing the Roman Catholic Holy See thing of locking up knowledge and knowledge generators. In the Holy See’s case the most well known is to do with astronomy and it’s conflict with accepted doctrine of mans place in the universe. But there were many others which delayed the likes of medicine and science by upto three hundred years, to the great cost of mankind. Thus gistory both old and new show use that witholding information always in the long term causes excessive harm to your own and will always out balance any short term gains there might be.

What the USG did was block information on “Compromising Emissions” for years, likewise made patents secret and prevented TEMPEST technology being sold outside of “trusted organisations” by making possession effectively illegal.

As EmSec is entirely about the basic laws of physics, it was not to supprising that alowing “Compromising Emissions” fairly soon started to be a real problem for mankind in general. Eventually the drive from Europe over “EMC” made the USG position pointless but nether the less asspects of it are still there as “Classified knowledge / methods / materials” the possession of which can make your life somewhat awkward to say the least (yet another reason to “not go there”).

Thus it is no great supprise that Intel Engineers and more importantly Marketing and Managment apparently “don’t get it” when it comes to such security subjects…

As an engineer that has “gone through the rituals” involved with such subjects back in the 1980’s it actually pains me to have to be cautious about USG IC SigInt agency idiocy when it comes to what they consider an “Offensive Capability Advantage”. Because it realy means the rest of us have to pay over and over and over again and again… for what is rarely a real advantage (consider SigInt / ElInt -v- HumInt pros and cons).

The likes of the GCHQ, NSA etc know a great deal about “Efficiency -v- Security” and the design rules like “clock the inputs, clock the outputs” and what they realy mean / do (in this case kills jitter transparancy side channels covert or otherwise). Which would have prevented some of these problems before they ever got to the drawing board, let alone left it.

So it will be interesting to see how Intel play this one out, the potential liability could kill them entirely. But then that would have dire consequences for not just the IC / SigInt entities… Thus the question of “Are they to big to fail?”… If the stratigic answer is “yes” then expect some USG fudgery to happen as it did for “The banking Crisis”.

Currently the only acceptable security solution for mear mortals is to develop the “Two Machine Mentality”. One OnLine machine using a CD/DVD distro to do non confidential online activities, the other not just OffLine but “Energy Gapped” to do confidential activities and ordinary work on (remember what you see as ordinary work, others see as high value intel) .

Because, not meaning to be nasty, but what we see currently “Is but one of many nightmares to come” and any “above the ISA level” in the computing stack solutions are almost guaranteed to be worthless one way or another. It’s what Linus Torvalds and Theo de Raadt are only too aware off, and I’ve been warning of on this blog for a very long time…

Tony H. • January 4, 2018 8:33 PM

@mrfox

From the meltdown paper,

Serializing the permission check and the register fetch can prevent Meltdown, as the memory address is never fetched if the permission check fails. However, this involves a significant overhead to every memory fetch…

Can someone explain where the significant overhead comes from? Once the physical address for a memory read is known, whether or not the memory is protected should also be known? Surely checking that single bit against the CPU mode should be orders of magnitude faster than actually loading the contents into a register. What am I missing?

Doing the permission check *after* the value has already been shoved into a register sounds like asking for trouble.

Seems to me there are two versions of this problem (“Meltdown” or “Variant 1”) being described. The one in the Google Project Zero paper describes a software permission check; that in the Meltdown paper describes a hardware permission check.

The Project Zero version is easy to understand as having significant overhead to fix, but strangely it’s the Meltdown one that contains the statement you quote. The Project Zero version seems to be talking about kernel code making a legitimate (to it) memory access, and the flaw is that that access may proceed speculatively (causing cache side-effects) while the processor performs the range check to see if the user has access. This would surely be exploitable on just about any CPU with branch prediction and speculative execution, and the C example does not require any knowledge of Intel architecture to understand.

The Meltdown version also has such a software check but they don’t mention it, but rather some not well specified hardware protection check, which evidently is done only after (or at least late in the game wrt) fetching and cacheing. I think this is an Intel-specific thing that they expect their readers to understand.

Of course both of these require that there be a method of exfiltrating the information to user space using some way of testing the cached state of the speculatively fetched data. That too may depend on the CPU architecture and microarchitecture.

Thoth • January 4, 2018 11:55 PM

@Clive Robinson

I think we have talked a lot about these topics on compromising the CPU here and it took so long for a bunch of researchers to publish a formal paper.

It’s no secret that CPU designs can be flawed.

On top of that, good old friend, Paul Kocher is one of the paper authors for Spectre.

We have discussed C-v-P, data diodes with examples from @Markus Ottela and also the energy and air gapping methods you have so frequently mentioned as mitigation of these vulnerabilities.

One thing they might have missed is memory protection and segregation techniques. It would be nice if they could show that even with use of delegating memory regions to different processes or apps on the hardware, they could still bypass it.

tyr • January 5, 2018 2:32 AM

@Clive

I was always suspicious of the mad rush
of Apple to Intel CPUs and now have a
good reason. The problem with monoculture
(i.e. the one true way things are done)
has now raised its ugly head. So you
either have to forgo all that snazzy
acceleration code or bend over for the
exploitation.

If Intel CEO doesn’t get tagged for the
dump of 39 million in stock and they pass
it off as coincidence you will know USA
isn’t going to be around much longer in
its present form.

I keep thinking a lot of money could be
made from a Kickstarter IPO of a guillotine
factory as the idea who has come around
again.

Marvels never cease these days.

Cassandra • January 5, 2018 3:28 AM

Two drive-by items:

1) Interestingly, CERT changed their published Vulnerability Note VU#584653

Old version: https://web.archive.org/web/20180104032628/https://www.kb.cert.org/vuls/id/584653

Solution
Replace CPU hardware
The underlying vulnerability is primarily caused by CPU architecture design choices. Fully removing the vulnerability requires replacing vulnerable CPU hardware.
Apply updates
Operating system updates mitigate the underlying hardware vulnerability.

Newer version: https://web.archive.org/web/20180105083106/https://www.kb.cert.org/vuls/id/584653

Solution
Apply updates
Operating system and some application updates mitigate these attacks.

Some people are speculating that CERT came under pressure to do this.

2) The vulnerability mechanism was investigated earlier by someone who came very close to uncovering it:

https://web.archive.org/web/20170729101621/https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/

Pandoras box

While I did set out to read kernel mode without privileges and that produced a negative result, I do feel like I opened a Pandora’s box. The thing is there was two positive results in my tests. The first is that Intel’s implementation of Tomasulo’s algorithm is not side channel safe. Consequently we have access to results of speculative execution despite the results never being committed. Secondly, my results demonstrate that speculative execution does indeed continue despite violations of the isolation between kernel mode and user mode.

This is truly bad news for the security. First it gives microarchitecture side channel attacks additional leverage – we can deduct not only information from is actually executed but also from what is speculatively executed. It also seems likely that we can influence what is speculative executed and what is not through influencing caches like the BTB see Dmitry Evtyushkin and Dmitry Ponomarev [5] for instance.It thus add another possibility to increase the expressiveness of microarchitecture side channel attacks and thus potentially allow an attacker even more leverage through the CPU. This of cause makes writing constant time code even more complex and thus it is definitely bad news.

Also it draws into doubt mitigations that rely on retirement of instructions. I cannot say I know how far that stretches, but my immediate guess would be that vmexit’s is handled on instruction retirement. Further we see that speculative execution does not consistently abide by isolation mechanism, thus it’s a haunting question what we can actually do with speculative execution.

Somebody reading Anders Fogh’s website could well have extended his work and used the results.

Grauhut • January 5, 2018 6:17 AM

Why do i have the feel these exploits could be remote exploitable by abusing wireless device drivers… 😉

iwl100-firmware     Firmware for Intel(R) Wireless WiFi Link 100 Series Adapters    Neue Version 39.31.5.1-57.el7   Updates
iwl1000-firmware    Firmware for Intel® PRO/Wireless 1000 B/G/N network adaptors    Neue Version 39.31.5.1-57.el7   Updates
iwl105-firmware     Firmware for Intel(R) Centrino Wireless-N 105 Series Adapters   Neue Version 18.168.6.1-57.el7  Updates
iwl135-firmware     Firmware for Intel(R) Centrino Wireless-N 135 Series Adapters   Neue Version 18.168.6.1-57.el7  Updates
iwl2000-firmware    Firmware for Intel(R) Centrino Wireless-N 2000 Series Adapters  Neue Version 18.168.6.1-57.el7  Updates
iwl2030-firmware    Firmware for Intel(R) Centrino Wireless-N 2030 Series Adapters  Neue Version 18.168.6.1-57.el7  Updates
iwl3160-firmware    Firmware for Intel(R) Dual Band Wireless-AC 3160 Series Adapters    Neue Version 22.0.7.0-57.el7    Updates
iwl3945-firmware    Firmware for Intel® PRO/Wireless 3945 A/B/G network adaptors    Neue Version 15.32.2.9-57.el7   Updates
iwl4965-firmware    Firmware for Intel® PRO/Wireless 4965 A/G/N network adaptors    Neue Version 228.61.2.24-57.el7     Updates
iwl5000-firmware    Firmware for Intel® PRO/Wireless 5000 A/G/N network adaptors    Neue Version 8.83.5.1_1-57.el7  Updates
iwl5150-firmware    Firmware for Intel® PRO/Wireless 5150 A/G/N network adaptors    Neue Version 8.24.2.2-57.el7    Updates
iwl6000-firmware    Firmware for Intel(R) Wireless WiFi Link 6000 AGN Adapter   Neue Version 9.221.4.1-57.el7   Updates
iwl6000g2a-firmware     Firmware for Intel(R) Wireless WiFi Link 6005 Series Adapters   Neue Version 17.168.5.3-57.el7  Updates
iwl6000g2b-firmware     Firmware for Intel(R) Wireless WiFi Link 6030 Series Adapters   Neue Version 17.168.5.2-57.el7  Updates
iwl6050-firmware    Firmware for Intel(R) Wireless WiFi Link 6050 Series Adapters   Neue Version 41.28.5.1-57.el7   Updates
iwl7260-firmware    Firmware for Intel(R) Dual Band Wireless-AC 7260 Series Adapters    Neue Version 22.0.7.0-57.el7    Updates
iwl7265-firmware    Firmware for Intel(R) Dual Band Wireless-AC 7265 Series Adapters    Neue Version 22.0.7.0-57.el7    Updates
kernel  The Linux kernel    Neue Version 3.10.0-693.11.6.el7    Updates
kernel-headers  Header files for the Linux kernel for use by glibc  Neue Version 3.10.0-693.11.6.el7    Updates
kernel-tools    Assortment of tools for the Linux kernel    Neue Version 3.10.0-693.11.6.el7    Updates
kernel-tools-libs   Libraries for the kernels-tools     Neue Version 3.10.0-693.11.6.el7    Updates
linux-firmware  Firmware files used by the Linux kernel     Neue Version 20170606-57.gitc990aae.el7     Updates
microcode_ctl   Tool to transform and deploy CPU microcode update for x86.  Neue Version 2.1-22.2.el7   Updates

JG4 • January 5, 2018 6:21 AM

@tyr – the guilliotines could be miniaturized and electronically controlled (IoT) to be worn around the necks of the politicians. the brilliant movie, Total Recall, showed a crude prototype controlled by an electronic fence. it’s another example of projected intent. the IoT exposure of the politicians might wake them up to the need for some credible standards. the guilliotines could be subject to a continuous vote/voter approval rating system, and include live webcams for transparency.

@Clive – Thanks for the helpful elucidation of tradespaces. reality is another tradespace. btw, Tiger Woods is another example of a billionaire who created a market for himself. I think that I’m on the record saying that politicians are arbitraging fundamental economic tradeoffs between present and future. we could hope to live long enough to piss on their graves, but that is limited satisfaction for living in penury or for the premature collapse of civilization.

another nice data visualization

http://www.visualcapitalist.com/hackers-hack-motives-behind-cyberattacks/

Thanks for the quip:

“Free market capitalism isn’t intrinsically bad; it happens to be not-free, not-market, and not capitalism”

one of the articles that I linked yesterday had a useful list of working assumptions. it wouldn’t be difficult to come up with a list of requirements for a free market to actually exist (it’s not clear that any ever have) and I’m certain that someone smarter than I am already has done it. symmetry of information, liquidity, participants consistently acting in their own self-interest would be a good start. the list could be compared to the current paradigm to see if there are any unicorns in the forest or ever have been.

some useful coverage of the usual topics

https://www.nakedcapitalism.com/2018/01/links-1518.html

echo • January 5, 2018 8:09 AM

The Register discusses some of the mitigations underway and issues surrounding design and development. It also appears a whitewash/scapegoating may also be underway by lawyers representing Intel investors.

https://www.theregister.co.uk/2018/01/05/spectre_flaws_explained/

INTC INVESTOR ALERT: Law Offices of Howard G. Smith Commences Investigation on Behalf of Intel Corporation Investors
https://www.businesswire.com/news/home/20180103006309/en/INTC-INVESTOR-ALERT-Law-Offices-Howard-G

Clive Robinson • January 5, 2018 9:09 AM

@ echo,

INTC INVESTOR ALERT: Law Offices of Howard G. Smith Commences Investigation on Behalf of Intel Corporation Investors

Agh, the “chilling of free speech” starts with a lawyers letter…

And people wonder why I don’t let my personal details be easily found…

Now what was it somebody was saying about neck worn guillotines for politicos… Maybe the should be trialed on lobbyist lawyers and their ilk first, it might be popular as a spectator sport… Just joking folks I would not wish to be falsely accused of not having brotherly love or what ever nice PC turn of phrase you want to give it 😉

echo • January 5, 2018 9:34 AM

@clive @Cassandra

I felt your previous comment on institutional failures and Cassandras mentioning the CERT advisory had been “fixed” is a all too true and very sad approach to many avoidable problems. (By way of example abuses in healthcare and immigration and building quality have all been in the UK news recently.) Lawyers too as you say can be a very threatening response. The thing is other more positive and agreeable actions are possible but is the political and personal will there?

I lack the in-depth experience and expertise to comment too deeply on the technical issues and have other fish to fry so tend to stay out of the more involved discussions.

Speaking purely as an end user who only just invested in new to me laptops and upgrades I hope any fixes reach my now older than five years hardware. I always wanted a Thinkpad since I saw the classic butterfly keyboard model so bought one of the last classic models. (Actually, I bought two. One for desktop use and partly due to anxiety attacks another for backup/portable/other reasons.) I can if I have to buy something within Intels arbitrary (and potentially unlawful) time limit but others are not so fortunate. How comfortable does a multi-millionaire CEO feel about writing off the security of the unemployed and disabled and pensioners and those in less well developed economies?

https://www.cnet.com/news/meltdown-spectre-intel-ceo-no-recall-chip-processor/

But Intel CEO Brian Krzanich said the new problems are much more easily fixed — and indeed are already well on their way to being fixed, at least in the case of Intel-powered PCs and servers. Intel said Thursday that 90 percent of computers released in the last 5 years will have fixes available by the end of next week.

Grauhut • January 5, 2018 9:58 AM

@Clive: I think you misinterpreted poor Howard G. Smith. This seems not to be about free speech, but about missed official warnings and losses.

Smells more like a case against Intel by Intel Investors because of missed stock exchange related information obligations.

They want their money back! 🙂

Who? • January 5, 2018 1:46 PM

@ Gerard van Vooren

Please, consider that I am far from being an expert on this vulnerability. I know what happened a decade ago in OpenBSD; I would expect most of these processor design flaws been fixed right now (to the extent software fixes can workaround these processor bugs).

As I am learning more about these attacks, it is more clear to me that a microcode update is required as a full workaround. It would be nice if Intel releases fixes for as many processors as possible and OEMs provide updates. Obviously fixing computers manufactured in the last five years is not enough. Most of my computers were manufactured between 1997 and 2006, these are my workhorses yet. Firmware has become a nightmare in the last ten years, so (as most people on this forum) my choice is not trusting on recent hardware.

Who? • January 5, 2018 2:10 PM

@ Clive Robinson

Yes those erata Theo de Raadt talks about have been around for a long time and like as not will be around in other ways for a very long time to come. But it’s not a case of “may have fixed” but more “may have got lucky this time”. Read Theo’s words on what he thinks the future holds, he fully well knows that at some point he and OpenBSD are going to fall afoul of those erata, it’s only a question of “when” not “if”.

I fully agree with you; OpenBSD can do a lot to improve security, but hardware is at a different level. No one can find workarounds for some of these bugs at just the operating system level. We need access to firmware and, on this case, processor microcode too (expecting future discovered bugs can be fixed implementing workarounds at this level, even microcode has limits on what can it do!). Computers have become too difficult to fully understand and, instead of improving and fixing our over-engineered technology we are finding ways to make it more difficult to audit.

Sure, at some point we will discover a new Meltdown or Spectre bug but this one will be unfixable. It nearly happens to Spectre, it has been considered unfixable by Google, but it seems Intel has a way to immunize processors against it too. We will see what happens on the next weeks.

My wish is that these attacks will show we need to step back. We have much better technology right now than it was twenty years ago. We can build machines that are faster, cheaper and less power-hungry right now. So, why not turning things simple and auditable again?

Jim • January 5, 2018 3:25 PM

the lawyer above is just a plaintiff attorney who is attempting to solicit potential intel equity shareholders to join his prospective plaintiff class action class.

the realties of multidistrict class actions in US federal district courts are that this attorney will NEVER receive his desired certification from a US district court judge unless he has previously had such a suit certified previously.

Jim • January 5, 2018 3:46 PM

the lawyer above is just a plaintiff attorney who is attempting to solicit potential intel equity shareholders to join his prospective plaintiff class action class.

the realities of multidistrict class actions in US federal district courts are that this attorney will NEVER receive his desired certification from a US district court judge unless he has previously had such a suit certified previously.

Clive Robinson • January 5, 2018 6:30 PM

@ echo,

Speaking purely as an end user who only just invested in new to me laptops and upgrades I hope any fixes reach my now older than five years hardware

If your “new to you” hardware works it will continue to work as it did befor (unless people muck up the software patches, which is Linus’s most obvious concern).

It is still as secure as it was. All that has happened is a an existing vulnerability has now become a –newish– attack vector.

So if you implement some other measure outside of your hardware to block the use of the vulnerability things will not realy have changed.

So if you do not connect it to a network where others can get in –or you get out– effectively “OffLine mode” your usage will be unaffected by this.

The problem arises when you want to go into the “OnLine Mode” where others can get at your hardware –or you can get out to dangerous places– you then need some form of protection.

It’s why I’ve talked of the “two computer mode/mentality” do your confidential and private activities on one machine that NEVER goes “OnLine” and one that is striped back such that the vulnerability is in effect irrelevant (think HD less with CD/DVD based OS distro). The two computers are then “gapped”. The problem is that on some occasions you need to “cross the gap”, as with busy roads you can do this in a safe way or not, as with crossing a road safely, it takes more effort and care to be safe when crossing the gap.

At some point somebody is going to get the bright idea of using a CPU that is X generations behind that does bot have these “Superscaler Vulnerabilities” and use it as the core of a secure routing device often called a “Guard” –sluice or pump– that is in effect a specialised firewall and data diode. This will have ways of stopping the vulnerabilities becoming attack vectors on your internal “Guarded” machines.

However there is a problem, and I hate to be the bearer of “bad news” but these two attack vectors are in effect “instances” of a very much larger “class” of Superscaler architecture vulnerabilities. The reason, the Superscaler architecture was only designed with “efficiency” in mind, as a result it has opened up a whole series of side channels, each of which have a month or so of potential nightmares in them…

So there is almost certainly “more to come” unless Intel calls in Hercules to clean out the Aegian Stables sized mess that they have created by neglecting things they should have kept their eye on.

One problem is the “Swiss Watchmaker’s adage”, which is “Take it appart reverse the order of the parts and see if it works better”, you have to be very very carefull about what you mean as better…

Reading between the lines Intel found that when they reversed the recommended order of “check then fetch” from memory as “fetch then only check if needed” was in most cases “better”… Because their definition of “better” was narrowly focussed on average throughput increases, and ignored the wider view that would have included “not making new side channels”. Which as I’ve noted earlier there is a small and unlikely possability they would not have been aware of…

It’s upto you to decide if you want to use the two gapped computers method or not, I’ve been using “fully gapped” since the early 1990’s and have upgraded from “air-gapped” to “energy-gapped” in various steps as my “thinking hinky” skills increased. For instance I described the “How” of BadBIOS from knowledge I had aquired practically making a simillar system in the 1980’s as a cheap reliable way for small “pocket organiser” computers to talk to earky PCs and thus had long before taken steps to prevent both sound and light gap crossing. For other reasons –lab kit usage– I had switched to passive cooling and effective RF and sound insulation. So I know the difference between “Designing out” and “Getting lucky”, thus how to learn from it.

Thus what I want is others to also learn from my mistakes, research, developments and luck. But I know the people who realy need it are not going to be able to implement it. They are those for whom the purchase of just one computer for a childs education means the parents go hungry. It’s also why I am deeply suspicious of the time of the anouncment, just after the busiest PC/laptop/pad sales period of the year… After all think about what would have happened to Black Friday and later sales if this news had come out a week before Black Friday?

Clive Robinson • January 5, 2018 7:05 PM

@ Grauhut,

I may have misjudged the reason for what the lawyer is trying to do.

But… Whilst the Intel investors and stockholders feel agrived and want their money back, there are others that have been deceived proportionately more…

What about all the Mom’s and Pop’s that have saved and scrimped and in some cases gone without, so they can buy their child(ren) a computer to do homework and get a better education and the posability of a future?

They to have in effect been defrauded, because this problem was known not just to Intel but others well before Thanksgiving and Black Friday. And those people very deliberatly sat on the information untill after the busiest consumer computer shopping period of the year. Those Mom’s and Pop’s through no fault of their own have bought “lemons” and the reality is there is no “lemonaid” option for them, they won’t even see ten cents on the dollar for what they have spent.

Unlike others who can with a little extra spending mitigate the risk, those Mom-n-Pops are saddled with the equivalent of a boat anchor, possibly on credit…

So from my point of view many of those investors and stock holders should move down the line some…

It also again brings into question what the word “Responsible” realy means in “Responsible disclosure”?..

I can make a prediction about “compensation” to consumers though. People often get tallked into buying “bundles”. That is PC + screen + keyboard + mouse + printer + software + Games etc. We know the bundler often bundles “dead stock” to get it of the shelves etc. When it comes to a consumer “getting their money back” what will happen is that the bundler will only refund on the PC… Worse to reduce this they will say that the total price spent by the consumer minus every bundled item at full or even inflated value will be the best they can do. Thus the customer will not even get the price of the CPU chip back. Such is the way such markets can work…

Clive Robinson • January 5, 2018 7:22 PM

@ Who?, ALL,

As I am learning more about these attacks, it is more clear to me that a microcode update is required as a full workaround.

I would not be too sure that a microcode update will fully fix thr problem.

You have to remember that “microcode is slow compared to hard wired”, and that they were looking for every fraction of a nS they could get… Thus there is a probavility that some of the vulnerability is “hard wired”…

It’s not something you or I can know unless Intel tell us truthfully. Any microcode fix they make might just be a “rearangement of the deckchairs on the Titanic to make a faster way to get to the side of the ship to jump off, rather than magic life rafts out of thin air”… I know that sounds grim but there is only so much that microcode can do with what’s already hardwired, it cannot magic new control lines or gates into existence…

Clive Robinson • January 5, 2018 7:59 PM

@ Who?

I should have read you next comment… I see you understand there is limits to microcode.

But moving on to try to catch up 😉

Computers have become too difficult to fully understand and, instead of improving and fixing our over-engineered technology we are finding ways to make it more difficult to audit.

Whilst that is the apparent effect the cause is rather more interesting…

Back in the days of 8bit micros memory fetches from external static RAM could actually be faster than from the internal registers… Hence a clued up assembler programmer could do the equivalent of “Vector Array Computing” way faster than you would think, thus only used the INC or DEC on internal registers with branching on flags.

Times changed and internal registers started to get faster thus more registers appeared in the early 16bit chips. Then adder logic got faster so it was possible to do a “poor mans virtual memory” by introducing segment registers.

Due to slow internal instruction decode via microcode ROM the Reduced Instruction Set Computer (RISC) could still benifit from the speed of external SRAM. However that changed and Complex Instruction Set Computers (CISC) gained an advantage. Likewise Harvard machines were faster than Von Neuman, so the hidden internals got the Harvard treatment which is why you have two L1 caches, one for data one for instructions. You then get the busses joined again to fake a Von Neuman architecture which is why you only have one L2 cache for data and instructions.

Each new process untill a decade or so ago spawned a new CPU, Linus for instance worked on the ill fated Trasmeta CPU (IIRC).

The problem was that Intel had to be “backwards compatable” not just at the Instruction Set Architecture (ISA) layer in the computer stack, it also had to remain compatible at much lower levels like the interupt and memory control, which is well down the stack at or even below the memory level.

Thus Intel picked up baggage faster than a “Footballers Wife with a no limit platinum credit card in the pre-sale exclusive sale”.

To realise what interesting times are ahead of Intel and have a think back how Microsoft went from 16bit to 32bit Windows withva “Thunk”, that’s going to look way way easy in comparison. Intel had an opportunity when they went 64bit but chose not to, so have got themselves into an evolutionary cul de sac…

You can see why some want to buy futures in the butter and popcorn markets 😉

Joseph • January 5, 2018 9:29 PM

Clive Robinson said,

They are those for whom the purchase of just one computer for a childs education means the parents go hungry.

You can see why some want to buy futures in the butter and popcorn markets 😉

There’s a secondary market for computer products too, you know?

The child will get his computer assisted education whether Meltdown/Spectre exists or not. Furthermore, his parents should be more wary of the latest mass indoctrinations that are so commonly and blatantly exhibited by our and their knowledge outlets. Some may be as deeply rooted as Meltdown.

Joe • January 5, 2018 9:55 PM

@Bad Juju wrote, “What Intel doesn’t tell folks is that ALL their procs back to P3 days are affected by meltdown, and they’re only going back 5 years with the patch due to EOL. While that makes certain sense that means older boxes are going to be 100% insecure no matter what OS.”

That made my stomach churn as I made it a habit to run 5 year older gears. But only because there havent been any new funds to replace them. I guess I really should move my pr0n collection to an encrypted external drive.

Halil ÖZALP • January 6, 2018 7:46 AM

Despite the criticality of this attack; the baseline difficulty to construct an attack is reasonably high due to the degree of tailoring required. This complexity is greatly further increased if either of these conditions is not satisfied. While this is beneficial in that we do not need to (strongly) worry for most binaries, there are several classes of software for which these preconditions are more readily satisfied. The primary example being the host operating system: here, even if the exact operating system version is not known, the there will always exist large commonalities which may be reasonably targeted (e.g. Between Linux or Windows versions). Further, in this example, application’s own address space represents a shared channel with the hosting operating system that may be used to clear the second hurdle. (It should be noted that hardware protection techniques such as SMAP may be potentially bypassed in this case as the operating system’s direct map can be used as an alias for triggering cache presence.)

http://www.turbocu.com.tr
• •

Empy • January 6, 2018 9:03 AM

There is nothing wrong with 5 year old tech. My i7 3770 still runs around much modern day hardware. EOL not so fast. It’s no where near end of life. Processors are the failing egg in Moore’s law which ended a long time ago.

Who? • January 6, 2018 6:40 PM

@ Clive Robinson

Thus what I want is others to also learn from my mistakes, research, developments and luck. But I know the people who realy need it are not going to be able to implement it. They are those for whom the purchase of just one computer for a childs education means the parents go hungry. It’s also why I am deeply suspicious of the time of the anouncment, just after the busiest PC/laptop/pad sales period of the year…

I am suspicious of the time of the announcement too. Google revealed the bug to Intel on June 1st, I think. Both Intel and OEMs had a lot of time to work on a fix. My new workstation (a Dell Precision manufactured on December 4th, indeed I am a victim of this delay in the announcement too) got the microcode update on December 22nd. Of course Dell has not mentioned this fact yet, the firmware upgrade did include a brief “microcode has been updated” note, but it is listed as the release that fixes Meltdown and Spectre on the official (but not publicly announced yet, up to my knowledge) lists whose links I published on this thread yesterday.

The way this issue has been managed is a shame.

My hope is that these microcode updates will FIX the problem, not just MITIGATE it. Hell, how much I hate the word “mitigate,” since it was first used to describe the fixes for rowhammer based on increasing the memory modules refresh frequency. No, we do not want a patch that makes the bug more difficult to exploit, I would bet all of us want a patch that definitely closes it.

Spectre and Meltdown should be eradicated on any hardware architecture that supports a fix, i.e. on any hardware architecture whose microcode can be updated.

Do you really think Intel will release patches for, let us say, pre-2012 i-series processors? Or will Intel only release fixes for the “currently supported” architectures? i.e. processors manufactured after 2012.

Clive Robinson • January 7, 2018 12:17 AM

@ Who?,

Do you really think Intel will release patches for, let us say, pre-2012 i-series processors?

My gut feeling from what has already happened from the timing of events like selling of shares and options and overly delayed anouncments is that Intel will act with greedy self-interest followed by corporate lawyers advice…

Which basically means “Limit the liability, maximize the profits and rewards to dash with the cash”.

Mind you I can be a tads cynical in my old age 😉

Taz • January 7, 2018 3:56 AM

@Clive Robinson

You seem to have a solid grounding with the issues swirling around this week, so I’m hoping you will share a formula which might work to keep us safe – as many of us wear out the stacks of now vulnerable hardware we’ve collected.

There is no question most of this hardware would need to be scrapped if it were ever exposed to outsiders. That’s the only real fix. But is there any way we could use a hardened box outside our lan firewall perimeter to collect the newspaper clippings we might wish to collect for later import into a network filled with vulnerable hardware? That doesn’t seem possible to me….but perhaps you have a better idea.

I’m thinking of a homebrew version of that Authentic8 remote browser solution or a similar idea.https://www.authentic8.com/ Have resisted the additional expense in the past, but a bigger factor was the loss of control. Then of course there is the matter of moving information into storage without admitting spectre.

Ideas?

Who? • January 7, 2018 5:03 AM

@ Clive Robinson

Mind you I can be a tads cynical in my old age 😉

No, you are not cynical, you are just a wise man.

My initial hope was that a fully software-based approach were enough to fix this bug. This approach would have fixed on an acceptable way all my current computers (with manufacture dates ranging from 1997 up to 2013, except for the Precision Tower 3420 manufactured a month ago). Now we need to play the microcode card, so we are basically doomed.

Intel released a new microarchitecture last october (Coffee Lake), of course hiding the fact that it is vulnerable to both Meltdown and Spectre, and my bet is that Cannon Lake will be released on time too. The fact Coffee Lake has been released confirms your idea about Intel acting with greedy self-interest.

Who? • January 7, 2018 5:13 AM

…my bet is that Cannon Lake will be released on time too.

To be more precise, my bet is that Cannon Lake will be released on time and it will be vulnerable to both Meltdown and Spectre too.

Mark Kauffman • January 7, 2018 8:18 AM

None of my families Galaxy phones are affected. They use a Snapdragon processor based on an ARM core. See developer.arm.com/support/security-update. I found a handful of laptops available that are not affected. So, sure, dump the Intel – junk as Linus describes it, and find a box with a secure processor.

Clive Robinson • January 7, 2018 9:56 AM

@ Taz,

I’m hoping you will share a formula which might work to keep us safe – as many of us wear out the stacks of now vulnerable hardware we’ve collected.

FIRSTLY and most importantly see in your mind bright pink letters on a fluorescent green background in double bold capital letters the sage words of Douglas Adams,

    DON’T PANIC

There you feel better already 😉

Seriously there have not been any attacks in the wild we are aware of so time to think and take stock rationally, you may not have to do anything or very little at all.

Secondly another Adams quote,

    I can give you an answer but you are not going to like it

It’s not the Marvin “I can see a million outcomes but they all lead to certain death” (except for maybe Intel Managment 😉

No it’s what you might call the “security end stop advice” that works in nearly all cases.

Which put simply is develop split habits and use two “air or energy gapped” computers. One for your privacy/security the other for connecting to the world. Thus you don’t let nasties near your important kit which is the gapped computer. The second part of this is make a “goat box”, for connecting outside of your security zone for things like the Internet.

That is ask yourself,

    Do I care what attackers can do if the power switch takes the goat box back to a sane and usable state?

For many the answer is actually no they don’t care thus a motherboard with plenty of RAM running a CD/DVD in RAM OS will in many cases work fine…

BUT appart from the two box downside, it may mean a mental wrench as you have to modify the way you work your computer life. Alsi it means not just running two computers gapped you will have to on occasion cross the gap securely, and that can be difficult to do for many people.

As I said it’s what I would call the “end stop” solution for security as it applies for most Internet ills. Think of it as “The option of last resort”, for when they realy are out to get you.

That said you may not have to do very much at all… There is good news and there is bad news, and it’s more “user friendly” than “Intel based Server friendly”.

There are three basic attacks plus Google call version 1 to 3 and another ARM has thought up called 3a… The main attacks to worry about currently have the higher numbers.

AMD and ARM have been proactive and given tables of what the effects are on their products,

AMD chips are susceptible to 1 but not so much 2 and importantly not 3. So if you have an AMD chip in your kit don’t worry and install the appeopriate software patches at some point.

ARM –who remember do not make chips only IP– have given a list of core types and how they are effected. Mostly even if the core is in your device there is unlikely to be patches made available anyway. However it appears that the user side impact will not be high currently (though that may change if somebody weaponises the vulnarabilities.

Intel have issued “temper tantrum type corporate statments” that basically blaim the rest of the world and say there chips function to their design specification thus are technically correct…

Which is managment speaking lawyers for “We don’t give a damm”… If you have Intel based kit think carefully about what you are going to do, the go join a class action if you can but you probably won’t be able to…

Put simply the big time swallow of between 30-50% is for “CPU bound” systems, like servers. User machines are usually I/O bound not CPU bound. Thus even with all the patches you might only see a couple of percent reduction. Obviously if you are a Games player or developer who does lots of compiles you will be a lot closer to that 30-50% slow down.

The big problem especially for Intel who basically got it badly wrong is it is a new “Class of attack” with only a few known explotation instances which are POC code. At some point this is going to get weaponised. Worse for Intel is they have a hugh baggage of crap and corruption hidden behind the Instruction Set Architecture (ISA) interface software thus humans see. In the past there were undifined instructions in Intel CPUs that could do nasty or destructive things. There is no public knowledge as to if such holes in the instruction table still have chip Killer/maimers behind them and if other instances of this class can activate them or not.

The point is if you are an ordinary PC “user” you only realy need take action currently if,

1, The CPU is Intel.
2, You need it to connect out of your security zone.

Then you need to patch it up and keep your fingers crossed.

If you are a gamer or developer, then your best option is gap your machine so it neither connects out or can be connected to from outside. Thus if it’s only on a secure gapped network you can probably get away currently with doing nothing.

This advice will change if for no other reason Microsoft Win 10 demands you connect to the mother ship for their “telemetry” and other “tradesmans entrance” activities…

Hopefully OS patches will appear before exploits do, as for what Intel will do, probably very little except carry on “whining and whingeing it’s not our fault” or some such whilst the writs arrive.

As many others have noted appart from senior managment “insider trading” and delaying announcing beyond the Xmas sales peak, Intel have not been clear, transparent or even close to proactive over this. So “duck and cover” and wait it out.

Clive Robinson • January 7, 2018 10:23 AM

@ Taz, ALL,

There might even be a business opportunity in all this…

Can anyone here draw those Comic Book pictures like “Judge Dred”?

Well if you remember back Intel had a world wide advertising program that had people sort of dsncing in those shiny fluorescent “Bunny Hopper suites” that we were supposed to think was a “clean room suit”.

Well if you could draw one but in more Judge Dred proportions with evil red laser like eyes behind the visor, deamon like horns/ears on the top and teath that look like they could crunch concrete and bite through rebar. Give it a slight zombie apocalypse type stance climbing through a hole in a wall with a big biohazard symbol punched through, and in the fore ground a glass door with a big red stop sign with Danger written above and Intel Bugs Inside beneath,people might pay for them to stick on their laptop lids…

As the old saying goes “There’s no bad news only news” maybe we could prove it wrong and get Intel’s share price down by 30-50% it would be poetic justice 😉

Taz • January 7, 2018 12:12 PM

From my pile of old Thinkpads and motherboards I have isolated an atom based N270 ITX board. Unfortunately, try as I have – cannot find definitive information if this card is immune to spectre.

I’m thinking one of these could replace my current VPN proxy, while the other serves as the crude internet desktop machine? And I’m wondering if stronger/immune processors exist.

I mostly use powerful machines only for video editing. So sealing them off from the world is no loss. But I still need a machine to connect to the net and protect the few password protected accounts I allow our family. Otherwise, we go back to 1970 and do everything in person again (which is always an option – if inconvenient).

One thing which would really help right now is a list of tested processors immune to spectre. Google can’t find it…though there are hints.

TAZ • January 7, 2018 12:29 PM

Found

https://riscv.org/2018/01/more-secure-world-risc-v-isa/

The RISC-V community has an historic opportunity to “do security right” from the get-go with the benefit of up-to-date knowledge. In particular, the open RISC-V ISA makes it possible for many different groups to experiment with alternative mitigation techniques and share results. The RISC-V Foundation was formed with an open and inclusive governance model to allow for contributions from leading experts across academia and industry. Witness how the processor security research community (DARPA SSITH RISC-V-based program) is standardizing around RISC-V because it is simple and open.

Grauhut • January 7, 2018 1:57 PM

@Who?: Cannon Lake imho has a 50:50 chance to be born or unborn.

Maybe they will release some buggy socketed cannons in order to push the corresponding chip set into the market.

I think they will mod the “Ice Lake” Gen., that was announced 08/15/17. Unusual early announcement and just some weeks after they received the reports from Goggle.

“Google said it informed the affected companies about the Spectre flaw on 1 June 2017 and later reported the Meltdown flaw before 28 July 2017.”
(Guardian)

“Intel Officially Reveals Post-8th Generation Core Architecture Code Name: Ice Lake, Built on 10nm+, by Ian Cutress on August 15, 2017 9:20 AM EST

In an unusual move for Intel, the chip giant has ever so slightly taken the wraps off of one of their future generation Core architectures. …

This is an unexpected development as the company has yet to formally detail (let alone launch) the first 10nm Core architecture – Cannon Lake – and it’s rare these days for Intel to talk more than a generation ahead in CPU architectures.”

https://www.anandtech.com/show/11722/intel-reveals-ice-lake-core-architecture-10nm-plus

Mark • January 7, 2018 7:12 PM

Question. Why doesn’t the CEO of Intel take the $39,000,000 he ran off with from selling off his Intel stock, just before they revealed this, and help fix the problem? They new about it in June 2017, planed to reveal in Jan 2018, and his sale had nothing to do with that? Right, and I’m building a on land in Zanzibar, it’s a great investment opportunity for you.

Clive Robinson • January 7, 2018 11:37 PM

@ Mark,

They new about it in June 2017, planed to reveal in Jan 2018

How about the word “plotted” instead of “planed”, and add right at the end “right after the peak consumer sales for Christmas”…

Thus even though he’s personally cleaned up on his shares for 39million in change, he was still a company man as far as the share holders were concerned, ensuring they get those two quaters of good sales figures etc…

Also compare and contrast Intel’s response to the SNAFU compared to AMD and ARM.

Is it any wonder some investing related people are saying that this could be the end of Intel dominance in the Server Market fof a number of years…

That said, Intel having “Primed the Pump” on this doom fest, I’m wondering just what other little nasties Microsoft will slip into their patch… Most users will be blaiming Intel for the slowdown of their PC’s, which makes it a golden opportunity not to be missed for “Telemetry++” or similar…

Cassandra • January 8, 2018 4:28 PM

@Clive,

Thank-you for the link to Anders Fogh’s newest blog posting. It made for interesting reading.

One particular stand-out was his use of the term “Pandora’s Box”, and the phrase “In light of recent events, I shall not be publishing the rest of the stuff I did.”

I get the very strong impression that he has discovered a rather large area, probably related to Spectre, that could contain exploitable techniques, which is also not currently publicly known. The future might well be interesting.

Cassie

Clive Robinson • January 9, 2018 12:11 AM

@ Cassie,

I get the very strong impression that he has discovered a rather large area

I would not be surprised in the slightest if that were the case.

As I mentioned about the December Paper it kicked my “Hinky Thinking” into high gear with the possabilities I could see. Just one of those would be the equivalent of the “Dead Hand” or “Doomsday Device” that gave Rand Corp pause for thought with Nukes and gave rise to the Mutually Assured Destruction (MAD) idea that still pervades much of US thinking (and some say is a reflection of the mental state of Curtis LeMay).

It’s interesting to note that whilst Russian political leaders wisely rejected their scientists idea of the Doomsday Ship in shallow waters as monstrous, the US politicos did not… Thus the reason it’s said there are three times as many nukes in the US as there are in the rest of the world[1].

It is note worthy that an engineering son of a Russian premier, who had been party to nearly all his fathers visits to scientists and sort of acted as a sound board for his father to get a better understanding ended up becomming a Prof of history at Brown’s University in the US[2].

[1] Part of the reason why this was possible was Premier Khrushchev, wanting to pull in on military spending to make spending for social reforms possible. He thus opened up the belief via the Space Race that Russia had many rockets and was well ahead of the West. Due to overflights the senior US military and spy agenies knew as did senior political leaders that this was at best a figment of the imagination. Though they kept quiet so that the fear in US citizens alowed US rocketry that had been stalled since the end of the gathering stage of operation paperclip could get going, and that later JFK could make his University of Texas speech about setting a mission “that before the end of this decade” would put Neil Armstrong’s foot on the moon. Whilst also –supposadly– giving us PTFE for our frying pans and a significant kick start to both the computer industry and the electronics industry on which it relied. Oh and not forgetting fault tolerant high availability computers and communications, all whilst the flower power movment was cracking on through the Sixties[3]

[2] https://www.americamagazine.org/issue/my-father-nikita

[3] There is an argument that Ronald Reagan’s wife Nancy with her anti drug stance actually killed US free thinking in mathmatics, academia and industry. What is certain is her “just say no” had a darker side more akin to the work of senator McCarthy. It certainly gave rise to the seemingly endless and failed “War on Drugs” that the neo-cons pulling GWB’s strings then tried to repeate with “The War on Terror” which is responsible for many of the ills and woes in the US as well as other parts of the world. Oh and the hugh loss of personal freedoms and privacy that has turned the US into the worlds surveillance state, which has given us the idiocy of the IC and SigInt entities “Offensive Competative Advantage” that has all but destroyed computer security and in real terms done immense harm to the US and other Western nations economies.

John • January 9, 2018 8:32 PM

Since most people (99%) will not be attacked, why not tell us how to REFUSE the patches that slow their system? ..or if not possible REVERSE the patches after they are forced on us. Thank You.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.