Speculative execution prevention for Windows drivers(?)

NTDEV
1

Hey, guys.

As we can see from recently disclosed exploitation of CPUs “features” called Spectre and Meltdown, it is possible to use speculative execution to bypass base Win/CPU code execution security model. In case of Spectre you can un-sandbox JavaScript in web-browser and read Ring 0 memory from usual app (Meltdown).

What do you think about danger of speculative execution for drivers and their code?

Recently Microsoft published a blog post about introducing new compiler switch (/Qspectre) for VS2017 to prevent speculative execution in sensitive part of code (where conditional jumps are located). They are recommending to use it for software compilation.

What do u think about using this switch for [device] drivers compilation? Are there present sensitive cases and conditions for drivers, where speculative execution can be used for unauthorized code execution/data access?

I saw recent NVidia audio driver, they compiled it with prevention of speculative code execution.

Microsoft blog post below.
https://blogs.msdn.microsoft.com/vcblog/2018/01/15/spectre-mitigations-in-msvc/

2

xxxxx@gmail.com wrote:

As we can see from recently disclosed exploitation of CPUs “features” called Spectre and Meltdown, it is possible to use speculative execution to bypass base Win/CPU code execution security model. In case of Spectre you can un-sandbox JavaScript in web-browser and read Ring 0 memory from usual app (Meltdown).

What do you think about danger of speculative execution for drivers and their code?

You know, I have to say that I am baffled by the panic over this
problem.   Yes, it’s ugly that user-mode code can smell kernel-mode
memory, but there are two things to remember.  First, the attacker has
to get user-mode code running on my machine.  Assuming the usual good
practices, that’s a very difficult thing to do.  Second, the exploits
can read that memory very slowly, about 2k bytes per second.   If you’re
going to use this exploit, you’d want to read net and disk buffers, but
those are incredibly dynamic.  They don’t stand still long enough for a
2k B/s reader to grab anything coherent.

Personally, unless I have missed a memo, I see this as much less of an
issue than the old FDIV bug.

And your last sentence reflects a misunderstanding of the problem.  The
problem is not that speculative execution makes your code vulnerable. 
The problem is that an attacker can USE speculative execution to snoop
information about static kernel memory.

Recently Microsoft published a blog post about introducing new compiler switch (/Qspectre) for VS2017 to prevent speculative execution in sensitive part of code (where conditional jumps are located). They are recommending to use it for software compilation.

But that’s silly.  It is the ATTACKER that uses speculative execution. 
There’s no danger added by having kernel code that uses speculative
execution.

 

What do u think about using this switch for [device] drivers compilation? Are there present sensitive cases and conditions for drivers, where speculative execution can be used for unauthorized code execution/data access?

I don’t think it can.  Certainly there’s no way to cause unauthorized
code execution.  The best the attacker can do is sniff out the contents
of some kernel addresses.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Tim Roberts wrote:

And your last sentence reflects a misunderstanding of the problem.? The
problem is not that speculative execution makes your code vulnerable.?
The problem is that an attacker can USE speculative execution to snoop
information about static kernel memory.

You are speaking about Meltdown, when attacker USE his own exploit. But in case of Spectre an attacker can use weakness of speculative execution of another app that works into a system. New compiler switch is intended to break this situation, when attacker can’t use your own code gadgets to exploit speculative execution, which is based on branch predictor, to execute their code out-of-context. Your initial statement looks incorrect in case of Spectre, because attacker can exploit your own code with mitigation to achieve own goals.

There’s no danger added by having kernel code that uses speculative
execution.

If there is no danger for Ring 0 code, why Win10 kernel developers bring updated trap- and interrupt- handlers with “lfence” instruction against speculative execution as a mitigation measure for Spectre in latest update? I mean that major update when they released KPTI.

4

Just a quick update:

We’ve been working on the meltdown/spectre issues for the past couple of weeks… We’re hoping to be able to put together some intelligent guidance for the community soon.

Peter
OSR

5

I’m beginning to think that Tim Roberts was right, an attacker use speculative execution of its own code to exploit the Spectre in common scenario. This means that a benefit of /Qspectre is pretty small.

6

Agreed. But the COST is also pretty small. So…

Peter
OSR
@OSRDrivers

7

Tim Roberts wrote:

You know, I have to say that I am baffled by the panic over this problem…

Same here Tim, same here. You haven’t missed any memos.

Gerard

8

Agreed

Sent from Mailhttps: for Windows 10

From: xxxxx@osr.commailto:xxxxx
Sent: January 23, 2018 11:54 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Speculative execution prevention for Windows drivers(?)



Agreed. But the COST is also pretty small. So…

Peter
OSR
@OSRDrivers

—
NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></mailto:xxxxx></mailto:xxxxx></https:>

9

Your analysis seems to overlook even more important problem for the attackers - they have to know what they are looking for, and,in order to make an educated guess in this respect, they have to be in control of a system scheduler. For example,let’s look at the original paper

https://web.archive.org/web/20180103225843/https://spectreattack.com/spectre.pdf

First they do a bit of training, then they call the victim, and then they try to analyse things.
In other words, they know their victim in advance so that they can jam it precisely in between the training and analysing parts of their malicious code. However, when it comes to practical implementation, things are not necessarily THAT simple. For example, you can yield execution after having accomplished a training part. However, you don’t know how many threads will be scheduled on the CPU before your code gets a chance to run again,let alone having any clue about their actual identities, do yo.

Basically, the only thing that you may possibly do is to get some unrelated chunks of binary data that you should never see. This is exactly the same thing like having the possibility to read some binary data from the file without having any idea about the actual structure of this data. As long as you have no chance to make a guess about interpretation of this binary data, a mere possibility of seeing it does not really seem to pose a significant security risk, does it.

Certainly it would be better if you never get a chance to see this data in the first place, but still it does not seem to be worth all the fuss, panic and FUD that we have recently encountered…

Anton Bassov

10

Correct Anton.

Sure it can be done in the lab, but it is essentially a contrived problem.