strip segfaults on dietlibc-built executables

Bug #254790 reported by Mark Seaborn
8
Affects Status Importance Assigned to Milestone
binutils
Fix Released
Medium
binutils (Ubuntu)
Fix Released
Medium
Unassigned
Nominated for Intrepid by Mark Seaborn

Bug Description

Binary package hint: dietlibc

On Ubuntu intrepid on amd64, executables built with dietlibc can cause strip to segfault:

$ cat test.c
#include <stdio.h>
int main() { fprintf(stderr, "hello\n"); return 0; }
$ diet gcc test.c -o test
/usr/lib/diet/lib-x86_64/libc.a(stderr.o): In function `__fflush_stderr':
stderr.c:(.text+0x8): warning: warning: your code uses stdio (7+k bloat).
$ objdump -p test

test: file format elf64-x86-64

Program Header:
    LOAD off 0x0000000000000000 vaddr 0x0000000000400000 paddr 0x0000000000400000 align 2**21
         filesz 0x0000000000000930 memsz 0x0000000000000930 flags r-x
    LOAD off 0x0000000000000ff0 vaddr 0x0000000000600ff0 paddr 0x0000000000600ff0 align 2**21
         filesz 0x0000000000000118 memsz 0x0000000000001290 flags rw-
   STACK off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**3
         filesz 0x0000000000000000 memsz 0x0000000000000000 flags rwx
   RELRO off 0x0000000000000ff0 vaddr 0x0000000000600ff0 paddr 0x0000000000600ff0 align 2**0
         filesz 0x0000000000000010 memsz 0x0000000000000010 flags r--

$ ./test
hello
$ strip test
Segmentation fault (core dumped)

$ dpkg -s dietlibc-dev | grep ^Version
Version: 0.31-1ubuntu3
$ dpkg -s binutils | grep ^Version
Version: 2.18.50.20080707-0ubuntu1

I am not sure if the presence of the RELRO segment is correct, because I don't think it has appeared in the i386 version of the executable or in dietlibc executables built on earlier versions of Ubuntu.

Revision history for this message
Mark Seaborn (mrs) wrote :

This change to gcc may be relevant:

gcc-4.3 (4.3.0-3ubuntu5) intrepid; urgency=low
  * debian/rules.patch: add security hardening compiler options:
    - gcc-relro-default: use -Wl,-z,relro by default.
    - gcc-format-security-default: use -Wformat -Wformat-security by default.
    - gcc-fortify-source-default: use -D_FORTIFY_SOURCE=2 by default.
 -- Kees Cook < <email address hidden>> Thu, 01 May 2008 15:04:12 -0700

Revision history for this message
Mark Seaborn (mrs) wrote :

It looks like this problem was encountered before with matrixssl (which uses dietlibc) given the following changelog:

matrixssl (1.8.5-1ubuntu1) intrepid; urgency=low
  * Add -Wl,-z,norelro to LDFLAGS, fix FTBFS while stripping binaries on
    i386 and amd64 architectures (Ubuntu toolchain issue only).
 -- Luca Falavigna < <email address hidden>> Fri, 25 Jul 2008 13:16:13 +0200

Revision history for this message
Mark Seaborn (mrs) wrote :

This problem causes dietlibc-dev to fail to build from source on Ubuntu intrepid on amd64 with the following error:

gcc -D__dietlibc__ -isystem include -Os -fstrict-aliasing -momit-leaf-frame-pointer -mfancy-math-387 -Wall -W -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wno-switch -Wno-unused -Wredundant-decls -nostdlib -o bin-x86_64/diet bin-x86_64/start.o bin-x86_64/dyn_start.o diet.c bin-x86_64/dietlibc.a bin-x86_64/dyn_stop.o -DDIETHOME=\"/work/dietlibc-0.31\" -DVERSION=\"0.31-1ubuntu3\" -lgcc
strip -R .comment -R .note bin-x86_64/diet
make[1]: *** [bin-x86_64/diet] Segmentation fault (core dumped)
make[1]: *** Deleting file `bin-x86_64/diet'
make[1]: Leaving directory `/work/dietlibc-0.31'
make: *** [build-stamp] Error 2

Attached is a patch to fix this by adding the -Wl,-z,norelro option.

Revision history for this message
Mark Seaborn (mrs) wrote :

The previous patch fixes the FTBFS but is not enough to fix the original problem. The following patch changes the "diet" wrapper to add -Wl,-z,norelro as well.

Revision history for this message
In , Andreas Schwab (schwab-linux-m68k) wrote :

This is broken since PT_GNU_RELRO has been added in 2004.

Starting program: /tmp/test/test/binutils/strip-new test

Program received signal SIGSEGV, Segmentation fault.
0x40000000000ac441 in _bfd_elf_compute_section_file_positions (
    abfd=0x6000000000022e70, link_info=0x0) at ../../binutils/bfd/elf.c:4706
4706 if (lp->p_type == PT_LOAD

Revision history for this message
In , Andreas Schwab (schwab-linux-m68k) wrote :

Created attachment 3045
Testcase

Revision history for this message
In , Andreas Schwab (schwab-linux-m68k) wrote :

Fixed.

Revision history for this message
Luca Falavigna (dktrkranz) wrote :

Could you please try it on Jaunty too. I'm unable to reproduce it.

Changed in dietlibc:
status: New → Incomplete
Revision history for this message
Mark Seaborn (mrs) wrote :

I can still reproduce the problem: it happens just as I described in the original report in a freshly-built amd64 jaunty chroot. Are you testing this on amd64? What output do you get from objdump?

Is there any reason you'd expect the problem to have gone away? dietlibc has not been changed since Ubuntu hardy but gcc presumably still adds the -Wl,-z,relro option. As far as I can remember, this option is not applicable to static executables. Maybe it could be considered a linker bug that it does not ignore the option when producing a static executable.

Revision history for this message
Luca Falavigna (dktrkranz) wrote :

My fault, I am now able to reproduce it. I'll conduct some tests to see if this can be applied safely, dietlibc has several rdepends and they need to be checked carefully. Thanks!

Changed in dietlibc:
assignee: nobody → dktrkranz
importance: Undecided → Medium
status: Incomplete → Triaged
Revision history for this message
Luca Falavigna (dktrkranz) wrote :
Revision history for this message
Luca Falavigna (dktrkranz) wrote :
Changed in dietlibc:
assignee: dktrkranz → nobody
Revision history for this message
Mark Seaborn (mseaborn-cmedresearch) wrote :

Yes. That binutils fix was under this bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=7011
(no mention of steps to reproduce though)
I also raised a bug on binutils myself:
http://sourceware.org/bugzilla/show_bug.cgi?id=7076
They are probably the same problem.

However, including a RELRO segment should not have any benefit for static executables because they are interpreted by the dynamic linker. See <http://www.airs.com/blog/archives/189> and <http://www.gentoo.org/proj/en/hardened/hardened-toolchain.xml#RELRO>.

Changed in binutils:
status: Unknown → Fix Released
Revision history for this message
In , Matthias Klose (doko) wrote :

please could you consider the fix for the 2.19 branch as well?

Revision history for this message
In , Cvs-commit (cvs-commit) wrote :

Subject: Bug 7011

CVSROOT: /cvs/src
Module name: src
Branch: binutils-2_19-branch
Changes by: <email address hidden> 2008-12-23 10:06:46

Modified files:
 bfd : ChangeLog elf.c

Log message:
 * Import this patch from the mainline:
 2008-11-10 Andreas Schwab <email address hidden>

 PR 7011
 * elf.c (assign_file_positions_for_non_load_sections): Handle
 PT_GNU_RELRO specially.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&only_with_tag=binutils-2_19-branch&r1=1.4318.2.19&r2=1.4318.2.20
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/elf.c.diff?cvsroot=src&only_with_tag=binutils-2_19-branch&r1=1.462.2.2&r2=1.462.2.3

Revision history for this message
In , Nickc (nickc) wrote :

Hi Matthias,

  I have checked the patch into the 2.19 branch, but it is up to the release
manager to decide if there should be a 2.19.1 point release. I will email him
and see what he thinks.

Cheers
  Nick

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package binutils - 2.19.0.20090110-0ubuntu1

---------------
binutils (2.19.0.20090110-0ubuntu1) jaunty; urgency=low

  * Update to the binutils-2_19-branch 20090110.
    - Fix PR binutils/7011. LP: #254790.
  * debian/*.shlibs: Update to the version from the branch.

 -- Matthias Klose <email address hidden> Sat, 10 Jan 2009 13:47:35 +0100

Changed in binutils:
status: Triaged → Fix Released
Changed in binutils:
importance: Unknown → Medium
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.