To summarize:<div><br></div><div>- CPython may be vulnerable to speculative execution vulnerabilities, but none are known.</div><div>- In general, CPython is currently too slow for speculative execution exploitation to be practical.</div><div> - Sandboxed, JIT'ed JS is not too slow for speculative execution exploitation to be practical</div><div> - (Not otherwise discussed here: PyPy's sandboxed JIT may not be too slow for speculative execution exploitation to be practical.)</div><div><br></div><div>- 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)</div><div> - 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</div><div><br></div><div>- Linux kernels with [IBRS, STIBP, IBPB] can enable userspace protection</div><div>- The revised worst-case performance impacts for variant 2 mitigations are 4-8%</div><div><br></div><div>- MSVC has a /Qspectre flag for variant 1</div><div><br></div><div>- Because there is no exploit provided (or currently thought possible with just CPython), this security-related dialogue is regarded as a nuisance.</div><div>- There is no published or official statement or investigation from the Python community regarding Spectre (or Meltdown) vulnerabilities.</div><div><br></div><div>Here's a good write-up:</div><div>Safety_instructions_for_Meltdown_and_Spectre</div><div><br></div><div>Have a good day!<br><br>On Monday, September 17, 2018, Steve Dower <<a href="mailto:steve.dower@python.org">steve.dower@python.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 17Sep2018 1158, Wes Turner wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Monday, September 17, 2018, Steve Dower <<a href="mailto:steve.dower@python.org" target="_blank">steve.dower@python.org</a> <mailto:<a href="mailto:steve.dower@python.org" target="_blank">steve.dower@python.org</a><wbr>>> wrote:<br>
<br>
I investigated this thoroughly some time ago (when the MSVC flags<br>
became available) and determined (with the help of some of the<br>
original Spectre/Meltdown investigation team) that there is no<br>
significant value in enabling these flags for Python.<br>
<br>
What did you fuzz with?<br>
Does that assume that e.g. Fortify has identified all bugs in CPython C?<br>
There have been a number of variants that have been disclosed; which did who test for?<br>
</blockquote>
<br>
Don't change the subject.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It boiled down to:<br>
* Python allows arbitrary code execution by design<br>
<br>
Yet binaries built with GCC do have NX? Unless nested functions in C extensions?<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Pure Python code in CPython has very long per-instruction opcode<br>
sequences that cannot easily be abused or timed<br>
<br>
A demonstration of this would be helpful.<br>
</blockquote>
<br>
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.<br>
<br>
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).<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Injected pure Python code cannot be coerced into generating native<br>
code that is able to abuse Spectre/Meltdown but not able to abuse<br>
other attacks more easily<br>
<br>
So, not impossible.<br>
</blockquote>
<br>
Of course it's not impossible. But why would you<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Code injection itself is outside of this particular threat model<br>
<br>
[Jupyter] Notebook servers are as wide open to arbitrary code execution as browser JS JITs; often with VMs and/or containers as a 'sandbox'<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
`pip install requirements.txt` installs and executes unsigned code: Python, C extensions<br>
<br>
What can a container do to contain a speculative execution exploit intending to escape said container?<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
By comparison with JavaScript, most JS JITs can be easily coerced<br>
into generating specific native code that can break sandbox<br>
guarantees (e.g. browser tabs). Python offers none of these guarantees.<br>
<br>
<br>
This is faulty logic. Because Python does not have a JIT sandbox, speculative execution is not a factor for Python?<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Distributors are of course free to enable these flags for their own<br>
builds, but I recommend against it for the official binaries, and<br>
would suggest that it's worth more PR than actual security and<br>
nobody else needs to enable it either.<br>
<br>
(Extension authors with significant scriptable C code need to<br>
perform their own analysis. I'm only talking about CPython here.)<br>
<br>
<br>
Extension installers (and authors) are not likely to perform any such analysis.<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Extensions are composed of arbitrary C, which certainly can both directly exploit and indirectly enable remote exploitation of Spectre and Meltdown vulnerabilities.<br>
</blockquote>
<br>
If arbitrary C is running, we can't help you anymore.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Most users of python are installing arbitrary packages (without hashes or signatures).<br>
</blockquote>
<br>
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.<br>
<br>
Cheers,<br>
Steve<br>
</blockquote></div>