'Kernel memory leaking' Intel processor -- a serious cpu bug!?!

[aciddose]

The way I see it, doesn't matter if you have AMD, because if the OS is issuing the fix, it will affect AMD processors the same as Intel.

That sure is what Intel would like you to believe.

Linus says something differnt on the commit comment

https://git.kernel.org/pub/scm/linux/ke ... source=anz

- Exclude AMD from the PTI enforcement. Not necessarily a fix, but if AMD is so confident that they are not affected, then we should not burden users with the overhead"

Is this the comment you are referring to? I have no idea how you relate that to anything I said in the portion of my post you quoted. Linus isn't saying anything about it, only acknowledging the patch from AMD which checks the CPUID and does not enable the feature for AMD processors.

What he means exactly by "not necessarily a fix" is most likely that there are likely better solutions to the issue than the AMD-supplied patch, but accepts it anyway due to its urgency. If it turns out AMD chips are affected AMD users will need to specify a flag on boot to force the feature to be enabled.

The patch merely adds an exception "if CPUID not equal AMD" which prevents the default being set to enabled.

[lnikj]

Am I correct in saying that both of these exploits require software to be installed that takes advantage of those exploits ? In other words you can't access them remotely ?

If so would the short term solution be not to install any new software on critical systems ? I have everything I'll ever need on my studio computer so never installing any new software on it would keep it safe from Meltdown and Spectre ?

Yes. Needs to be air gapped though. Spectre will probably be exploitable via Javascript in browsers.

[PurpleSunray]

Am I correct in saying that both of these exploits require software to be installed that takes advantage of those exploits ? In other words you can't access them remotely ?

You don't need to install, but only to run software locally.
That's the reason why WebBrowser companies provide updates as well, in adition to the OS kernel.
In there WebBrowser there is JScript code, that is executed by a JScript engine ... which is vulnerable to the same shit as the kernel is, as it also need to isolate stuff against each other.

[PurpleSunray]

The way I see it, doesn't matter if you have AMD, because if the OS is issuing the fix, it will affect AMD processors the same as Intel.

That sure is what Intel would like you to believe.

Linus says something differnt on the commit comment

https://git.kernel.org/pub/scm/linux/ke ... source=anz

- Exclude AMD from the PTI enforcement. Not necessarily a fix, but if AMD is so confident that they are not affected, then we should not burden users with the overhead"

Is this the comment you are referring to? I have no idea how you relate that to anything I said in the portion of my post you quoted. Linus isn't saying anything about it, only acknowledging the patch from AMD which checks the CPUID and does not enable the feature for AMD processors.

What he means exactly by "not necessarily a fix" is most likely that there are likely better solutions to the issue than the AMD-supplied patch, but accepts it anyway due to its urgency. If it turns out AMD chips are affected AMD users will need to specify a flag on boot to force the feature to be enabled.

The patch merely adds an exception "if CPUID not equal AMD" which prevents the default being set to enabled.

Here is the upstream commit my the AMD guy where he expains why this should be turned off for AMD:
https://lkml.org/lkml/2017/12/27/2

[PurpleSunray]

What he means exactly by "not necessarily a fix"

Nah, it think what he means that this commit is no fix for any problem, but it is actually disabling another fix (the one for Intels).

[aciddose]

Am I correct in saying that both of these exploits require software to be installed that takes advantage of those exploits ? In other words you can't access them remotely ?

If so would the short term solution be not to install any new software on critical systems ? I have everything I'll ever need on my studio computer so never installing any new software on it would keep it safe from Meltdown and Spectre ?

You "installed" and "ran" software when you loaded the KVR forum. It's called javascript. You should be using a tool like noscript to white-list (only run explicitly authorized scripts) but technically, we're all f**ked no matter what. There is no way to be 100% certain of the security of the system without replacing the CPU.

"Spectre" is a completely different class of attacks which are well known. Really these are just new ways to perform the same sort of timing attacks which have dozens of avenues. Most of these issues can be worked around, which has people talking about "fixes".

