To summarize:
- CPython may be vulnerable to speculative execution vulnerabilities, but
none are known.
- In general, CPython is currently too slow for speculative execution
exploitation to be practical.
- Sandboxed, JIT'ed JS is not too slow for speculative execution
exploitation to be practical
- (Not otherwise discussed here: PyPy's sandboxed JIT may not be too
slow for speculative execution exploitation to be practical.)
- C extensions may be vulnerable to speculative execution vulnerabilities;
but that's the authors' and users' problem (and so it's appropriate to
mention this to extension owners following distutils-sig/PyPA)
- C extensions can set indirect branch CFLAGS only with GCC 7.3 and GCC
8+; which are only usable with conda and the forthcoming manylinux2010 spec
- Linux kernels with [IBRS, STIBP, IBPB] can enable userspace protection
- The revised worst-case performance impacts for variant 2 mitigations are
4-8%
- MSVC has a /Qspectre flag for variant 1
- Because there is no exploit provided (or currently thought possible with
just CPython), this security-related dialogue is regarded as a nuisance.
- There is no published or official statement or investigation from the
Python community regarding Spectre (or Meltdown) vulnerabilities.
Here's a good write-up:
Safety_instructions_for_Meltdown_and_Spectre
Have a good day!
On Monday, September 17, 2018, Steve Dower <steve.do...@python.org> wrote:
> 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
