https://git.kernel.org/…/ke…/... sure some of you are working on the patches already, if you are then lets connect cause, I am an ardent researcher for the same as of now.

So here it goes:

As soon as kernel page table isolation(KPTI) bug will be out of embargo, Whatsapp and FB will be flooded with over-night kernel "shikhuritee" experts who will share shitty advices non-stop.

1. The bug under embargo is a side channel attack, which exploits the fact that Intel chips come with speculative execution without proper isolation between user pages and kernel pages. Therefore, with careful scheduling and timing attack will reveal some information from kernel pages, while the code is running in user mode.

In easy terms, if you have a VPS, another person with VPS on same physical server may read memory being used by your VPS, which will result in unwanted data leakage. To make the matter worse, a malicious JS from innocent looking webpage might be (might be, because JS does not provide language constructs for such fine grained control; atleast none that I know as of now) able to read kernel pages, and pawn you real hard, real bad.

2. The bug comes from too much reliance on Tomasulo's algorithm for out-of-order instruction scheduling. It is not yet clear whether the bug can be fixed with a microcode update (and if not, Intel has to fix this in silicon itself). As far as I can dig, there is nothing that hints that this bug is fixable in microcode, which makes the matter much worse. Also according to my understanding a microcode update will be too trivial to fix this kind of a hardware bug.

3. A software-only remedy is possible, and that is being implemented by all major OSs (including our lovely Linux) in kernel space. The patch forces Translation Lookaside Buffer to flush if a context switch happens during a syscall (this is what I understand as of now). The benchmarks are suggesting that slowdown will be somewhere between 5%(best case)-30%(worst case).

4. Regarding point 3, syscalls don't matter much. Only thing that matters is how many times syscalls are called. For example, if you are using read() or write() on 8MB buffers, you won't have too much slowdown; but if you are calling same syscalls once per byte, a heavy performance penalty is guaranteed. All processes are which are I/O heavy are going to suffer (hostings and databases are two common examples).

5. The patch can be disabled in Linux by passing argument to kernel during boot; however it is not advised for pretty much obvious reasons.

6. For gamers: this is not going to affect games (because those are not I/O heavy)

Meltdown: "Meltdown" targeted on desktop chips can read kernel memory from L1D cache, Intel is only affected with this variant. Works on only Intel.

Spectre: Spectre is a hardware vulnerability with implementations of branch prediction that affects modern microprocessors with speculative execution, by allowing malicious processes access to the contents of other programs mapped memory. Works on all chips including Intel/ARM/AMD.

For updates refer the kernel tree: https://git.kernel.org/…/ke…/...

For further details and more chit-chats refer: https://lwn.net/SubscriberLink/...

~Cheers~

(Originally written by Adhokshaj Mishra, edited by me. )

A group of Security researchers has officially fucked hardware-level Intel botnet officially branded as "Intel Management Engine" they did so by gathering it all the autism they were able to get from StackOverflow mods... though they officially call it a Buffer Overflow.
On Wednesday, in a presentation at Black Hat Europe, Positive Technologies security researchers Mark Ermolov and Maxim Goryachy plan to explain the firmware flaws they found in Intel Management Engine 11, along with a warning that vendor patches for the vulnerability may not be enough.

Two weeks ago, the pair received thanks from Intel for working with the company to disclose the bugs responsibility. At the time, Chipzilla published 10 vulnerability notices affecting its Management Engine (ME), Server Platform Services (SPS), and Trusted Execution Engine (TXE).

The Intel Management Engine, which resides in the Platform Controller Hub, is a coprocessor that powers the company's vPro administrative features across a variety of chip families. It has its own OS, MINIX 3, a Unix-like operating system that runs at a level below the kernel of the device's main operating system.

It's a computer designed to monitor your computer. In that position, it has access to most of the processes and data on the main CPU. For admins, it can be useful for managing fleets of PCs; it's equally appealing to hackers for what Positive Technologies has dubbed "God mode."

The flaws cited by Intel could let an attacker run arbitrary code on affected hardware that wouldn't be visible to the user or the main operating system. Fears of such an attack led Chipzilla to implement an off switch, to comply with the NSA-developed IT security program called HAP.

But having identified this switch earlier this year, Ermolov and Goryachy contend it fails to protect against the bugs identified in three of the ten disclosures: CVE-2017-5705, CVE-2017-5706, and CVE-2017-5707.

The duo say they found a locally exploitable stack buffer overflow that allows the execution of unsigned code on any device with Intel ME 11, even if the device is turned off or protected by security software.

For more of the complete story go here:
https://blackhat.com/eu-17/...
https://theregister.co.uk/2017/12/...

I post mostly daily news, commentaries and such on my site for anyone that wish to drop by there