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

HMP.A is only encrypting the transport of the keystroke from your keyboard to the password dialog/protected application.

 

In an attempt to provide a quick answer, I will just say this:

1. I use uMatrix only as my script and browser element controller, on a site by site basis, but with all the blacklisted host name files turned off. uBO has duplicates of the uMatrix Hosts files, so no need need in duplicating that effort.
2. I use uBlock Origin in basic mode with the selected 3rd party filters that I want enabled. This allows uBO to be my filtering and blacklist tool for known malware, ad, and tracking sites.

If you want more info, probably best to discuss in another thread.

 

Well if that is the case, then until our firmware is fully updated and OS patched, we must be vigilant that nothing running on our computer is malicious. Must assume our memory can be compromised, and only run one browser and/or one browser tab at a time if working with confidential info. If working locally with documents that need to be secured, probably a good idea to shut down any browser or internet facing apps to mitigate risk.

 

Thank you. I'm interested in how to work with both uMatrix and uBlock Origin to mitigate the risk in Chrome. So could you open a new thread for in-depth discussion?

 

Recommend starting here with this open thread referenced above by paulderdash, rather beginning a new one, as there is already some info here. I will give it a bump.

https://www.wilderssecurity.com/threads/enhancing-ublock-origin-with-umatrix.388704/

 

I think the browser patches also help, and it may be that the browser Jit can trap some of these scanning events too, who knows. At least to raise some kind of event which could be investigated.

Plus, all the realistic attempts at script control and ad-blocking - you mention evil scripts looking for ways to run, and the ad scene is surely one of them. And 2FA on the site....

And running separate sessions/boots for sensitive data entry - it would be quite a lot harder, I assume, to go round finding other processes and scanning their memory.

 

Could be, I have never ever tried to "do evil" (that is: write any code to read other processes memory).

But now I am almost tempted to try, especially after seeing how trivial it is to lists currently runnig processes (at least on Linux and with C)
as shown with my print_all_pids() function that I talked in:
https://www.wilderssecurity.com/thr...software-for-linux-programmers-part-1.399715/

Listing processes does not seem that hard on Windows either:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682623(v=vs.85).aspx

Different story is, how easy (possible?) it's to dump memory of processes and also to adapt those examples to workable exploit code that could be run on browser.
JavaScript? WebAssembly? Some other way? Hmmmmmm......

Update:
Reading process memory (at least if have access rights) seems very easy:
http://nullprogram.com/blog/2016/09/03/

 

InSpectre: Check Spectre and Meltdown Prevention
From Gibson Research Corporation

Now at Release #4 - Silent System Probe Option

Steve Gibson explains his "Inspectre" utility for Meltdown and Spectre.

Episode #646 Jan.16 2018

https://www.twit.tv/shows/security-now

 

Regarding browser script control, I assume AdGuard is less helpful than a uBO/uM combo as this is not its primary modus operandi, though it does obviously block ads ...

Edit: I suppose one could use uMatrix alongside AdGuard if one is using the latter.

 

since the microsoft patch of January 4 my desktop has problem on the start, it appears the Asus logo but after this the monitor is black, I have to click in the start button of the pc to restart and after the Asus logo appears the Windows 10 logo and the pc works. So when I see today the new KB 4073290 i installed it, this new update has the patches for Meltdown and Spectre, right? hope that this solve the problem at the start

 

I think history shows that those who publicly profess to do no evil, and more, protect us from unspecified threats, end up doing most harm.

As you say, with sufficient privileges, it's not hard to read other processes memory. And Spectre (without privilege) can in any case read another processes memory - if it can find what it's after. What's more, I think whether closed source or open, it's relatively easy to establish where well-known secrets are held. My understanding is that ASLR is not a hard defence against this (obviously not in-process). My feeling is that this would then be used to exfiltrate the data, although it might be used to inform future attacks, though that sounds more like TAO type operations which probably don't concern us so much. I think Javascript could do this without any need to write anything or escalate anything.

I do think the cross-process attacks will be difficult and unreliable, let's hope that some of the software mitigations we are seeing will prove effective at rendering them pointless in comparison with the many other "conventional" malware attacks.

One way of mitigating the lifetime of stored secrets in RAM might be to use something like the Yubikey HMAC function, so that what normally sits in memory is a value pre-hashed, that would require the HMAC operation to be performed to recover the "real" secret. That way, you have the HMAC secret outside the computer memory (on the Yubikey). The real secret will still necessarily appear in memory however briefly, so that may not yield the desired protection. The proper way for websites is of course to implement 2FA.

Sandboxing - such as used by Firejail or Sandboxie, will I think continue to be valuable, not because it's a defence against Spectre itself, but because it prevents/inhibits many conventional attack escalations from the initial breach.

 

"Intel says newer chips also hit by unwanted reboots after patch

Intel's firmware fix for Spectre is also causing higher reboots on Kaby Lake and Skylake CPUs.

Intel says the unexpected reboots triggered by patching older chips affected by Meltdown and Spectre are happening to its newer chips, too.

Intel confirmed in an update late Wednesday that not only are its older Broadwell and Haswell chips tripping up on the firmware patches, but newer CPUs through to the latest Kaby Lake chips are too..."

http://www.zdnet.com/article/meltdo...unwanted-reboots-after-patch/#ftag=RSSbaffb68

 

"Patch-Induced Reboot Errors Impact Kaby Lake, Skylake, Ivy And Sandy Bridge, Too...

...The buggy firmware updates were distributed to motherboard vendors as part of a BIOS update. Many of the vendors, such as MSI, ASUS, and Gigabyte, have issued press releases announcing the new BIOS revisions this week, but for now, it might not be wise to update to those versions. Users that haven't installed the latest BIOS are not affected, and Intel says that new patches will enter the validation phase early next week..."

http://www.tomshardware.co.uk/intel-reboot-meltdown-spectre-processors,news-57753.html

 

Does Intel released microcode for Ivy and Sandy Bridge? Where can I find it?

 

He does bring up that anyone not currently running Win 10 1709 might not be mitigated by the Windows patches issued to date. And that MS might be using this situation to force people to upgrade to 1709.

 

These updates would need to be provided by your system manufacturer, not Intel, unless you have an Intel branded system or motherboard. Up to them whether they decide to release updates for out of warranty hardware.

I am impacted because I am running two Ivy Bridge gen systems... well past the three year warranty on my Asus boards...

 

FYI - I downloaded and ran GRC's InSpectre in admin mode and you can no longer disable either the Meltdown or Spectre Win mitigations.

 

How is that any good? Just installed it myself. Thanks.

 

Is there anyone who understood how to do it?

 

Start -> Run. Then enter C:\folder name where installed\InSprectre.exe -probe

See if that works.

 

I noticed this as well with InSpectre release 4. It does not seem to be showing correctly based on what is in that registry key as it was with release 1. I'm not sure what GRC has done within the past few releases since it was initially working correctly. Something to do with his antivirus detection workaround, I assume.

 

Not works:

 

Yeah, I tired all command line options I am familiar with and none worked.

 

Right click on the "ghosted " box symbol shown in Inspectre window. Then select "Tech details." It show you everything that "probe" was supposed to and much more.