[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
stack.
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.
https://security.stackexchange.com/a/47825
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?
https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html
"What is a retpoline and how does it work?"
https://stackoverflow.com/a/48099456
https://github.com/speed47/spectre-meltdown-checker/issues/119
> mindirect-branch=thunk -mindirect-branch-register
Here's a helpful table of the 'Speculative execution exploit variants'
discovered as of yet:
https://en.wikipedia.org/wiki/Speculative_Store_Bypass#Speculative_execution_exploit_variants
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