Thanks @Giovanni Pellerano for bumping this again. I can confirm that
this is an issue in python3.9 (3.9.7, "3.9.7-2build1") and python3.10
(3.10.0, "3.10.0-2") on 21.10 (amd64). I imagine if nothing is done, the
upcoming 22.04 LTS will have the issue in its default python(3), which I
imagine will be some version of 3.10.
# python3 --version
Python 3.9.7
# ./checksec --file=/usr/bin/python3
RELRO STACK CANARY NX PIE RPATH
RUNPATH Symbols FORTIFY Fortified Fortifiable FILE
Partial RELRO Canary found NX enabled No PIE No RPATH No
RUNPATH No Symbols Yes 14 39
/usr/bin/python3
# python3.10 --version
Python 3.10.0
# ./checksec --file=/usr/bin/python3.10
RELRO STACK CANARY NX PIE RPATH
RUNPATH Symbols FORTIFY Fortified Fortifiable FILE
Partial RELRO Canary found NX enabled No PIE No RPATH No
RUNPATH No Symbols Yes 14 39
/usr/bin/python3.10
Alternatively, via `hardening-check` from the devscripts package:
# hardening-check /usr/bin/python3
/usr/bin/python3:
Position Independent Executable: no, normal executable!
Stack protected: yes
Fortify Source functions: yes (some protected functions found)
Read-only relocations: yes
Immediate binding: no, not found!
Stack clash protection: unknown, no -fstack-clash-protection instructions found
Control flow integrity: yes
# hardening-check /usr/bin/python3.10
/usr/bin/python3.10:
Position Independent Executable: no, normal executable!
Stack protected: yes
Fortify Source functions: yes (some protected functions found)
Read-only relocations: yes
Immediate binding: no, not found!
Stack clash protection: unknown, no -fstack-clash-protection instructions found
Control flow integrity: yes
** Also affects: python3.9 (Ubuntu)
Importance: Undecided
Status: New
** Also affects: python3.10 (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python2.7 in Ubuntu.
https://bugs.launchpad.net/bugs/1452115
Title:
Python interpreter binary is not compiled as PIE
Status in Python:
New
Status in python2.7 package in Ubuntu:
Fix Released
Status in python3.10 package in Ubuntu:
New
Status in python3.4 package in Ubuntu:
Fix Released
Status in python3.6 package in Ubuntu:
Confirmed
Status in python3.7 package in Ubuntu:
Confirmed
Status in python3.8 package in Ubuntu:
Confirmed
Status in python3.9 package in Ubuntu:
New
Status in python3.7 package in Debian:
New
Status in python3.8 package in Debian:
New
Bug description:
The python2.7 binary (installed at /usr/bin/python2.7; package version
2.7.6-8) is not compiled as a position independent executable (PIE).
It appears that the python compilation process is somewhat arcane and
the hardening wrapper probably doesn't do the trick for it.
This is incredibly dangerous as it means that any vulnerability within
a native module (e.g. ctypes-based), or within python itself will
expose an incredibly large amount of known memory contents at known
addresses (including a large number of dangerous instruction
groupings). This enables ROP-based
(https://en.wikipedia.org/wiki/Return-oriented_programming) to abuse
the interpreter itself to bypass non-executable page protections.
I have put together an example vulnerable C shared object (with a buffer
overflow) accessed via python through the ctypes interface as an example. This
uses a single ROP "gadget" on top of using the known PLT location for system(3)
(https://en.wikipedia.org/wiki/Return-to-libc_attack) to call "id". The example
code is accessible at:
- https://gist.github.com/ChaosData/ae6076cb1c3cc7b0a367
I'm not exactly familiar enough with the python build process to say
where exactly an -fPIE needs to be injected into a script/makefile,
but I feel that given the perceived general preference for ctypes-
based modules over python written ones, as the native code
implementations tend to be more performant, this feels like a large
security hole within the system. Given the nature of this "issue," I'm
not 100% sure of where it is best reported, but from what I can tell,
this conflicts with the Ubuntu hardening features and is definitely
exploitable should a native module contain a sufficiently exploitable
vulnerability that allows for control of the instruction register.
To manage notifications about this bug go to:
https://bugs.launchpad.net/python/+bug/1452115/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
