FS#43246 - [python] [python2] python interpreters missing SSP exploit mitigation

Attached to Project: Arch Linux
Opened by Daniel Micay (thestinger) - Saturday, 27 December 2014, 03:35 GMT
Last edited by Eli Schwartz (eschwartz) - Friday, 25 January 2019, 00:35 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Felix Yan (felixonmars)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

This can be confirmed with `checksec --file` on the executables. It can be solved either by modifying the build system to respect our CFLAGS or by adding makedepends=(hardening-wrapper).
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Friday, 25 January 2019, 00:35 GMT
Reason for closing:  Not a bug
Additional comments about closing:  There isn't actually anything wrong, it seems.
Comment by Daniel Micay (thestinger) - Saturday, 27 December 2014, 03:38 GMT
SSP == -fstack-protector-strong stack canaries
Comment by Felix Yan (felixonmars) - Sunday, 28 December 2014, 12:30 GMT
Adding hardening-wrapper to makedepends doesn't seem to solve the problem as far as I have tested:

$ checksec --file /usr/bin/python2.7
RELRO STACK CANARY NX PIE RPATH RUNPATH FILE
Partial RELRO No canary found NX enabled PIE enabled No RPATH No RUNPATH /usr/bin/python2.7
Comment by Daniel Micay (thestinger) - Sunday, 28 December 2014, 19:12 GMT
@felixonmars: Strange. I also ran into this with imagemagick/graphicsmagick so I held off on reporting those. It might be a GCC bug because there are certainly functions with arrays and -fstack-protector-strong is supposed to add a canary check to each one.
Comment by Daniel Micay (thestinger) - Sunday, 28 December 2014, 19:17 GMT
I'll investigate this more.
Comment by Jelle van der Waa (jelly) - Saturday, 05 January 2019, 16:57 GMT
From IRC, Debian has it working, Fedora doesn't. Debian's rules file https://salsa.debian.org/gregprice-guest/python3/blob/master/debian/rules
Comment by johnsen (johnsen) - Tuesday, 15 January 2019, 19:51 GMT
Any update on this?
Comment by Jelle van der Waa (jelly) - Wednesday, 16 January 2019, 12:24 GMT
Not from me, haven't figured out why SSP seems to be stripped.
Comment by johnsen (johnsen) - Monday, 21 January 2019, 18:42 GMT
@thestinger: Since you investigate the issue, can you provide an update un this?

I think we should simply enable SSP an see if there are any issues while the package is in testing
Comment by loqs (loqs) - Tuesday, 22 January 2019, 02:47 GMT
Looking at /usr/bin/python3.7 from python3.7-minimal_3.7.2-1_amd64.deb it does not link to /usr/lib/libpython3.7m.so.1.0 it does contain the symbol __stack_chk_fail.
On arch python3.7 is linked to /usr/lib/libpython3.7m.so.1.0 which contains __stack_chk_fail.
Does the binary itself need to provide the symbol to be protected by SSP?
Comment by loqs (loqs) - Tuesday, 22 January 2019, 12:40 GMT
Setting CFLAGS to contain -fstack-protector-all /usr/bin/python3.7 contains the symbol __stack_chk_fail.
Setting CFLAGS to contain --param=ssp-buffer-size=1 /usr/bin/python3.7 does not contain the symbol __stack_chk_fail.
Comment by Levente Polyak (anthraxx) - Tuesday, 22 January 2019, 14:30 GMT
it does work, there is just nothing worth including stack canaries.
the binary, when dyn-linked to libpython3.7m.so.1.0 doesn't contain any real functions (its 7B in size)
especially nothing with stack buffer allocation that matches the rules for inclusion when using -fstack-protector-strong

this is a false negative

Loading...