I am trying to compile with -msecure-plt, and although compilation is completing just fine, when looking at the memory maps it doesn't look like the flag is actually doing anything. I am assuming it is not doing anything because the got and plt sections are both still in RWXP segements.
Dump of assembler code for function main:
0x1000061c <+0>: stwu r1,-16(r1)
0x10000620 <+4>: mflr r0
0x10000624 <+8>: stw r0,20(r1)
0x10000628 <+12>: stw r31,12(r1)
0x1000062c <+16>: mr r31,r1
0x10000630 <+20>: bl 0x1001096c <libfunc#plt>
0x10000634 <+24>: mr r10,r3
0x10000638 <+28>: lis r9,4096
0x1000063c <+32>: addi r3,r9,2048
0x10000640 <+36>: mr r4,r10
0x10000644 <+40>: crclr 4*cr1+eq
0x10000648 <+44>: bl 0x10010964 <printf#plt>
=> 0x1000064c <+48>: li r9,1
0x10000650 <+52>: mr r3,r9
0x10000654 <+56>: addi r11,r31,16
0x10000658 <+60>: lwz r0,4(r11)
0x1000065c <+64>: mtlr r0
0x10000660 <+68>: lwz r31,-4(r11)
0x10000664 <+72>: mr r1,r11
0x10000668 <+76>: blr
with /proc/<pid>/maps showing a memory map of
00100000-00103000 r-xp 00000000 00:00 0 [vdso]
0fe40000-0ffb8000 r-xp 00000000 00:01 6285 /lib/libc-2.22.so
0ffb8000-0ffc7000 ---p 00178000 00:01 6285 /lib/libc-2.22.so
0ffc7000-0ffc9000 r--p 00177000 00:01 6285 /lib/libc-2.22.so
0ffc9000-0ffcd000 rwxp 00179000 00:01 6285 /lib/libc-2.22.so
0ffcd000-0ffcf000 rwxp 00000000 00:00 0
0ffdf000-0ffe0000 r-xp 00000000 00:01 5928 /lib/libmaintest.so
0ffe0000-0ffef000 ---p 00001000 00:01 5928 /lib/libmaintest.so
0ffef000-0fff0000 rwxp 00000000 00:01 5928 /lib/libmaintest.so
10000000-10001000 r-xp 00000000 00:01 5934 /root/main
10010000-10011000 rwxp 00000000 00:01 5934 /root/main
b7860000-b7882000 r-xp 00000000 00:01 6240 /lib/ld-2.22.so
b7890000-b7892000 rw-p 00000000 00:00 0
b7892000-b7893000 r--p 00022000 00:01 6240 /lib/ld-2.22.so
b7893000-b7895000 rwxp 00023000 00:01 6240 /lib/ld-2.22.so
bff1a000-bff3b000 rw-p 00000000 00:00 0 [stack]
which sticks both of the plot jumps right into the middle of a rwx section. Am I misinterpreting this information?
I think that might be a kernel limitation: see e.g. https://lkml.org/lkml/2016/8/8/354 - it looks like the kernel maps things in ways you wouldn't expect for what I understand to be historical reasons.
It may be changing soon, given that the patch above was sent yesterday.
Depending on your version of gcc, the -msecure-plt flag might be ignored if any libraries you linked to were not also compiled with -msecure-plt (including glibc). See this.
Related
I'm upgrading to Ruby 2.5.1 and when a unicorn worker crashed during testing, I got a ton of output that I'm not sure how to interpret.
Does anyone know what each of these columns means? I think if I understood this better, I'd be able to find what caused the issue, as the output is rather larger than what I pasted here.
* Process memory map:
55d388ebb000-55d3891db000 r-xp 00000000 ca:01 4623622 /opt/ruby-2.5.1/bin/ruby
55d3893db000-55d3893e0000 r--p 00320000 ca:01 4623622 /opt/ruby-2.5.1/bin/ruby
55d3893e0000-55d3893e1000 rw-p 00325000 ca:01 4623622 /opt/ruby-2.5.1/bin/ruby
55d3893e1000-55d3893f2000 rw-p 00000000 00:00 0
55d38b066000-55d38bdf9000 rw-p 00000000 00:00 0 [heap]
55d38bdf9000-55d38d1a9000 rw-p 00000000 00:00 0 [heap]
55d38d1a9000-55d3a1258000 rw-p 00000000 00:00 0 [heap]
7f1bcc000000-7f1bcc021000 rw-p 00000000 00:00 0
7f1bcc021000-7f1bd0000000 ---p 00000000 00:00 0
7f1bd0e68000-7f1bd1031000 r--s 00000000 ca:01 13016
/lib/x86_64-linux-gnu/libc-2.23.so
....
i developed a static library, and a test application to call its
functions.
Now, when i am executing the test application, it was able to get in to
the function and calculate the required values, but when the return is
called it is giving stack smash error
./test_app
USB Handle opened SUCCESSFULLY
*** stack smashing detected ***: /home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7ffff7b25807]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x0)[0x7ffff7b257d0]
/home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app[0x4008ec]
/home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app[0x4006ed]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7ffff7a3c76d]
/home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app[0x400619]
======= Memory map: ========
00400000-00402000 r-xp 00000000 08:08 1186 /home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app
00601000-00602000 r--p 00001000 08:08 1186 /home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app
00602000-00603000 rw-p 00002000 08:08 1186 /home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app
00603000-00624000 rw-p 00000000 00:00 0 [heap]
7ffff7805000-7ffff781a000 r-xp 00000000 08:05 658720 /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff781a000-7ffff7a19000 ---p 00015000 08:05 658720 /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7a19000-7ffff7a1a000 r--p 00014000 08:05 658720 /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7a1a000-7ffff7a1b000 rw-p 00015000 08:05 658720 /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7a1b000-7ffff7bd0000 r-xp 00000000 08:05 658699 /lib/x86_64-linux-gnu/libc-2.15.so
7ffff7bd0000-7ffff7dcf000 ---p 001b5000 08:05 658699 /lib/x86_64-linux-gnu/libc-2.15.so
7ffff7dcf000-7ffff7dd3000 r--p 001b4000 08:05 658699 /lib/x86_64-linux-gnu/libc-2.15.so
7ffff7dd3000-7ffff7dd5000 rw-p 001b8000 08:05 658699 /lib/x86_64-linux-gnu/libc-2.15.so
7ffff7dd5000-7ffff7dda000 rw-p 00000000 00:00 0
7ffff7dda000-7ffff7dfc000 r-xp 00000000 08:05 658679 /lib/x86_64-linux-gnu/ld-2.15.so
7ffff7fdd000-7ffff7fe0000 rw-p 00000000 00:00 0
7ffff7ff6000-7ffff7ffb000 rw-p 00000000 00:00 0
7ffff7ffb000-7ffff7ffc000 r-xp 00000000 00:00 0 [vdso]
7ffff7ffc000-7ffff7ffd000 r--p 00022000 08:05 658679 /lib/x86_64-linux-gnu/ld-2.15.so
7ffff7ffd000-7ffff7fff000 rw-p 00023000 08:05 658679 /lib/x86_64-linux-gnu/ld-2.15.so
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0 [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Here is the test application
#include <stdio.h>
#include "leapfrog.h"
void main()
{
unsigned int mid=0x0;
USB_Init();
mid = Read_MID();
printf("\n mid = 0x%x\n",mid);
USB_Deinit();
return;
}
The above was the test application and it was referencing this function in the library
uint16 Read_MID(void)
{
int8 buf[8]={0};
uint16 mid;
//Read Vendor id
buf[0] = 0xFE;
msp_write(0x41,buf,1);
msp_read(0x41,buf,2);
mid = buf[0];
mid <<= 8;
mid |= buf[1];
return mid;
}
till the "mid" calculation i could get the correct values. it is reaching till the end while debugging with insight debugger. just after "}" in the console i see the stack smash error.
what might be the cause of the stack smash.
Thank you for time and patience.
I resolved it by adding more array space.
int8 buf[8]={0};
i made it as
int8 buf[10]={0};
my question is not relative to the error itself (I know what is the reason for it).
I would instead like to know how to read this dump (meaning of the fields, flags and so on), where it is produced (glibc, or gcc libraries) and how I can infer what's wrong from it at a higher level (e.g. some tool that might find this output useful).
*** glibc detected *** python: double free or corruption (fasttop): 0x0000000006c4eb90 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7f6c3a0a1b96]
/usr/lib/nvidia-current-updates/tls/libnvidia-tls.so.304.88(+0x1cc1)[0x7f6c2e544cc1]
======= Memory map: ========
00400000-00401000 r-xp 00000000 08:07 2238049 /build/bin/python
00600000-00601000 r--p 00000000 08:07 2238049 /build/bin/python
00601000-00602000 rw-p 00001000 08:07 2238049 /build/bin/python
00954000-07625000 rw-p 00000000 00:00 0 [heap]
40c14000-40c92000 rw-p 00000000 00:00 0
7f6c04000000-7f6c041bc000 rw-p 00000000 00:00 0
7f6c041bc000-7f6c08000000 ---p 00000000 00:00 0
7f6c08000000-7f6c081bc000 rw-p 00000000 00:00 0
7f6c081bc000-7f6c0c000000 ---p 00000000 00:00 0
7f6c0c000000-7f6c0c1bc000 rw-p 00000000 00:00 0
7f6c0c1bc000-7f6c10000000 ---p 00000000 00:00 0
7f6c14000000-7f6c14021000 rw-p 00000000 00:00 0
7f6c14021000-7f6c18000000 ---p 00000000 00:00 0
7f6c1ab5a000-7f6c1ab5b000 ---p 00000000 00:00 0
7f6c1ab5b000-7f6c1af5b000 rwxp 00000000 00:00 0
7f6c1af5b000-7f6c1af5c000 ---p 00000000 00:00 0
7f6c1af5c000-7f6c1b35c000 rwxp 00000000 00:00 0
7f6c1b35c000-7f6c1b35d000 ---p 00000000 00:00 0
7f6c1b35d000-7f6c1b75d000 rwxp 00000000 00:00 0
7f6c1b75d000-7f6c1b767000 r-xp 00000000 08:05 1314563 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f6c1b767000-7f6c1b967000 ---p 0000a000 08:05 1314563 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f6c1b967000-7f6c1b968000 r--p 0000a000 08:05 1314563 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f6c1b968000-7f6c1b969000 rw-p 0000b000 08:05 1314563 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f6c1b969000-7f6c1b980000 r-xp 00000000 08:05 1314576 /lib/x86_64-linux-gnu/libnsl-2.15.so
The man page for proc has the answer. The memory map output format is given in the entry for /proc/[pid]/maps.
The short summary is going across the columns it is: memory range, permissions, offset, device (major:minor), inode, and pathname.
When i build gcc-4.0.4 (on Ubuntu 10.10), there is a problem:
arm-linux-ar rc ./libgcc.a libgcc/./_udivsi3.o libgcc/./_divsi3.o
libgcc/./_umodsi3.o libgcc/./_modsi3.o libgcc/./_dvmd_lnx.o
libgcc/./_muldi3.o libgcc/./_negdi2.o libgcc/./_lshrdi3.o
libgcc/./_ashldi3.o libgcc/./_ashrdi3.o libgcc/./_cmpdi2.o
libgcc/./_ucmpdi2.o libgcc/./_floatdidf.o libgcc/./_floatdisf.o
libgcc/./_fixunsdfsi.o libgcc/./_fixunssfsi.o libgcc/./_fixunsdfdi.o
libgcc/./_fixdfdi.o libgcc/./_fixunssfdi.o libgcc/./_fixsfdi.o
libgcc/./_fixxfdi.o libgcc/./_fixunsxfdi.o libgcc/./_floatdixf.o
libgcc/./_fixunsxfsi.o libgcc/./_fixtfdi.o libgcc/./_fixunstfdi.o
libgcc/./_floatditf.o libgcc/./_clear_cache.o
libgcc/./_enable_execute_stack.o libgcc/./trampoline.o
libgcc/./_main.o libgcc/./_absvsi2.o libgcc/./_absvdi2.o
libgcc/./_addvsi3.o libgcc/./_addvdi3.o libgcc/./_subvsi3.o
libgcc/./_subvdi3.o libgcc/./_mulvsi3.o libgcc/./_mulvdi3.o
libgcc/./_negvsi2.o libgcc/./_negvdi2.o libgcc/./_ctors.o
libgcc/./_ffssi2.o libgcc/./_ffsdi2.o libgcc/./_clz.o
libgcc/./_clzsi2.o libgcc/./_clzdi2.o libgcc/./_ctzsi2.o
libgcc/./_ctzdi2.o libgcc/./_popcount_tab.o libgcc/./_popcountsi2.o
libgcc/./_popcountdi2.o libgcc/./_paritysi2.o libgcc/./_paritydi2.o
libgcc/./_powisf2.o libgcc/./_powidf2.o libgcc/./_powixf2.o
libgcc/./_powitf2.o libgcc/./_mulsc3.o libgcc/./_muldc3.o
libgcc/./_mulxc3.o libgcc/./_multc3.o libgcc/./_divsc3.o
libgcc/./_divdc3.o libgcc/./_divxc3.o libgcc/./_divtc3.o
libgcc/./eprintf.o libgcc/./_gcc_bcmp.o libgcc/./_divdi3.o
libgcc/./_moddi3.o libgcc/./_udivdi3.o libgcc/./_umoddi3.o
libgcc/./_udiv_w_sdiv.o libgcc/./_udivmoddi4.o libgcc/./unwind-dw2.o
libgcc/./unwind-dw2-fde-glibc.o libgcc/./unwind-sjlj.o
libgcc/./gthr-gnat.o libgcc/./unwind-c.o
* buffer overflow detected *: arm-linux-ar terminated
======= Backtrace: ========= /lib/libc.so.6(__fortify_fail+0x50)[0x8f1890]
/lib/libc.so.6(+0xe478a)[0x8f078a] /lib/libc.so.6(+0xe3ec8)[0x8efec8]
/lib/libc.so.6(_IO_default_xsputn+0x9e)[0x8765ee]
/lib/libc.so.6(_IO_padn+0xd8)[0x869f78]
/lib/libc.so.6(_IO_vfprintf+0x2b79)[0x84bd89]
/lib/libc.so.6(__vsprintf_chk+0xad)[0x8eff7d]
/lib/libc.so.6(__sprintf_chk+0x2d)[0x8efebd] arm-linux-ar[0x8050c05]
arm-linux-ar[0x804ed7e] arm-linux-ar[0x805168c]
arm-linux-ar[0x8055178] arm-linux-ar[0x804b7d2]
arm-linux-ar[0x804c494]
/lib/libc.so.6(__libc_start_main+0xe7)[0x822ce7]
arm-linux-ar[0x80496e1]
======= Memory map: ======== 003e4000-00400000 r-xp 00000000 08:01 131636 /lib/ld-2.12.1.so 00400000-00401000 r--p 0001b000 08:01
131636 /lib/ld-2.12.1.so 00401000-00402000 rw-p 0001c000 08:01
131636 /lib/ld-2.12.1.so 006b2000-006cc000 r-xp 00000000 08:01
131244 /lib/libgcc_s.so.1 006cc000-006cd000 r--p 00019000 08:01
131244 /lib/libgcc_s.so.1 006cd000-006ce000 rw-p 0001a000 08:01
131244 /lib/libgcc_s.so.1 0080c000-00963000 r-xp 00000000 08:01
132225 /lib/libc-2.12.1.so 00963000-00965000 r--p 00157000 08:01
132225 /lib/libc-2.12.1.so 00965000-00966000 rw-p 00159000 08:01
132225 /lib/libc-2.12.1.so 00966000-00969000 rw-p 00000000 00:00 0
00a42000-00a43000 r-xp 00000000 00:00 0 [vdso]
08048000-08097000 r-xp 00000000 08:01 427851
/home/zouhansi/armlinux/tools/bin/arm-linux-ar 08097000-08098000 r--p
0004e000 08:01 427851
/home/zouhansi/armlinux/tools/bin/arm-linux-ar 08098000-08099000 rw-p
0004f000 08:01 427851
/home/zouhansi/armlinux/tools/bin/arm-linux-ar 08099000-0809d000 rw-p
00000000 00:00 0 09354000-09558000 rw-p 00000000 00:00 0
[heap] b74c1000-b74c8000 r--s 00000000 08:01 661517
/usr/lib/gconv/gconv-modules.cache b74c8000-b765b000 r--p 002a3000
08:01 657761 /usr/lib/locale/locale-archive b765b000-b785b000 r--p
00000000 08:01 657761 /usr/lib/locale/locale-archive
b785b000-b785c000 rw-p 00000000 00:00 0 b785f000-b786b000 rw-p
00000000 00:00 0 bf839000-bf85c000 rw-p 00000000 00:00 0
[stack]
I find some solution from network to add "-D_FORTIFY_SOURCE=0" in
CFLAGS. I had edit Makefile like this: CFLAGS_FOR_BUILD = -g -O2
-D_FORTIFY_SOURCE=0
I make it again. But this problem is occured again.
Could you give some comments? Thanks a lot.
I had a similar problem building a GCC cross-compiler - it seems binutils is full of unsafe calls to sprintf().
A workaround which worked for me was to set:
export CFLAGS="-fno-stack-protector -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0"
These have to be set before running ../src/configure.
There seems to be a binutils patch here: http://www.redhat.com/archives/fedora-extras-commits/2009-November/msg06284.html but it didn't apply cleanly to the source I was using, so I stuck with CFLAGS hack.
After I cross-compiled GCC with the latest version of binutils, it worked and I didn't get the buffer overflow anymore.
This was the line I used, after I installed the latest binutils:
../gcc-4.5.1/configure --target=arm-linux --prefix=/.../toolchain/bin/binutils --disable-nls --disable-multilib --disable-shared --disable-decimal-float --disable--threads --disable-libmudflap --disable-libssp --disable-libgomp --enable-languages=c --with-system-zlib --with-newlib
my program was compiled properly with "make" on Ubuntu 11.04, but when i run it, it give error.
is this a bug on Ubuntu? or this is difference in variable types between compilers?
pls help me
*** buffer overflow detected ***: src/trilearn_player terminated
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x50)[0x9cd0a0]
/lib/i386-linux-gnu/libc.so.6(+0xe5f7a)[0x9cbf7a]
/lib/i386-linux-gnu/libc.so.6(__strcpy_chk+0x3f)[0x9cb30f]
src/trilearn_player[0x804dd24]
src/trilearn_player[0x808b2d5]
src/trilearn_player[0x80920cf]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x8fce37]
src/trilearn_player[0x804a421]
======= Memory map: ========
00139000-0015d000 r-xp 00000000 08:0b 6060 /lib/i386-linux-gnu/libm-2.13.so
0015d000-0015e000 r--p 00023000 08:0b 6060 /lib/i386-linux-gnu/libm-2.13.so
0015e000-0015f000 rw-p 00024000 08:0b 6060 /lib/i386-linux-gnu/libm-2.13.so
001b4000-001b5000 r-xp 00000000 00:00 0 [vdso]
00488000-0049d000 r-xp 00000000 08:0b 6831 /lib/i386-linux-gnu/libpthread-2.13.so
0049d000-0049e000 r--p 00015000 08:0b 6831 /lib/i386-linux-gnu/libpthread-2.13.so
0049e000-0049f000 rw-p 00016000 08:0b 6831 /lib/i386-linux-gnu/libpthread-2.13.so
0049f000-004a1000 rw-p 00000000 00:00 0
00558000-00637000 r-xp 00000000 08:0b 134145
00637000-0063b000 r--p 000de000 08:0b 134145 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.14
0063b000-0063c000 rw-p 000e2000 08:0b 134145 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.14
0063c000-00643000 rw-p 00000000 00:00 0
0087b000-00885000 r-xp 00000000 08:0b 6826 /lib/i386-linux-gnu/libnss_files-2.13.so
00885000-00886000 r--p 00009000 08:0b 6826 /lib/i386-linux-gnu/libnss_files-2.13.so
00886000-00887000 rw-p 0000a000 08:0b 6826 /lib/i386-linux-gnu/libnss_files-2.13.so
008e6000-00a42000 r-xp 00000000 08:0b 5792 /lib/i386-linux-gnu/libc-2.13.so
/lib/i386-linux-gnu/libc.so.6(__strcpy_chk+0x3f)[0x9cb30f]
Looks like you copy too many chars to the destination.