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
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
|
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.
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.
$ 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
I think we should simply enable SSP an see if there are any issues while the package is in testing
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?
Setting CFLAGS to contain --param=ssp-buffer-size=1 /usr/bin/python3.7 does not contain the symbol __stack_chk_fail.
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