libgcrypt11 has an executable stack

Bug #49192 reported by John Moser
4
Affects Status Importance Assigned to Milestone
libgcrypt11 (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: libgcrypt11

libgcrypt11 has an executable stack. This should probably be removed. This is doable in a variety of ways[1], but the easiest seems to be simply disabling the use of assembly code. This saves us the trouble of auditing it for actual code that wants an executable stack (as opposed to deciding it "looks like it works without it" and just taking it away and waiting to see if some obscure user breaks it in the future).

bluefox@icebox:~/gcrypt/libgcrypt11-1.2.2$ execstack -q /usr/lib/libgcrypt.so.11
X /usr/lib/libgcrypt.so.11

The DEB_CONFIGURE_EXTRA_FLAGS line can be added to debian/rules in the libgcrypt11 source package. The following block would then appear at the top of the file:

#DEB_CONFIGURE_EXTRA_FLAGS := --enable-maintainer-mode
DEB_DH_STRIP_ARGS = --dbg-package=libgcrypt11
DEB_DH_MAKESHLIBS_ARGS := -V 'libgcrypt11 (>=1.2.2)'
#Don't use inline assembly cruft
DEB_CONFIGURE_EXTRA_FLAGS := --disable-asm

bluefox@icebox:~/gcrypt/libgcrypt11-1.2.2$ execstack -q debian/libgcrypt11/usr/lib/libgcrypt.so.11
- debian/libgcrypt11/usr/lib/libgcrypt.so.11

Oddly enough...
bluefox@icebox:~/gcrypt/libgcrypt11-1.2.2$ ls -l debian/libgcrypt11/usr/lib/libgcrypt.so.11*
lrwxrwxrwx 1 bluefox bluefox 19 2006-06-09 17:39 debian/libgcrypt11/usr/lib/libgcrypt.so.11 -> libgcrypt.so.11.2.1
-rw-r--r-- 1 bluefox bluefox 310348 2006-06-09 17:39 debian/libgcrypt11/usr/lib/libgcrypt.so.11.2.1
bluefox@icebox:~/gcrypt/libgcrypt11-1.2.2$ ls -l /usr/lib/libgcrypt.so.11*
lrwxrwxrwx 1 root root 19 2006-05-22 17:53 /usr/lib/libgcrypt.so.11 -> libgcrypt.so.11.2.1
-rw-r--r-- 1 root root 310348 2005-10-28 05:16 /usr/lib/libgcrypt.so.11.2.1

The sha1sums are different, but the size is the same. Weird. *shrug*

This issue was discovered by attempting to boot a PaX kernel on Ubuntu. More explaination into the issue of executabel stacks can be found at the below URI.

[1] http://www.gentoo.org/proj/en/hardened/gnu-stack.xml

Revision history for this message
John Moser (nigelenki) wrote :

I have confirmed as well that this is the root cause of bug #34129, #34130, #34131, and #34132.

The following tasks also seem to have an executable stack for the following reasons (using a script that uses pax-utils[1]):

COMMAND: gnome-terminal (5294)
RWX --- --- /usr/lib/libgcrypt.so.11.2.1

COMMAND: gnome-session (5334)
RWX --- --- /usr/lib/libgcrypt.so.11.2.1

COMMAND: /usr/lib/control-center/gnome-settings-daemon (5339)
RWX --- --- /usr/lib/libgcrypt.so.11.2.1

COMMAND: /usr/lib/vino/vino-server (5341)
RWX --- --- /usr/lib/libgcrypt.so.11.2.1

COMMAND: gnome-panel (5353)
RWX --- --- /usr/lib/libgcrypt.so.11.2.1

COMMAND: nautilus (5355)
RWX --- --- /usr/lib/libgcrypt.so.11.2.1

COMMAND: gnome-volume-manager (5358)
RWX --- --- /usr/lib/libgcrypt.so.11.2.1

COMMAND: update-notifier (5362)
RWX --- --- /usr/lib/libgcrypt.so.11.2.1

COMMAND: /usr/lib/gnome-vfs-2.0/gnome-vfs-daemon (5367)
RWX --- --- /usr/lib/libgcrypt.so.11.2.1

COMMAND: /usr/lib/gnome-applets/trashapplet (5371)
RWX --- --- /usr/lib/libgcrypt.so.11.2.1

COMMAND: /usr/lib/gnome-applets/multiload-applet-2 (5401)
RWX --- --- /usr/lib/libgcrypt.so.11.2.1

COMMAND: /usr/lib/gnome-applets/mixer_applet2 (5403)
RWX --- --- /usr/lib/libgcrypt.so.11.2.1

COMMAND: /usr/lib/gnome-applets/gtik2_applet2 (5405)
RWX --- --- /usr/lib/libgcrypt.so.11.2.1

COMMAND: gnome-cups-icon (5412)
RWX --- --- /usr/lib/libgcrypt.so.11.2.1

COMMAND: /usr/lib/gnome-panel/clock-applet (5417)
RWX --- --- /usr/lib/libgcrypt.so.11.2.1

COMMAND: xchat-gnome (5426)
RWX --- --- /usr/lib/libgcrypt.so.11.2.1

COMMAND: /usr/lib/firefox/firefox-bin (5549)
 TEXTREL /home/bluefox/.mozilla/plugins/libflashplayer.so
RWX --- --- /usr/lib/libgcrypt.so.11.2.1

COMMAND: rhythmbox (14659)
 TEXTREL /usr/lib/gstreamer-0.10/libgstffmpeg.so
RWX --- --- /usr/lib/libFLAC.so.7.0.0
RWX --- --- /usr/lib/libgcrypt.so.11.2.1

Fixing libgcrypt fixes a lot. :)

