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