[Python-Dev] SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register

[Steve Dower]

On 17Sep2018 1158, Wes Turner wrote:
> On Monday, September 17, 2018, Steve Dower <steve.dower at python.org 
> <mailto:steve.dower at python.org>> wrote:
> 
>     I investigated this thoroughly some time ago (when the MSVC flags
>     became available) and determined (with the help of some of the
>     original Spectre/Meltdown investigation team) that there is no
>     significant value in enabling these flags for Python.
> 
> What did you fuzz with?
> Does that assume that e.g. Fortify has identified all bugs in CPython C?
> There have been a number of variants that have been disclosed; which did 
> who test for?

Don't change the subject.

>     It boiled down to:
>     * Python allows arbitrary code execution by design
> 
> Yet binaries built with GCC do have NX? Unless nested functions in C 
> extensions?

I don't know anything about GCC settings. Binaries for Windows have been 
built with this option for over a decade. It's unrelated to 
Spectre/Meltdown.

>     * Pure Python code in CPython has very long per-instruction opcode
>     sequences that cannot easily be abused or timed
> 
> A demonstration of this would be helpful.

That's not how proof-of-concepts work. You can't assume that the lack of 
a demonstration proves it is possible - at best you have to assume that 
it proves it is *not* possible, but really it just proves that nobody 
has a demonstration yet.

What I could demonstrate (again) if I thought it would be worthwhile is 
that the changes enabled by the flag do not affect the normal 
interpreter loop, and do not affect any code that can be called fast 
enough to potentially leak information. Feel free to go ahead and build 
with/without the flags and compare the disassembly (and if you do this 
and find that compilers are detecting new cases since I looked, *that* 
would be very helpful to share directly with the security team).

>     * Injected pure Python code cannot be coerced into generating native
>     code that is able to abuse Spectre/Meltdown but not able to abuse
>     other attacks more easily
> 
>   So, not impossible.

Of course it's not impossible. But why would you

>     * Code injection itself is outside of this particular threat model
> 
> [Jupyter] Notebook servers are as wide open to arbitrary code execution 
> as browser JS JITs; often with VMs and/or containers as a 'sandbox'

> `pip install requirements.txt` installs and executes unsigned code: 
> Python, C extensions
> 
> What can a container do to contain a speculative execution exploit 
> intending to escape said container?

Python's threat model does not treat the Python process as a sandbox. To 
say it another way, if you assume the Python process is a sandbox, 
you're on your own.

Arbitrary code, Python or otherwise, can totally escape the process, and 
then it's up to the OS to protect against escaping the machine. We do 
what we can to reduce unnecessary arbitrary code, but unless you've 
properly protected your environment then you have a lot more to worry 
about besides speculative execution vulnerabilities.

>     By comparison with JavaScript, most JS JITs can be easily coerced
>     into generating specific native code that can break sandbox
>     guarantees (e.g. browser tabs). Python offers none of these guarantees.
> 
> 
> This is faulty logic. Because Python does not have a JIT sandbox, 
> speculative execution is not a factor for Python?

Because Python does not have a (native) JIT at all, speculative 
execution relies on identifying vulnerable and reusable code patterns 
within the C code and being able to invoke those directly. Because pure 
Python code does not allow this (without relying on other bugs), there 
is no way to do this within the threat model we use.

Once you allow arbitrary or unvalidated native code, you are outside the 
threat model and hence on your own. And if you find a bug that lets pure 
Python code move the instruction pointer to arbitrary native code, that 
should be reported to the security team.

>     Distributors are of course free to enable these flags for their own
>     builds, but I recommend against it for the official binaries, and
>     would suggest that it's worth more PR than actual security and
>     nobody else needs to enable it either.
> 
>     (Extension authors with significant scriptable C code need to
>     perform their own analysis. I'm only talking about CPython here.)
> 
> 
> Extension installers (and authors) are not likely to perform any such 
> analysis.

Then it is their fault if they are compromised. Open source software 
relies on users validating the software themselves, as there is no legal 
recourse against developers who do not do it.

> Extensions are composed of arbitrary C, which certainly can both 
> directly exploit and indirectly enable remote exploitation of Spectre 
> and Meltdown vulnerabilities.

If arbitrary C is running, we can't help you anymore.

> Most users of python are installing arbitrary packages (without hashes 
> or signatures).

If they are concerned about Spectre/Meltdown, they should stop doing 
this. They should also stop if they are concerned about 1000 other 
issues that are much more likely than Spectre/Meltdown.

Cheers,
Steve