Re: [Full-disclosure] Exploiting buffer overflows via protected GCC
On Tue, 17 Feb 2009 12:19:07 +1100, Jubei Trippataka said: memset(buf, 'A', 528); That's where the original poster is starting from... You commenting on exploitation is kind of like asking a deaf person what their favorite song is. You obviously have no clue what you are talking about due to the fact you offered absolutely no insight in to the protection mechanism he was asking about, nor potential means of exploitation. Given this the real question remains, do you actually believe you have any clue about this stuff, or are you like Wallace and just want to post useless shit? Given the starting point, do you *really* think the original poster would have understood an in-depth explanation of all the technical details, rather than some hints as to the next thing he needs to learn about? He's not going to get anywhere until he learns at least that there's that canary on the stack, and where it is in relation to the various variables and things like the return address. After that, yes, he faces *other* challenges. But he'll learn more by thinking through each issue on his own than if somebody hands him the whole enchilada. pgpxvGo337Lj2.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Exploiting buffer overflows via protected GCC
On Mon, Feb 16, 2009 at 09:00:33AM -0500, ArcSighter Elite wrote: James Matthews wrote: I would recommend doing the following things. 1. Ask on the Ubuntu GCC list what protection is implemented. (Or just look at the source) 2. Use GCC to see where the execution is being redirected and so you can have a better visual of whats going on. 3. Are you sure the stack is executable? _fortify_fail is caused by the light weight buffer overflow checking, enabled by the -D_FORTIFY_SOURCE=2 compile time flag. Ciao, Marcus ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Exploiting buffer overflows via protected GCC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Matthews wrote:
I would recommend doing the following things.
1. Ask on the Ubuntu GCC list what protection is implemented. (Or just look
at the source)
2. Use GCC to see where the execution is being redirected and so you can
have a better visual of whats going on.
3. Are you sure the stack is executable?
On Sat, Feb 14, 2009 at 12:30 AM, Marcus Meissner meiss...@suse.de wrote:
On Fri, Feb 13, 2009 at 11:50:11AM -0500, Jason Starks wrote:
I came across a problem that I am sure many security researchers have
seen
before:
ja...@uboo:~$ cat bof.c
#include stdio.h
#include string.h
int main()
{
char buf[512];
memset(buf, 'A', 528);
return 0;
}
ja...@uboo:~$
ja...@uboo:~$ ./bof
*** stack smashing detected ***: ./bof terminated
=== Backtrace: =
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7f08548]
ja...@uboo:~$
I have googled my brains out for a solution, but all I have gathered is
that
my Ubuntu's gcc is compiled with SSP and everytime I try to overwrite the
return address it also overwrites the canary's value, and triggers a stop
in
the program. I've disassembled it and anybody who can help me probably
doesn't need me to explain much more, but I would like to know a way to
get
this. There seems to be some people on this list who may know something
on
how to exploit on *nix systems with this protection enabled.
I do not want to just disable the protection and exploit it normally, I
want
Perhaps you should learn first exactly _what_ caught your buffer overflow.
Hint: It was not SSP aka -fstack-protector.
Ciao, Marcus
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Ubuntu and recent kernels also implement ASLR. So, that may be the
issue, besides StackGuard.
Sincerely.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD4DBQFJmXGAH+KgkfcIQ8cRAmG0AJ0c9rFv2hd43oP2iR8EYCRC0gwKgwCYpXqo
1kRbO2tqcJ31JrUw3uNiRA==
=FGDQ
-END PGP SIGNATURE-
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Exploiting buffer overflows via protected GCC
memset(buf, 'A', 528); Don't do that. This sort of whoops is exactly what the gcc SSP canary is designed to stop. I could comment on this, but... I'll leave it. I have googled my brains out for a solution, but all I have gathered is that my Ubuntu's gcc is compiled with SSP and everytime I try to overwrite the return address it also overwrites the canary's value, and triggers a stop in the program. I've disassembled it and anybody who can help me probably doesn't need me to explain much more, but I would like to know a way to get this. There seems to be some people on this list who may know something on how to exploit on *nix systems with this protection enabled. What you want to do is be more precise in your splatting. Instead of one memset, see if you can come up with a way to do *two* memsets, which leave your stack looking like: 'A' (above the canary) 4 unmolested bytes of canary 'A' (below the canary) Of course, if you're trying to exploit already-existing code, you probably only have one memset/strcpy you can abuse, and the starting address of the destination is already nailed down, which means you need to fill in the 4 bytes of canary correctly. This means you need to find a way to obtain the value so you can use it. One hint - sometimes you're better off targeting the stack frame 2 or 3 function calls back, rather than the *current* frame. You commenting on exploitation is kind of like asking a deaf person what their favorite song is. You obviously have no clue what you are talking about due to the fact you offered absolutely no insight in to the protection mechanism he was asking about, nor potential means of exploitation. Given this the real question remains, do you actually believe you have any clue about this stuff, or are you like Wallace and just want to post useless shit? -- ciao JT ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Exploiting buffer overflows via protected GCC
I would recommend doing the following things.
1. Ask on the Ubuntu GCC list what protection is implemented. (Or just look
at the source)
2. Use GCC to see where the execution is being redirected and so you can
have a better visual of whats going on.
3. Are you sure the stack is executable?
On Sat, Feb 14, 2009 at 12:30 AM, Marcus Meissner meiss...@suse.de wrote:
On Fri, Feb 13, 2009 at 11:50:11AM -0500, Jason Starks wrote:
I came across a problem that I am sure many security researchers have
seen
before:
ja...@uboo:~$ cat bof.c
#include stdio.h
#include string.h
int main()
{
char buf[512];
memset(buf, 'A', 528);
return 0;
}
ja...@uboo:~$
ja...@uboo:~$ ./bof
*** stack smashing detected ***: ./bof terminated
=== Backtrace: =
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7f08548]
ja...@uboo:~$
I have googled my brains out for a solution, but all I have gathered is
that
my Ubuntu's gcc is compiled with SSP and everytime I try to overwrite the
return address it also overwrites the canary's value, and triggers a stop
in
the program. I've disassembled it and anybody who can help me probably
doesn't need me to explain much more, but I would like to know a way to
get
this. There seems to be some people on this list who may know something
on
how to exploit on *nix systems with this protection enabled.
I do not want to just disable the protection and exploit it normally, I
want
Perhaps you should learn first exactly _what_ caught your buffer overflow.
Hint: It was not SSP aka -fstack-protector.
Ciao, Marcus
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
--
http://www.goldwatches.com/
http://www.jewelerslounge.com/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Exploiting buffer overflows via protected GCC
I came across a problem that I am sure many security researchers have seen
before:
ja...@uboo:~$ cat bof.c
#include stdio.h
#include string.h
int main()
{
char buf[512];
memset(buf, 'A', 528);
return 0;
}
ja...@uboo:~$
ja...@uboo:~$ ./bof
*** stack smashing detected ***: ./bof terminated
=== Backtrace: =
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7f08548]
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7f08500]
./bof[0x8048467]
[0x41414141]
=== Memory map:
08048000-08049000 r-xp 08:01 5630493/home/jason/bof
08049000-0804a000 r--p 08:01 5630493/home/jason/bof
0804a000-0804b000 rw-p 1000 08:01 5630493/home/jason/bof
09407000-09428000 rw-p 09407000 00:00 0 [heap]
b7dfe000-b7e0b000 r-xp 08:01 2696597/lib/libgcc_s.so.1
b7e0b000-b7e0c000 r--p c000 08:01 2696597/lib/libgcc_s.so.1
b7e0c000-b7e0d000 rw-p d000 08:01 2696597/lib/libgcc_s.so.1
b7e0d000-b7e0e000 rw-p b7e0d000 00:00 0
b7e0e000-b7f66000 r-xp 08:01 2713045/lib/tls/i686/cmov/
libc-2.8.90.so
b7f66000-b7f68000 r--p 00158000 08:01 2713045/lib/tls/i686/cmov/
libc-2.8.90.so
b7f68000-b7f69000 rw-p 0015a000 08:01 2713045/lib/tls/i686/cmov/
libc-2.8.90.so
b7f69000-b7f6c000 rw-p b7f69000 00:00 0
b7f83000-b7f85000 rw-p b7f83000 00:00 0
b7f85000-b7f9f000 r-xp 08:01 2696604/lib/ld-2.8.90.so
b7f9f000-b7fa r-xp b7f9f000 00:00 0 [vdso]
b7fa-b7fa1000 r--p 0001a000 08:01 2696604/lib/ld-2.8.90.so
b7fa1000-b7fa2000 rw-p 0001b000 08:01 2696604/lib/ld-2.8.90.so
bfb8c000-bfba1000 rw-p bffeb000 00:00 0 [stack]
Aborted
ja...@uboo:~$
I have googled my brains out for a solution, but all I have gathered is that
my Ubuntu's gcc is compiled with SSP and everytime I try to overwrite the
return address it also overwrites the canary's value, and triggers a stop in
the program. I've disassembled it and anybody who can help me probably
doesn't need me to explain much more, but I would like to know a way to get
this. There seems to be some people on this list who may know something on
how to exploit on *nix systems with this protection enabled.
I do not want to just disable the protection and exploit it normally, I want
to learn how to exploit it this way.
Jason
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Exploiting buffer overflows via protected GCC
On Fri, 13 Feb 2009 11:50:11 EST, Jason Starks said: memset(buf, 'A', 528); Don't do that. This sort of whoops is exactly what the gcc SSP canary is designed to stop. I have googled my brains out for a solution, but all I have gathered is that my Ubuntu's gcc is compiled with SSP and everytime I try to overwrite the return address it also overwrites the canary's value, and triggers a stop in the program. I've disassembled it and anybody who can help me probably doesn't need me to explain much more, but I would like to know a way to get this. There seems to be some people on this list who may know something on how to exploit on *nix systems with this protection enabled. What you want to do is be more precise in your splatting. Instead of one memset, see if you can come up with a way to do *two* memsets, which leave your stack looking like: 'A' (above the canary) 4 unmolested bytes of canary 'A' (below the canary) Of course, if you're trying to exploit already-existing code, you probably only have one memset/strcpy you can abuse, and the starting address of the destination is already nailed down, which means you need to fill in the 4 bytes of canary correctly. This means you need to find a way to obtain the value so you can use it. One hint - sometimes you're better off targeting the stack frame 2 or 3 function calls back, rather than the *current* frame. pgpUTlRvizmh1.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Exploiting buffer overflows via protected GCC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 valdis.kletni...@vt.edu wrote: On Fri, 13 Feb 2009 11:50:11 EST, Jason Starks said: memset(buf, 'A', 528); Don't do that. This sort of whoops is exactly what the gcc SSP canary is designed to stop. I have googled my brains out for a solution, but all I have gathered is that my Ubuntu's gcc is compiled with SSP and everytime I try to overwrite the return address it also overwrites the canary's value, and triggers a stop in the program. I've disassembled it and anybody who can help me probably doesn't need me to explain much more, but I would like to know a way to get this. There seems to be some people on this list who may know something on how to exploit on *nix systems with this protection enabled. What you want to do is be more precise in your splatting. Instead of one memset, see if you can come up with a way to do *two* memsets, which leave your stack looking like: 'A' (above the canary) 4 unmolested bytes of canary 'A' (below the canary) Of course, if you're trying to exploit already-existing code, you probably only have one memset/strcpy you can abuse, and the starting address of the destination is already nailed down, which means you need to fill in the 4 bytes of canary correctly. This means you need to find a way to obtain the value so you can use it. One hint - sometimes you're better off targeting the stack frame 2 or 3 function calls back, rather than the *current* frame. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ He was actually seeking for ways to bypass stack protection in gcc environments. There may be references at the web, reducing the entropy for prediction, brute-forcing or abusing signal handlers, could be a good starting point. I have little experience with gcc, ask Matt Miller. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJlbfFH+KgkfcIQ8cRAtR8AKCFeamGDKgIzqjZJZLRc+WaNMdhlQCg1fc3 z3u4YNF0Hkkv+4EydOkX1oo= =Gz91 -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Exploiting buffer overflows via protected GCC
On Fri, Feb 13, 2009 at 11:50:11AM -0500, Jason Starks wrote:
I came across a problem that I am sure many security researchers have seen
before:
ja...@uboo:~$ cat bof.c
#include stdio.h
#include string.h
int main()
{
char buf[512];
memset(buf, 'A', 528);
return 0;
}
ja...@uboo:~$
ja...@uboo:~$ ./bof
*** stack smashing detected ***: ./bof terminated
=== Backtrace: =
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7f08548]
ja...@uboo:~$
I have googled my brains out for a solution, but all I have gathered is that
my Ubuntu's gcc is compiled with SSP and everytime I try to overwrite the
return address it also overwrites the canary's value, and triggers a stop in
the program. I've disassembled it and anybody who can help me probably
doesn't need me to explain much more, but I would like to know a way to get
this. There seems to be some people on this list who may know something on
how to exploit on *nix systems with this protection enabled.
I do not want to just disable the protection and exploit it normally, I want
Perhaps you should learn first exactly _what_ caught your buffer overflow.
Hint: It was not SSP aka -fstack-protector.
Ciao, Marcus
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
