Bug 136619 – Stack-smash in PyCrypto

• Product: Gentoo Linux
• Status: RESOLVED CANTFIX

[Description Noah K 2006-06-13 01:00:28 UTC]

After upgrading to Portage 2.1, I found emerge failing with "python: stack smashing attack in function sha_done()".

Because pycrypto uses SHA for its own digests, I was initially unable to remerge it with new CFLAGS, though at the suggestion of someone in #gentoo-portage I got it working by using FEATURES="-strict". The current emerge --info is as follows:

Portage 2.1 (default-linux/x86/2006.0, gcc-3.4.5, glibc-2.3.6-r3, 2.6.14-gentoo-r2 i686)
=================================================================
System uname: 2.6.14-gentoo-r2 i686 Pentium III (Coppermine)
Gentoo Base System version 1.6.14
dev-lang/python:     2.2.3-r5, 2.3.5, 2.4.2
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/gcc-config: 1.3.13-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.4.19, 2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=pentium3 -O3 -pipe" (This previously had -fstack-protector as well)
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/terminfo"
CXXFLAGS="-march=pentium3 -O3 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://mirrors.acm.cs.rpi.edu/gentoo http://gentoo.oregonstate.edu/ http://www.ibiblio.org/pub/Linux/distributions/gentoo"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://acm.cs.rpi.edu/gentoo-portage"
USE="x86 apache2 apm avi berkdb bitmap-fonts cdr cli crypt dri eds emboss esd fortran gdbm gif gpm imlib ipv6 isdnlog jpeg kerberos ldap libg++ libwww mad mikmod motif mp3 mpeg ncurses nis nptl ogg opengl pam pcre perl png pppd python quicktime readline reflection sdl session spl ssl tcpd truetype-fonts type1-fonts udev vorbis xml xmms xorg xv zlib elibc_glibc kernel_linux userland_GNU"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS

[Comment 1 solar (RETIRED) 2006-06-13 04:56:25 UTC]

-fstack-protector in CFLAGS is beyond the scope of hardened and is simply 
unsupported as it can lead to miscompiles of many things.
-O3 with fstack-protector is even more not supported and documented.

python team: suggestion to mark this bug as INVALID, CANTFIX

[Comment 2 Noah K 2006-06-13 05:06:18 UTC]

This problem is already referenced in the current ebuild, the protections just don't seem to actually work. If nothing else the package should just refuse to build to prevent people from getting into the chicken-and-egg situation described above.

[Comment 3 Marien Zwart (RETIRED) 2006-06-13 11:12:38 UTC]

The protections in there are triggered if you're running a hardened compiler. You are not running a hardened compiler: you're passing an unsupported CFLAG instead. As solar says you will probably hit problems with more than just pycrypto if you do this. Recommend you switch to the supported way of stack smash protection (hardened compiler profile) and reopen this if it still fails with a supported compiler/CFLAGS combination. See also the hardened faq, specifically http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#hardenedcflags.