UPDATED: Intel and its flawed Kernel Memory Management Security

It has emerged that Intel CPUs made in the last decade or so are missing proper checks when it comes to securing Kernel Memory. It would seem that through special (undocumented) steps, a User-Mode application can peek and make changes to Kernel-Mode Memory. This means that any application, such as your browser, can access and change your system memory.

Some theory

In the 32-bit era, an application could typically access up to 4GB of RAM; this has been de-facto for ages. What really happened is that the application had access to 2GB of for User-Mode memory (used to typically hold the memory needed by the application to function). The other 2GB is mapped to Kernel space, containing memory locations for Kernel-Mode memory.

In the 64-bit era, these memory limitations were lifted since a 64-bit architecture can access such a larger address space (16 exabytes, to be exact). Given that the Kernel-Mode memory is so much larger (248TB), the OS can randomly place it anywhere it pleases, randomly. This randomness (Address space layout randomization) successfully makes it so much harder for foul-playing applications to find the addresses of Kernel-Mode functions.

So, what’s happening?

Typically the code that runs in User-Mode (typical code) does not have access to the Kernel-Mode memory. The reason why this is done is so when an application switches to Kernel-Mode (needed for example to open a file from disk), the Kernel-Mode memory would still be accessible, avoiding the needed to have 2 memory tables, one for User-Mode and one for Kernel-Mode. Having more than one table will mean that during every sysenter (or equivalent), tables will need to be swapped, cache needs to be freed and any overhead that such operations require.

It would seem that on Intel CPUs, hackers have found a way to bypass this security feature. This means that a User-Mode application can now access Kernel-Mode memory; which is devastating. A User-Mode application can apply small changes to the Kernel and change its functionality. Since an application has access to Kernel memory, a hacker can basically do whatever he pleases with the target’s system.

How can this be fixed?

Unfortunately, an easy fix is not available. The whole memory management logic needs to be re-written, so that instead of having just one memory table, which maps both User-Mode and Kernel-Mode memory, an additional table will hold the Kernel-Mode memory; this table will be only accessible from Kernel-Mode memory. The change is being dubbed as Kernel page-table isolation (KPTI, known as KAISER).

Adding a new memory table and switching to-and-fro has negative effects on the overall system performance, especially in I/O heavy applications. The reason is that I/O involves a lot of User-Mode and Kernel-Mode switching. Given that the new code needs to run every time the system switches from User-Mode to Kernel-Mode. performance degradation are expected. Unofficial figures quote between 5%-30% performance impact, depending on the application. OC3D has provided some benchmarks; FS-Mark (I/O benchmark) show a devastating hit in performance. PostgreSQL said that there is a best case of 17% slowdown, worst case of 23% using new new Linux patch.

Which operating systems are vulnerable?

Basically, all Operating systems are vulnerable to this hack. this is because this is a bug that goes beyond the operating system, since it lives on the CPU rather than on an operating system level. Scary! Vendors have been (secretly) informed of this issue and are working on fixing the vulnerability:

Are non-Intel CPUs vulnerable?

All we know at the moment is that AMD CPUs are NOT vulnerable. This has been confirmed by AMD themselves. In fact, Tom Lendacky from AMD has issued a fix for the Linux kernel itself, adding a check so that if the CPU is AMD, the mitigation is not applied.

What’s next? How can I stay safe?

If you got an AMD CPU, well then congratulations, you’re safe! If you’re on an Intel System, don’t panic just yet. Yes, you are vulnerable, but yes, you still control what you do with your computer. If you don’t visit dodgy websites and don’t install dodgy applications, you’ll remain safe. But that’s age-old advice.



We need HTTPS – Today more than ever! – Avoiding the KRACK Wi-Fi Attack

Any decent tech guy knows that WPA2 has been officialy broken using an attack called KRACK. What does this mean? It means that any WPA2 network can be attacked with a Man in the Middle Attack, providing that the attacker is close (or has a device close) to you. Ouch!

This reminds me back in the day where FireSheep was still a thing. This allowed any user to Hijack any unsecured Wi-Fi and browse the user’s session. This now means that WPA2 is now as secure as Unsecured Wi-Fi since any data travelling on WPA2 can potentially be sniffed out.

Allright then, what does it mean for me, as a consumer? This means that at the moment, one cannot fully trust that no-one is listening on his WPA2 network. This also means that we need HTTPS now, more than ever! Why? Simple, because this means that if the user does indeed get a hold of your traffic, he still would not make any sense of it since it’s being encrypted! VPNs now also play a good role here; one can use a VPN to make sure that any traffic that he generates (even HTTP traffic) is indeed encrypted.

If you’re connected to a network and not using HTTPS (or the HTTP protocol in general), unfortunately, you’re out of luck. You can’t safely rely that no-one is listening on your data. This means that if you’re running some Wi-Fi enabled camera, make sure that it’s either running a secure (HTTPS based for example) protocol, or just turn it off.

Fortunately, this issue is not persistent – a software update can be handed out in order to address this issue. Software vendors have already been notified on how to address this issue, it’s just a matter of waiting for said vendors to issue a fix.

In short, don’t assume that you’re safe if you’re running WPA2; the only way to encrypt your traffic is by encrypting it (HTTPS / VPN). Read more in depth on this hack here.