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

I think in a way, the industry focus has been (possibly rightly), on mediating the impact to the humongous data center hypervisor and shared hosting multi tenant environment. That's where the big money, biggest risk, and support contracts exist.

I'm afraid consumers and small-medium businesses are on the "when I get round to it" item on the to-do list as far as the vendors are concerned. For the processor companies, mobo manufacturers and OS vendors - they have already got your money.

They will release patches, maybe, as we've seen, with minimal testing and explanation. And as we all suspect, may never release the Bios updates for older motherboards. What's bizarre right now is that MS has not released microcode for Windows (technically they could), even though Intel has noted it's not viable to update all the Bios even if it were available. I would guess that's because there's nothing in it for them really - if it goes wrong, as it may well do, they've got a world of complaints and rollback (as they have to an extent with the AMD patch debacle in Windows to start with).

If I'm being charitable to MS, it may be because they want to be able to assess and test the updates better. I'm with that! The other aspect is that, while proper Meltdown/Spectre mitigations are obviously best, for clients the main risk is in scripts running in the browser IMO. In that case, it's likely that mitigations in the JIT compiler will provide substantial protection. But the problem is, that's all speculation and there are few reliable sources to evaluate the real-life threats and suitable mitigations for the consumers - that would be the province of the big IT departments and consultants, who, again, would not be interested in helping the great unwashed.

 

Already planning my next PC build. But I think I'll wait until the next gen of hardware is released with a new chip design!

 

Well said!!!

 

The situation in my old pc with XP:

Comments are welcome.
TH.

 

Absolutely. Band-Aid fixes that are likely to cause you a lot of pain as you rip them off one by one as each new one comes along. Ugggh.

Which also makes it a Catch 22 if you wanted to move away from a system that cannot be hardware or microcode updated - you will not be able to move to a new less vulnerable design for at least a year and probably more, so in my opinion, unless you're running a shared hosted system, you might be better off not bothering to "upgrade" now, and taking steps to control what does run on your system. There's also the possibility that we'll get microcode updates via the OS too.

 

To be fully mitigated against the current demonstrated Intel Meltdown and Spectre vulnerabilities, all the following must be done:

1. OS software patches applied.
2. App software patches applied; e.g. NVidia driver updates, browser updates, etc..
3. BIOS firmware changes applied.

Since you are running XP which is no longer supported, you are lacking the OS patch mitigation.

 

Well, I could see list of process PIDs and also their memory ranges without problem, no matter if two non-root accounts (I did the test by login to two separate virtual consoles just in case) or non-root & root.
But trying to actually read some other user process memory kicked "Operation not permitted" like it should.

 

I know. I just wanted to test how easy it is to read process memory as general.

 

This does bring up the question of if your security solution can prevent a malware debugger from doing like activity? Here's a MS utility for example that will not only allow you to view a process's memory but also modify it: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/memory-window

 

For Unix-like OSes (Gnu/Linux, *BSD family. I don't know macOS) running program on separate user account for example by OpenSSH. It might seem as overkill, but I heard that processes started by sudo can inherit some privileges, so it is better to use other tools like mentioned OpenSSH.
For example isolate rest of system from browser: https://www.dragonflybsd.org/docs/docs/handbook/RunSecureBrowser/

 

To go deeper within point 2, compilers (GCC, Microsoft's Visual Studio, etc.) are also having mitigations applied in which many applications will need to be compiled again with these updated compilers. There was some suggestion of compiling entire Windows OS with this and apparently had only minimal (if any) performance impact.

 

You mean my sandbox guide for Linux app developers? If the malware exploit manges to get inside sandbox it should see (because PID namespace) only the process PID that started the sandbox. But with Spectre around, Im pretty sure that it could see other processes too ...

Hmmm...Can it write to any process memory? For example non-admin trying to modify processes running as admin?
I could of course update the process memory tester for Linux but I don't think it could write to any other process memory regions except those marked with "w".

 

The following from SANS pretty much sums up the Meltdown and Spectre vulnerabilities. Since Meltdown attacks the OS kernel, I would say that it is the worst of the two:



Here's is the full SANS article on the subject which is definitely worth a read: https://www.renditioninfosec.com/files/Rendition_Infosec_Meltdown_and_Spectre.pdf

As far as browser mitigations go, besides apply the software patches, is the following. I find it ironic that a protection mechanism, i.e. sandboxing, is what is being exploited :

This is how I run IE11, each tab will spawn a new instance of IE11.

 

Here's some more info on WinDbg use: https://docs.microsoft.com/en-us/wi...bugger/getting-started-with-windows-debugging

 

I would say that sandboxes are not exploited. They are getting bypassed and only when it comes to reading.

 

@itman - I'm really confused by that SANS report because it says Spectre cannot access kernel memory, whereas the Project Zero report enumerates one PoC that did do so. It would be really nice to know...!

Actually, just checking again, it seems that a variant of BTI Spectre (PoC#3), running with root privileges inside a KVM guest "can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization" - but that some initialization over 30 mins was required first.

https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html

 

"Determine if you will be doing kernel or user mode debugging. Kernel mode - Kernel mode is the processor access mode in which the operating system and privileged programs run. Kernel mode code has permission to access any part of the system, and is not restricted like user mode code. It can gain access to any part of any other process running in either user mode or kernel mode. Much of the core OS functionality and many hardware device drivers run in kernel mode."

Jees! That's quite powerfull
That silly process memory test that I made uses Linux syscall but even then it has not that kind of power.


Hmmm... there is still ptrace syscall that I haven't tried yet ............

 

The SANS report is quite specific:

Google's POC for Spectre variant 1 & 2 in ref. to points 2). and 3). clearly note that Linux was used. For points 1). and 4). does not have a specific OS ref.. However. from remaining language in the doc., it appears to me all testing was done on Linux.

Therefore I can only assume the SANS Spectre comments are directed to Win OSes.

 

Maybe where the confusion is coming from is a process is obviously communicating with the ntoskrnl.exe. Data is being transferred from/to the process's memory space. It is this data that can be hijacked.

 

https://www.bleepingcomputer.com/ne...tches-after-receiving-reports-of-boot-issues/

 

I just wanted to say that the Ashampoo tool didn't work, but I didn't have any problems with GRC's InSpectre tool, it even works with limited rights, quite a good tool.

Correct, there is a risk, but I'm not convinced it's a big risk. It all depends on how easy it's to exploit. If anyone can setup a website and steal passwords from the browser's memory with the help with a bit of JavaScript, while the browser continues to work normally, then it's indeed quite serious.

 

That is exactly what can happen with the Spectre vulnerability. The only restriction presently is it is not any easy attack to pull off; more so now that most browsers are being patched to make memory timings more difficult to predict.

 

wyxchari writes:

https://www.msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/?page=146

***** Will it be true?

 

As far as the FSB remark, yes. This is why original articles noted pre-1995 processors are not affected. They don't have internal cache memory.

As far as InSprectre goes, I agree. It made a number of default system setting changes on my Win 10 1709 build.

-EDIT- xyxchari's last reply to you: