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

[Franklin? Lee]

There is much reason to believe it won't help, and you have given little
reason to believe that it will help, or that you even properly understand
how the flag mitigates Spectre in programs where it does help.

I am not undermining your attempts for the sake of performance. I am trying
to help you understand why no one is taking you seriously, and suggesting
what you can do so that they will. One way is to explain why an unsandboxed
interpreter needs to protect against a sandbox escape.

On Sep 21, 2018 3:12 AM, "Wes Turner" <wes.turner at gmail.com> wrote:

I feel like you are actively undermining attempts to prevent exploitation
of known vulnerabilities because the software in question is currently too
slow.

For a 4-8% performance penalty, we could just add the CFLAGS to the build
now and not worry about it.

I give up.


On Friday, September 21, 2018, Franklin? Lee <leewangzhong+python at gmail.com>
wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180921/0642c950/attachment.html>