| Summary: | guard symbols almost always present when using hgcc-2.4.[1-2] | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | solar (RETIRED) <solar> |
| Component: | [OLD] Development | Assignee: | Alexander Gabert (RETIRED) <pappy> |
| Status: | VERIFIED TEST-REQUEST | ||
| Severity: | major | ||
| Priority: | High | ||
| Version: | 1.4 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
21:18:21 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# gcc -o vuln vuln.c
21:18:26 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# strip vuln
21:18:27 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# readelf -s vuln| grep guard
31: 00001ce0 32 OBJECT GLOBAL DEFAULT 16 __guard
21:18:29 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# ./vuln
Segmentation fault
21:18:33 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# gcc -o vuln vuln.c -yno_propolice
21:19:02 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# readelf -s vuln| grep guard
21:19:04 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# ./vuln
Segmentation fault
i dont know what you are doing wrong, dudes
21:19:05 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# gcc -o vuln vuln.c -yno_propolice -yet_exec
21:19:30 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# readelf -s vuln| grep guard
21:19:32 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# file vuln
vuln: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux
2.4.1, dynamically linked (uses shared libs), not stripped
21:19:35 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# ./vuln
Segmentation fault
21:20:28 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# gcc -o vuln vuln.c -yno_propolice
21:20:35 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# ./vuln 1234567890
21:20:42 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# ./vuln 12345678901
21:20:44 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# ./vuln 1234567890
21:20:46 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# gcc -o vuln vuln.c
21:20:54 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# ./vuln 1234567890
21:20:56 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# ./vuln 12345678901
21:20:57 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# ./vuln 123456789012
21:20:58 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# ./vuln 123456789012345678901234567890
Aborted
21:21:05 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# readelf -s vuln| grep guard
31: 00001ce0 32 OBJECT GLOBAL DEFAULT 16 __guard
71: 00000000 0 FILE LOCAL DEFAULT ABS guard.c
72: 0000094c 153 FUNC LOCAL DEFAULT 12 __guard_setup
81: 00001ce0 32 OBJECT GLOBAL DEFAULT 16 __guard
21:21:15 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# strip vuln
21:21:25 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# readelf -s vuln| grep guard
31: 00001ce0 32 OBJECT GLOBAL DEFAULT 16 __guard
21:21:26 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# gcc -o vuln vuln.c -yno_propolice
21:21:33 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
# ./vuln 123456789012345678901234567890
Segmentation fault
21:21:35 [/usr/local/chroots/chroot001:18030.pty-s0.epoch] epoch /tmp/test
#
maybe you should reemerge hcc-242 to get the latest bugfree thing from cvs
*g*
cvs update... solar@simple c $ gcc vuln.c -o vuln -yet_exec solar@simple c $ gcc vuln.c -o vuln -yno_propolice solar@simple c $ readelf -s vuln | grep guard Good now this all works as expected. On another note. I don't think I was doing anything wrong here. As I stated on the "Summary" of this bug the problem existed in 2.4.1 - 2.4.2 so unless you tested 2.4.1 as well I don't think you should be so quick to say others are doing something wrong. If using a solution that your working is wrong then I guess I'm guilty. *g* |
=== TEST 1 === solar@simple c $ gcc vuln.c -o vuln -yno_propolice solar@simple c $ readelf -s vuln | grep _guard 31: 00001ce0 32 OBJECT GLOBAL DEFAULT 16 __guard 72: 0000095c 158 FUNC LOCAL DEFAULT 12 __guard_setup 81: 00001ce0 32 OBJECT GLOBAL DEFAULT 16 __guard === TEST 2 === solar@simple c $ gcc vuln.c -o vuln solar@simple c $ readelf -s vuln | grep _guard 31: 00001d20 32 OBJECT GLOBAL DEFAULT 16 __guard 72: 0000095c 158 FUNC LOCAL DEFAULT 12 __guard_setup 81: 00001d20 32 OBJECT GLOBAL DEFAULT 16 __guard === TEST 3 === solar@simple c $ gcc vuln.c -o vuln -yno_propolice -yet_exec solar@simple c $ readelf -s vuln | grep _guard === TEST 4 === solar@simple c $ gcc vuln.c -o vuln -yet_exec solar@simple c $ readelf -s vuln | grep _guard === TEST 5 === emerge =sys-devel/hardened-gcc-2.4.2 gcc vuln.c -o vuln -yet_exec This just blows up real bad.. solar@simple c $ gcc vuln.c -o vuln -yet_exec /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../crt1S_noncsu.o(.text+0x0): In function `_start': : multiple definition of `_start' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../crt1.o(.text+0x0): first defined here /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../crt1S_noncsu.o(.rodata+0x0): multiple definition of `_fp_hw' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../crt1.o(.rodata+0x0): first defined here /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../crt1S_noncsu.o(.data+0x0): In function `data_start': : multiple definition of `__data_start' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../crt1.o(.data+0x0): first defined here /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../crt1S_noncsu.o(.rodata+0x4): multiple definition of `_IO_stdin_used' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../crt1.o(.rodata+0x4): first defined here collect2: ld returned 1 exit status ------------------------------------------------ As we can see from the above tests we are getting the symbols when we should not. Now iirc the __guard_setup function is apart of the constructor and there is no way not to have that be in the end result. If this is true then the output executable will have a performance hit regardless if we wanted ssp or not among other hidden bugs. Please stay up way to late at night and bang your head against the wall till this problem goes away. :)