Portage 2.1.8.3 (default/linux/x86/10.0, gcc-4.5.0-asneeded, glibc-2.11.1-r0, 2.6.33.3 i686) ================================================================= System uname: Linux-2.6.33.3-i686-Quad-Core_AMD_Opteron-tm-_Processor_2350-with-gentoo-2.0.1 Timestamp of tree: Tue, 04 May 2010 11:30:01 +0000 app-shells/bash: 4.1_p5 dev-java/java-config: 2.1.11 dev-lang/python: 2.6.5-r2, 3.1.2-r3 dev-python/pycrypto: 2.1.0 dev-util/cmake: 2.8.1-r1 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.1-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.4_p6-r1, 1.5-r1, 1.6.3-r1, 1.7.9-r2, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1 sys-devel/gcc: 4.5.0 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.33 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /var/lib/hsqldb /var/qmail/alias /var/qmail/control /var/yp/Makefile" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -pipe" DISTDIR="/var/cache/distfiles" FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms split-log strict test test-fail-continue unmerge-orphans userfetch userpriv usersandbox" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://ftp.uni-erlangen.de/pub/mirrors/gentoo" LANG="en_US.utf8" LDFLAGS="-Wl,-O1" MAKEOPTS="-j14" PKGDIR="/var/spool/portage/packages" PORTAGE_COMPRESS="" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/cache/portage/tree-tinderbox" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl berkdb bzip2 cli cracklib crypt cups cxx dri fortran gdbm gpm iconv ipv6 java5 java6 modules mudflap ncurses nls nostatic nptl nptlonly openmp pam pcre perl pppd python qt3support readline reflection ruby session spl ssl sysfs tcpd unicode vhosts x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias auth_digest" ELIBC="glibc" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18 jruby ruby19" USERLAND="GNU" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Created attachment 230517 [details] Build log
It looks like adding -D_FORTIFY_SOURCE in the CFLAGS make the build successful, even if I don't really grab what does it means... I will attach the patch/new ebuild after having more testing done.
Created attachment 244951 [details, diff] bigloo-3.3a_p5-gcc45_fortify.patch Here it is. This patch create a new file in the Bigloo autoconf directory. It needs then to be executable. Here comes a sample ebuild addition: # Fix for bug 318661 epatch "${FILESDIR}/${P}-gcc45_fortify.patch" # as the patch add a new autoconf test, make it executable chmod +x "${S}/autoconf/ccfortify" I'm planning to commit that patch upstream. Dunno when yet.
Patch applied upstream for releases >=3.4b.
Erm... is bigloo now trying to ignore -D_FORTIFY_SOURCE=2 and thus proceeding with a possibly vulnerable code execution? Really this is _not_ the correct fix, try to debug what is causing __fortify_fail to be called, it's likely an out-of-bound access… maybe hardened team can give us a hand here?
(In reply to comment #5) > Erm... is bigloo now trying to ignore -D_FORTIFY_SOURCE=2 and thus proceeding > with a possibly vulnerable code execution? Yes, it lowers the fortify_level to 1 at configure time. > Really this is _not_ the correct fix, try to debug what is causing > __fortify_fail to be called, it's likely an out-of-bound access… maybe > hardened team can give us a hand here? I shortly talked with upstream about that issue, and we didn't give any deep attention to it. There is not a lot of documentation about that feature, apart from the announcement on the gcc list archive (There should be a page somewhere in the Gentoo website about FORTIFY_SOURCE, on either the hardened or QA project' pages, as for -as-needed) As far as I know, FORTIFY_SOURCE=2 is set internally in gentoo's gcc for a while, and the abort only occurs since gcc-4.5. Why? What are the changes on FORTIFY in 4.5.x? My current debug trace show me that the failure comes in Bigloo's (pwd) built-in, which calls getcwd with a freshly allocated string of size 1024, and 1024 for the size. It seems that either the string allocation is wrong, or the call to getcwd is. string_t type is defined in workdir/bigloo/runtime/Include/bigloo.h The C code of (pwd) is in workdir/bigloo/runtime/objs/obj_{s,u}/Llib/os.c BGl_pwdz00zz__osz00 The string allocation is done in workdir/bigloo/runtime/Clib/cstring.c make_string I'm trying to write a small C file reproducing the abort
Created attachment 246809 [details] testcase for x86_64 Test case reproducing the failure, the command-line used to compile: gcc -O2 -pipe -D_FORTIFY_SOURCE=2 -I/usr/lib/bigloo/3.4b fortify-test.c -L/usr/lib/bigloo/3.4b -L/usr/lib -lbigloo_s-3.4b -lgc -ldl -lm -lgmp -ldl -o fortify-test It requires a bigloo available, tested it against the last bigloo beta available from the Lisp overlay. The printf added in my_get_cwd prints "__bos(c_buf)=1", which explains the failure (and actually, a warning is printed at compile-time) The bigloo string representation seems to be the cause, it use the first char of a string in the string_t structure (char0), instead of the address of this first char (which is obtained from &char0). Is this *that* bad?
Created attachment 247472 [details, diff] bigloo-3.3a_p5-gcc45_fortify.patch Backport of upstream changes made in bigloo's trunk
Vulnerable 3.3a version has been removed from the tree, and replaced with 3.4b that already solves this issue.
