'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign

Intel PDF:

https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf

 

Connecting via Wi-Fi? If so, you need to read this:

MADIoT – The nightmare after XMAS (and Meltdown, and Spectre)

https://www.welivesecurity.com/2018/01/08/madiot-nightmare-xmas-meltdown-spectre/

 

MSI will not provide a BIOS update for my 10 year old motherboard.

I tried this tool for the Intel Core 2 Duo E8400 CPU on that board, but after installation I see "No CPUs needed an update. Your system might not need this driver." in the Event Viewer (the E8400 is included on the Intel download page though).

Still InSpectre lists my system as vulnerable to Spectre (which I believe it is).

 

I think that this post sums it up well... https://www.wilderssecurity.com/thr...-xss-where-noscript-isnt.393256/#post-2666796

I generally run uMatrix with 3rd party scripts denied by default. If you need a site to allow 3rd party scripts to run, and wanted to ensure no XSS was possible, you could run NoScript in tandem with uMatrix with scripts whitelisted, but XSS denied.

 

Assuming that the code you execute locally on your computer is trusted and signed, then the scripts that run in the browser are the biggest remaining risk.

I would use some combination of Umatrix, uBlock Origin, (and noScript, but it's Firefox only), to minimize the attack surface.

 

"VMware Retracts Faulty Intel Firmware Patches For Chip Vulnerabilities

A bug in Intel's firmware update for Meltdown and Spectre that manifests itself when running virtual machines has prompted VMware to rollback a recently issued security patching recommendation. This adds yet another wrinkle of complexity for solution providers looking to protect their customers from the two side-channel vulnerabilities.

Customers alerted Intel that upgraded systems powered by some older Intel Haswell and Broadwell processors were experiencing unexpected reboots when running the Intel firmware upgrade

VMware had recently pushed out the Intel microcode upgrades for the physical hardware as a courtesy to its customers, alongside its own patches for ESX hypervisors—a mitigation framework the virtualization vendor recommended in its latest security advisory on the side-channel vulnerabilities...

On Monday, once Intel alerted VMware of the problem discovered in the field, VMware advised partners to no longer install those patches in tandem. VMware instead referred them to an earlier security advisory document that referenced patch releases not including the code from Intel..."

http://www.crn.com/news/security/30...firmware-patches-for-chip-vulnerabilities.htm

 

Inspectre new version 0.0.6591.2:

https://www.grc.com/inspectre.htm

 

I had applied the now 'pulled' BIOS update, experienced the WHEA and slowdown problems, so applied the changes you suggested in #582.

So I am assuming you are saying the respective bits would be best reset to the original '0' and '3' prior to a revised BIOS update, as per: https://support.microsoft.com/en-us...-to-protect-against-the-speculative-execution ?

 

I had also previously run uMatrix and personally found it more 'intuitive' (with NS in globally allow mode for XSS and clickjacking).

Will need to revisit and also how to best combine with uBO. There was previous discussion here: https://www.wilderssecurity.com/threads/enhancing-ublock-origin-with-umatrix.388704/

I currently run uBO in medium mode, is it best to revert to simple mode when running with uM?

Edit: Can someone point me to a best synopsis on how to run these together? (from someone who doesn't know his iFrame from his XHR).

True, script blocking is relevant to this threat but I suppose this discussion should be continued in a uMatrix thread.

 

Strict site isolation ensures that related sites run in separate processes (at the cost of higher memory use). While this protects against in-process memory scanning, it does NOT defend against all Spectre-class attacks because they can specifically go cross-process. Almost certainly a harder attack, but nothing to stop that.

It would help defend against more conventional malware where process isolation is more trustworthy.

Script defences are a more reliable control I think in this instance.

 

IMO using separate browser sessions for sensitive data is ATM enough secure.
Also, I wonder what data browser actually stores in memory if you manually enter credentials to log in. Credentials are sent to remote server, which issues session cookie or something similar. So I don't see a need for browser to store that data in memory (also don't know if it actually does).

 

I think you're right about levels of threat here at the moment. The medium term issue though is the industrialisation of malware. I do think the malware will have to be pretty sophisticated to do a practical industrial type job though.

As a developer interested in securing in-RAM secrets, there are many tricky issues depending on language and platform. But I guess most developers don't bother, which is the big exposure. The memory could contain the secret for some time, and indeed, it might be relatively easy to harvest it from the page you're on by injecting some event listeners, so that the secret is in the DOM and necessarily in memory at that point. And sometimes, you can't avoid keeping the secret in RAM (e.g. Truecrypt).

Good practice is things like zero-ing out memory once used, and then using garbage collection (but you can't rely on that happening immediately). You can also encrypt secrets and use platform/kernel functions to decrypt (e.g. things like DPAPI on Windows). My ideal is to have some two-factor going on, either locally, or with the remote web site, which is actually the real solution to the browser threats.

 

I am just guessing that whenever a password is entered in any field in webpage,the browser caches it in memory in plain form until you hit the submit button.That is why one can unmask the starred password by clicking on eye logo in IE before clicking submit.

 

Browsers use session cookies (that is, a cookie with expiration time empty/null) to pass information between itself and remote server when needing somekind of access control/user authentication.

Session cookie can be stored to disk but it would not make much sense because by definition, they are valid only for the given session and should be deleted after browser closes (expiration time empty). So it would make more sense to store them into memory and I guess most browsers will.

Different story are other kinds of cookies like those that are set when some site ask if you want to "keep me logged in" or similar. They are stored to disk and could have also expiration time other than empty.

Previously, cookies were the only way to pass data because HTTP has no other way to keep user state (it's a stateless protocol).
But then the HTML5 came and now we have things like local storage (similar to old persistent/tracking cookie but can store more information) and session storage (like old session cookie)

EDIT: And when I say more information I also mean more. Old cookies can store just 4 KB per cookie of information. HTML5 local/session storage can store several MBs !
EDIT2: And yeah, any passwords typed to those password fields in forms? Yup, they are really in plaintext in memory internally but of course hashed (or should be!) just before sending them by hitting submit

 

Glad you brought this up since I was going to myself.

Appears to me, one mitigation to these current issue is that browsers be modified to store sensitive data in memory encrypted.

 

Can be done, but to decrypt, you need the secret somewhere, and that will potentially be accessible. Often gets quite circular! I think in the medium term, some forms of local 2FA/coprocessor may help. But then - a loud message to website operators - SORT OUT DECENT 2FA ON YOUR SITE!!!!! I'd like to see that mandated for any site involved in taking payment, at least as an option. "Decent" does not mean SMS, biometric or smartphone based.

The other problem is that it's not always easy to be sure that the original plaintext variable is actually disposed of - and you normally have little control over that, especially for interpreted languages (this is normally a Good Thing).

 

@Stefan Froberg
Thnx. Can credentials be extracted from session cookies stored in memory? I always thought that it couldn’t.
Also while login data is in browser memory, is it stored in kernel memory that supposed to be protected by CPU?

Thanks all others for you answers also.

 

Not really a good analogy here. Disabling privacy related telemetry features is not the same as disabling critical security related mitigations. Personally, I would think that a concern associated with security issues would know better in this regard.

 

You couldn't because you weren't supposed to as per OS rules but you can now provided you can create a meltdown/spectre exploiting script & run it on your pc.All things encryption related(& actively running in OS) require a decryption key which is always stored in kernel memory only when any OS is running.That is why using a separate hardware independent from your pc processor as 2nd factor authentication is the safest way.

 

Yes, that's correct. Although on non-Server builds of Windows, I believe that you could even delete those registry keys and everything would be returned to default anyway since non-Server builds enforce it by default. So the registry keys in this case are more used to disable the mitigation(s). I would suggest as you said, original '0' and '3' is the best way to go for now.

 

Some users are reporting success with the VMware tool applying the microcode at boot, while others are reporting failure on that. I have no idea why the success rate is scattered like that, though. I was able to successfully apply the microcode with the VMware driver to my physical system, however, it failed on a Hyper-V guest that I tried it on.

Regardless, the Intel microcode continued to cause problems (WHEA errors due to CPU page faults) whether I used the VMware driver or built into the BIOS.

So the best choice right now is to wait until Intel fixes their issues (many reported issues) in their next microcode release. Hopefully they push a fix out this week to manufacturers, but who knows at this point.

 

I think you'd expect it to fail on the Hyper-V guest - a hypervisor won't try to emulate all aspects of the Bios, and indeed, if VMWare's anything to go by, there are hypervisor patches specifically to do the correct reporting (like PCID) and mitigations for Spectre & Meltdown.

Thanks for the feedback on the driver experiments.

 

In theory, yes. Let's say some bad guy knows intimately well where and how some open source browser X stores it's cookie data in memory.
And not only that but also a way that it could be retrieved with client-side scritpting language, like JavaScript.

Now, he/she could kick some domain up, copy-paste maybe some interesting stuff from some other site for content and then inject it with a
piece of JavaScript code that sniffs your browser, sends the evil cookie grabbing payload toward you if the browser happens to be browser X,
and then send it back to his/her server.

Only thing left to do is to try to lure all the users of browser X to his/her evil page.

But that was only theory, because browsers are not supposed to allow grabbing stuff from between different tabs (that is, say one tab where your online bank is open and another tab where the evil page is)

That theory just became reality with the meltdown+spectre combo.

@itman is right, there should be some browser standard for encrypting all the cookies/passwords etc.. all the sensitive info that's is keeped in memory.

Also, there really is no any standard how login stuff is handled or encrypted (if it is encrypted at all!) and it's all implementation dependent.
Your login security depends of the competence of the web developer. (nothing stops them sending your login stuff in plaintext in those cookies
and your only hope is that they at least were wise enough to use HTTPS during the whole session...hopefully)

In the early days (when HTTPS was not yet common) there was HTTP Basic auth but that was laughtably insecure (uses easily reversible base64)
It was replaced by HTTP Digest Access Authentication (RFC 2069) and later strengthened version (RFC 2617) but unfortunately many of the enchancements to login process were optional and MiTM attack was easy (remember, HTTPS was still rare in those days, around 1997), they could force clients to use weaker RFC 2069 or even just the Basic auth.

So two standard ways to handle login, one horribly weak and one only little bit stronger. And then all the rest out there are non-standard, ad hoc methods.


Only hope is HTTPS, keep all the sensitive stuff as long encrypted as possible, keep machine patched and cross fingers .....

 

HitmanPro.Alert offers keystroke encryption as an anti-keylogger risk reduction. So the browser dialogue boxes where you enter info are protected by encryption. I wonder if this extends to the data being stored in memory?