On 17Sep2018 1158, Wes Turner wrote:
On Monday, September 17, 2018, Steve Dower <steve.do...@python.org <mailto:steve.do...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to