People have been speculating that the whole mash-up of the two bugs is a misinformation campaign to try to get you confused about the real issue: stupidly named "Meltdown", an Intel design flaw that removes all security from all Intel CPUs and can't be fixed completely without replacing the chips. There is absolutely no way to fix the bug, the Linux patch only makes it less likely the kernel memory can be accessed. It does not actually provide a fix for the fact a user process can read memory from where it isn't supposed to be allowed because it can't change the inner workings of the CPU.

Evidence is appearing showing manipulation of news sources and reclassification to try to avoid having customers fear buying Intel chips. If you're doing anything with security do not buy any Intel chips and replace them ASAP.

[PurpleSunray]

Evidence is appearing showing manipulation of news sources and reclassification to try to avoid having customers fear buying Intel chips. If you're doing anything with security do not buy any Intel chips and replace them ASAP.

Ermm.. why?
The problem is solved on kernel, there is no more security issue with that patch.
Ok, there is a performance impact on software that calls into kernel a lot. But I don't care.
On my PC there is Ableton Live and a bunch of VST plugins. So me for the most important thing is the audio rendering thread, which should not call into kernel anyhow (it was already costly before the patch.. don't do on audio processing loop) - there is no virtualized ESXi with 100 VMs each runnning a 1000TB SQL DB.. than I would be really worried about.

[aciddose]

Do you consider Ableton something you need extremely high security for?

The misinformation isn't targeted to single users who are worthless (what are you worth? $1000?). 99% of these CPUs are sold to be used in server farms, millions of office PCs and the like ($10000000000s?).

Something like a 20% performance drop or major unsolvable security issues means these customers won't even consider Intel's current lineup of products in their future purchase decisions.

[PurpleSunray]

Do you consider Ableton something you need extremely high security for?

Nah, but there is browser and email client and BattleNet App and ... where I enter passwords. They run the Intel CPU as well.
But the end I just don't care... this issues does not affect me.
The securty flaw is fixed on kernel, so MS makes sure nobody grabs my password via Intel bug.
Performance drop is no issue for me, since I do not run any databases, virtualization or stuff that calls into kernel a lot, but audio processing.

[aciddose]

You're assuming your password is in kernel space: it isn't!

It's in userspace along with any keys generated by your browser which are accessible right now via javascript.

This demonstrates how confused people are about these issues.

For the Intel flaw, this gives potential access to kernel space. Crackers don't need to update the kernel!

So say you have a copy protection using a kernel mode driver to communicate with a USB key dongle or similar situation. It transmits the keys in kernel space and attempts to make the process of its userspace code inaccessible too. This is now all accessible to the cracker.

[PurpleSunray]

You're assuming your password is in kernel space: it isn't!

So you tell me that key-input events arrive at my app magically, w/o kernel?
And the programmer of the App does the encryption on it's own, not using any windows API that involes kernel.
And TLS/SSL is also implemented by the App itself, not the kernel. And ...

I think all this fuzz only comes from speculations like yours.
Why do you think kernel does not see my password? Will depend on OS, kernel, app, ... so many things.
Worst case that FTP app sends password plaintext, so there about a ton of kernel modules that see it (socket, TCP stack, MAC driver, ..)

[Cinebient]

Doesn´t that mean that crackers could already done this since a decade.
It´s not that this flaw is usable for crackers just right now.

[lnikj]

Doesn´t that mean that crackers could already done this since a decade.
It´s not that this flaw is usable for crackers just right now.

They could, yes, if they knew it was there. No logs are left so who knows. Cue NSA speculations ....

[aciddose]

No, the Intel flaw wasn't known. Yes, they could have over-ridden any kernelmode protection for (apparently) the past 15 years or however long this flaw existed.

Regarding passwords: you know exactly how this works so why ask stupid questions? The point is the text is transmitted in the open in userspace, so whether it's in the kernelspace or not is irrelevant at that point. The real threat is via the less severe issue it is possible for javascript in your browser to potentially implement a keylogger. Some browsers have already been patched.

[lnikj]

Browser patching seems equally speculative though ... we know this is a timing issue so we'll make our timers less accurate ... and dance around a fire and hope that works for the time being.