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

[Franklin? Lee]

On Thu, Sep 20, 2018 at 2:10 PM Wes Turner <wes.turner at gmail.com> wrote:
>
> On Thursday, September 20, 2018, Stefan Ring <stefanrin at gmail.com> wrote:
>>
>> On Tue, Sep 18, 2018 at 8:38 AM INADA Naoki <songofacandy at gmail.com> wrote:
>>
>> > I think this topic should split to two topics: (1) Guard Python
>> > process from Spectre/Meltdown
>> > attack from other process, (2) Prohibit Python code attack other
>> > processes by using
>> > Spectre/Meltdown.
>>
>> (3) Guard Python from performance degradation by overly aggressive
>> Spectre "mitigation".
>
>
> > Spectre has the potential of having a greater impact on cloud providers than Meltdown. Whereas Meltdown allows unauthorized applications to read from privileged memory to obtain sensitive data from processes running on the same cloud server, Spectre can allow malicious programs to induce a hypervisor to transmit the data to a guest system running on top of it.
> - Private SSL certs
> - Cached keys and passwords in non-zeroed RAM
> - [...]
>
> https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)

It's true that the attacks should worry cloud providers. Doesn't that
mean that companies like Amazon, Microsoft (Steve), and Docker should
have done analyses on CPython's vulnerability to these exploits?
Has/should/can anyone officially representing Python contact the
companies and ask them?

When I followed your quote to find the context, I found it uses, as
its source, a Forbes article. The source cited by THAT article is
Daniel Gruss, who was one of the researchers. Should someone from the
PSF contact the researchers? Steve says he spoke to some of them to
judge whether the proposed compiler flags would help, and decided
against it.

Absent of expert input, here's my non-expert take: That quote requires
an OS-level fix. A Python program without the proper permissions can't
do such things unless there is a vulnerability with the OS, and it is
extremely unlikely for anyone to update Python for Spectre but not
update the OS (and they'd be screwed in any case). And even if there
is a vulnerability in the OS, maybe the way to exploit it is by using
arbitrary Python execution (which you need before you can TRY to use
Spectre) on this Python interpreter. You can then write a new binary
file and run THAT, and it will be fast enough. That's not something
you can fix about CPython.

Also, (again with my understanding) the problem of Spectre and
Meltdown are that you can escape sandboxes and the like, such as the
user/kernel divide, or a software sandbox like that provided by a
JavaScript VM. For CPython to be "vulnerable" to these attacks, it
needs to have some kind of sandbox or protection to break out of.
Instead, we sometimes have sandboxes AROUND CPython (like Jupyter) or
WITHIN CPython. I don't see how it makes sense to talk about a sandbox
escape FOR CPython (yet).

Your original post linked to a discussion about Linux using those
build flags. Linux is a kernel, and has such protections that can be
bypassed, so it has something to worry about. Malicious code can be
native code, which (to my understanding) will be fast enough to
exploit the cache miss time. Here's Google's article about the
retpoline and why it helps:
https://support.google.com/faqs/answer/7625886

As of yet, you have quoted passages that have little relevance to
interpreter devs, especially non-JIT interpreters, and you have linked
to entire articles for non-experts with little relevance to
interpreter devs. This doesn't show that you have any better of an
understanding than I have, which is less than the understanding that
some of the Python devs have, and much less than what Steve has. In
short, it LOOKS like you don't know what you're talking about. If you
have a different and deeper understanding of the problem, then you
need to show it, and say why there is a problem for CPython
specifically. Or find someone who can do that for you.

> Here's one:
> https://github.com/Eugnis/spectre-attack/blob/master/Source.c
>
> Is this too slow in CPython with:
> - Coroutines (asyncio (tulip))
> - PyPy JIT *
> - Numba JIT *
> - C Extensions *
> - Cython *
>
> * Not anyone here's problem.

C extensions are obviously fast enough. I think most of the other
starred examples are fast enough, but it's probably more subtle than I
think and requires further analysis by their devs. I also think
there's something important I'm still missing about what's required
and what it can do.

I don't see what coroutines have to do with it. Coroutines are still
Python code, and they're subject to the GIL.