Bug 167569 - gcc stack protector stuff finds buffer overflow in as when processing garbage
gcc stack protector stuff finds buffer overflow in as when processing garbage
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: binutils (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-05 13:47 EDT by Pekka Pietikäinen
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-05 13:51:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pekka Pietikäinen 2005-09-05 13:47:32 EDT
Description of problem:

Obviously this is something totally stupid to do, but just in case the exact
bug in the code is potentially anything serious:

[pp@the ~]$ as /bin/ls
/bin/ls: Assembler messages:
/bin/ls:1: Error: junk at end of line, first unrecognized character valued 0x7f
/bin/ls:1: Error: junk at end of line, first unrecognized character valued 0x2
/bin/ls:1: Error: junk at end of line, first unrecognized character is `>'
/bin/ls:1: Error: junk at end of line, first unrecognized character valued 0x1
/bin/ls:1: Error: junk at end of line, first unrecognized character is `6'
/bin/ls:1: Error: junk at end of line, first unrecognized character is `@'
*** buffer overflow detected ***: as terminated
======= Backtrace: =========
/lib64/libc.so.6(__chk_fail+0x2f)[0x3cc8edd4ff]
/lib64/libc.so.6[0x3cc8edcad9]
/lib64/libc.so.6(_IO_default_xsputn+0x86)[0x3cc8e68496]
/lib64/libc.so.6(_IO_vfprintf+0xf47)[0x3cc8e42557]
/lib64/libc.so.6(__vsprintf_chk+0xa9)[0x3cc8edcb89]
/lib64/libc.so.6(__sprintf_chk+0x80)[0x3cc8edcac0]
as[0x420ee9]
as[0x4210c5]
as[0x426205]
as[0x415f66]
as[0x405461]
/lib64/libc.so.6(__libc_start_main+0xef)[0x3cc8e1cd1f]
as[0x402889]
======= Memory map: ========
00400000-0044a000 r-xp 00000000 fd:00 10307595                           /usr/bin/as
00549000-0054b000 rw-p 00049000 fd:00 10307595                           /usr/bin/as
0054b000-00554000 rw-p 0054b000 00:00 0
0064a000-0064b000 rw-p 0004a000 fd:00 10307595                           /usr/bin/as
0064b000-0068d000 rw-p 0064b000 00:00 0                                  [heap]
3cc8100000-3cc811a000 r-xp 00000000 fd:00 11111070                      
/lib64/ld-2.3.90.so
3cc8219000-3cc821a000 r--p 00019000 fd:00 11111070                      
/lib64/ld-2.3.90.so
3cc821a000-3cc821b000 rw-p 0001a000 fd:00 11111070                      
/lib64/ld-2.3.90.so
3cc8300000-3cc8392000 r-xp 00000000 fd:00 10296174                      
/usr/lib64/libbfd-2.16.91.0.2.so
3cc8392000-3cc8491000 ---p 00092000 fd:00 10296174                      
/usr/lib64/libbfd-2.16.91.0.2.so
3cc8491000-3cc849d000 rw-p 00091000 fd:00 10296174                      
/usr/lib64/libbfd-2.16.91.0.2.so
3cc849d000-3cc84a1000 rw-p 3cc849d000 00:00 0
3cc8e00000-3cc8f2f000 r-xp 00000000 fd:00 11112440                      
/lib64/libc-2.3.90.so
3cc8f2f000-3cc902e000 ---p 0012f000 fd:00 11112440                      
/lib64/libc-2.3.90.so
3cc902e000-3cc9032000 r--p 0012e000 fd:00 11112440                      
/lib64/libc-2.3.90.so
3cc9032000-3cc9034000 rw-p 00132000 fd:00 11112440                      
/lib64/libc-2.3.90.so
3cc9034000-3cc9038000 rw-p 3cc9034000 00:00 0
3d03900000-3d0390d000 r-xp 00000000 fd:00 11111155                      
/lib64/libgcc_s-4.0.1-20050831.so.1
3d0390d000-3d03a0c000 ---p 0000d000 fd:00 11111155                      
/lib64/libgcc_s-4.0.1-20050831.so.1
3d03a0c000-3d03a0d000 rw-p 0000c000 fd:00 11111155                      
/lib64/libgcc_s-4.0.1-20050831.so.1
2aaaaaaab000-2aaaaaaac000 rw-p 2aaaaaaab000 00:00 0
2aaaaaacd000-2aaaaaad0000 rw-p 2aaaaaacd000 00:00 0
2aaaaaad0000-2aaaada24000 r--p 00000000 fd:00 10310000                  
/usr/lib/locale/locale-archive
2aaaada24000-2aaaadd2b000 rw-p 2aaaada24000 00:00 0
7fffff938000-7fffff94d000 rw-p 7fffff938000 00:00 0                     
[stack]ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0                 
[vdso]
Aborted
[pp@the ~]$
[pp@the ~]$ rpm -q binutils
binutils-2.16.91.0.2-4

FC4 is also effected.

Suppose expected behaviour is to bravely try to parse all that junk.
Comment 1 Jakub Jelinek 2005-09-05 13:51:56 EDT
No, it is not.  If you want to spent a few months fixing all the problems
when gas is fed with junk, you can go ahead, but I'm certainly not willing
to spend that much time on making gas junk proof.  I spent a lot of time
trying that for small read-only binutils and elfutils utilities and even after
more than 100KB of patches did not reach the point where it wouldn't crash
on random junk.
In gas as well as ld, the rule is simply, don't run it on untrusted junk.

Note You need to log in before you can comment on or make changes to this bug.