[Python-ideas] Executable space protection: NX bit,

Wes Turner wes.turner at gmail.com
Tue Sep 4 19:51:03 EDT 2018

What about ` -mindirect-branch=thunk -mindirect-branch-register `?

Thanks! Looks like NX is on by default

A quick search of the codebase doesn't find any mprotect() calls, so I'm
assuming it's just the compiler flags defaulting to NX on for the main

This answer helped me understand a bit more; I'll take a look at the issue
tracker as well:

> From all of this we conclude that on at least some recent versions of
Linux, the stacks (main and threads) will usually be marked as
non-executable (i.e. NX bit set). However, if the executable code of the
application, or some executable code somewhere in a DLL loaded by the
application, contains a nested function or otherwise advertises a need for
an executable stack, then all stacks in the application will be marked as
executable (i.e. NX bit not set). In other words, a single loadable plugin
or extension for an application may deactivate NX stack protection for all
threads of the applications, simply by using a rarely used but legitimate
and documented feature of GCC.

> There is no need to panic, though, because, as @tylerl points out,
protection afforded by the NX bit is not that great. It will make some
exploits more awkward for the least competent of attackers; but good
attackers will not be impeded.


So, a C extension with a nested function (e.g. a trampoline) causes the NX
bit to be off?

retpoline is a trampoline approach *partially mitigating* the Spectre (but
not Meltdown?) vulns, right?


"What is a retpoline and how does it work?"


> mindirect-branch=thunk -mindirect-branch-register

Here's a helpful table of the 'Speculative execution exploit variants'
discovered as of yet:

Everything built - including the kernel - needs to be recompiled with new
thunk switches, AFAIU? How can we tell whether a python binary or C
extension has been rebuilt with which appropriate compiler flags?

On Tuesday, September 4, 2018, Mark E. Haase <mehaase at gmail.com> wrote:

> Hey Wes, the checksec() function in PEDA that you cited has a standalone
> version as well:
> https://github.com/slimm609/checksec.sh
> Running this on my Python (installed from Ubuntu package):
> $ checksec --output json -f /usr/bin/python3.6 | python3 -m json.tool
> {
>     "file": {
>         "relro": "partial",
>         "canary": "yes",
>         "nx": "yes",
>         "pie": "no",
>         "rpath": "no",
>         "runpath": "no",
>         "fortify_source": "yes",
>         "fortified": "17",
>         "fortify-able": "41",
>         "filename": "/usr/bin/python3.6"
>     }
> }
> My Python has pretty typical security mitigations. Most of these features
> are determined at compile time, so you can try compiling Python yourself
> with different compiler flags and see what other configurations are
> possible. Some mitigations hurt performance and others may be incompatible
> with Python itself. If you search on bugs.python.org you'll find a few
> different issues on these topics.
> On Mon, Sep 3, 2018 at 3:01 AM Wes Turner <wes.turner at gmail.com> wrote:
>> Rationale
>> =========
>> - Separation of executable code and non-executable data is a good thing.
>> - Additional security in Python is a good idea.
>> - Python should support things like the NX bit to separate code and
>> non-executable data.
>> Discussion
>> ==========
>> How could Python implement support for the NX bit? (And/or additional
>> modern security measures; as appropriate).
>> What sort of an API would C extensions need?
>> Would this be easier in PyPy or in CPython?
>> - https://en.wikipedia.org/wiki/NX_bit
>> - https://en.wikipedia.org/wiki/Executable_space_protection
>> Here's one way to identify whether an executable supports NX:
>> https://github.com/longld/peda/blob/e0eb0af4bcf3ee/peda.py#L2543
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180904/29cbceff/attachment.html>

More information about the Python-ideas mailing list