[1] http://www.gentoo.org/proj/en/hardened/pax-utils.xml

Revision history for this message
John Moser (nigelenki) wrote :

The patching fix is as follows:

Append the following four lines:

/* Add these three lines to get us a PT_GNU_STACK header */
#ifdef __ELF__
.section .note.GNU-stack,"",%progbits
#endif

To all *.S source files. Use the below script:

e="/* Add these three lines to get us a PT_GNU_STACK header */
#ifdef __ELF__
.section .note.GNU-stack,\"\",%progbits
#endif"
for i in `find . -name \*.S`; do echo "$e" >> "$i"; done

Submit resulting changes upstream when finished and well tested, cite Ubuntu mainline as example.

Test data used:

bluefox@icebox:/tmp/x/libgcrypt11-1.2.2$ scanelf -qeRt .
RWX --- --- ./debian/tmp/usr/lib/libgcrypt.so.11.2.1
RWX --- --- ./debian/libgcrypt11/usr/lib/libgcrypt.so.11.2.1
RWX --- --- ./debian/libgcrypt11-dbg/usr/lib/debug/usr/lib/libgcrypt.so.11.2.1
!WX --- --- ./mpi/mpih-rshift.o
!WX --- --- ./mpi/mpih-lshift.o
!WX --- --- ./mpi/mpih-mul3.o
!WX --- --- ./mpi/mpih-mul2.o
!WX --- --- ./mpi/mpih-mul1.o
!WX --- --- ./mpi/mpih-sub1.o
!WX --- --- ./mpi/mpih-add1.o

Result after fix:
bluefox@icebox:/tmp/x/libgcrypt11-1.2.2$ scanelf -qeRt . bluefox@icebox:/tmp/x/libgcrypt11-1.2.2$

Revision history for this message
John Moser (nigelenki) wrote :

I have reported the bug to upstream, with the proper assembly fixes. Their initial response said to use --enable-noexecstack, which adds -Wa,noexecstack to the compile flags; I have stressed the importance of patching the assembly files directly (which is more portable), no idea if they're going to take it.

Revision history for this message
Brandon Hale (brandon) wrote :

Closing per reporter on IRC.

Changed in libgcrypt11:
status: Unconfirmed → Fix Released
Revision history for this message
John Moser (nigelenki) wrote :

Fix released for Edgy a while ago, but none for dapper, so I've attached a debdiff between libgcrypt11_1.2.2-1 and libgcrypt11_1.2.2-1.1, with 1.1 adding a non-executable stack.

This is marked for dapper-updates. It helps security, but does not fix any vulnerability. It helps security on both x86-64 and i386 with NX bit, probably on every other platform capable of enforcing PROT_EXEC properly as well.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.