For posterity - this is how I did the analysis above: # download the current python3.9 source package and rebuild it with PIE enabled apt source python3.9 cd python3.9-3.9.10/ sed -i "/export DEB_BUILD_MAINT_OPTIONS=hardening=-pie/d" debian/rules dch -i -D jammy "Enable PIE (LP: #1452115)" update-maintainer # sbuild assumes you already have a jammy-amd64 schroot setup sbuild
# 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 # make sure VM has full disk allocated lxc exec sec-jammy-amd64 -- growpart /dev/sda 2 lxc exec sec-jammy-amd64 -- resize2fs /dev/sda2 lxc file push ../*.deb sec-jammy-amd64/root/ lxc shell sec-jammy-amd64 # then inside the LXD VM install and run pyperformance with and without the new python3.9 apt install python3-pip pip3 install pyperformance # tune for system performance modprobe msr python3.9 -m pyperf system tune # get baseline numbers without PIE pyperformance run --python=/usr/bin/python3.9 -o py3.9.json # install our debs we built above that have PIE enabled apt install ./python3.9_3.9.10-2ubuntu1_amd64.deb ./libpython3.9-stdlib_3.9.10-2ubuntu1_amd64.deb ./python3.9-minimal_3.9.10-2ubuntu1_amd64.deb ./libpython3.9-minimal_3.9.10-2ubuntu1_amd64.deb ./libpython3.9_3.9.10-2ubuntu1_amd64.deb ./libpython3.9-dev_3.9.10-2ubuntu1_amd64.deb ./python3.9-dev_3.9.10-2ubuntu1_amd64.deb # check they have PIE apt install devscripts hardening-check /usr/bin/python3.9 # re-run pyperformance with PIE pyperformance run --python=/usr/bin/python3.9 -o py3.9-pie.json # and compare the results python3 -m pyperf compare_to py3.9.json py3.9-pie.json --table -- 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
