[Bug 1452115] Re: Python interpreter binary is not compiled as PIE

[Simon Déziel]

@alexmurray, totally random observation that is not related to this bug
but might save you/others some times. The following 4 steps:

# use a LXD VM for testing
lxc launch --vm images:ubuntu/jammy sec-jammy-amd64
# stop the VM and disable UEFI secure boot
lxc stop sec-jammy-amd64
# ensure secureboot is not used so we can use the msr module later
lxc config set set-jammy-amd64 security.secureboot=false
lxc start sec-jammy-amd64

Can be reduced to:

# use a LXD VM for testing, no secureboot to allow using the msr module later
lxc launch --vm images:ubuntu/jammy sec-jammy-amd64 -c security.secureboot=false

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, 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:
  Fix Released
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