exploitable code?

exploitable code?

[jnf]

hi, ive got a question, is this code exploitable?

int main(int argc, char **argv) {
char buf[256];

strcpy(buf,argv[1]);
exit(1);
}

everything i read says yes, but i cant seem to get it. I don't see any way of overwriting esp for ret, so as far as i can tell i must go into the exit function, and exit comes before leave, so i cant land to arb. code. So am I just dumb, or am I playing with code that isnt exploitable?

fyi, this isnt an actual program but a program created for educational purposes.
thx
j

_____________________________________________________________
Sign up for FREE email from DoItYourself.com at http://doityourself.com

_____________________________________________________________
Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net  http://www.everyone.net/?btn=tag

Re: exploitable code?

[Stephen Satchell]

At 08:38 PM 6/30/02 -0700, jnf wrote:
>hi, ive got a question, is this code exploitable?
>
>int main(int argc, char **argv) {
>char buf[256];
>
>strcpy(buf,argv[1]);
>exit(1);
>}
>
>everything i read says yes, but i cant seem to get it. I don't see any way 
>of overwriting esp for ret, so as far as i can tell i must go into the 
>exit function, and exit comes before leave, so i cant land to arb. code. 
>So am I just dumb, or am I playing with code that isnt exploitable?
>
>fyi, this isnt an actual program but a program created for educational 
>purposes.
>thx

The exit function may well be a "long jump" that uses the return value for 
the function "main" as its target.  Therefore, when the exploiting code 
overwrites the return address for "main" the "exit" call will use the 
overwritten value.

Too bad people aren't required as a matter of course to look at the 
assembler output of code from compilers anymore.  You learn a lot seeing 
how your statements get translated to machine code.

Satch

Re: exploitable code?

[jnf]

>The exit function may well be a "long jump" that uses the return value for 
>the function "main" as its target.  Therefore, when the exploiting code 
>overwrites the return address for "main" the "exit" call will use the 
>overwritten value.

every value i overwrite is pushed onto the stack and the next used again, the overwritten ret address is fine for main, but exit never returns, i just went through all of exit today and was hoping to find like
pop %eax
jmp %eax

or something to break out of exit, but i didnt find it, So perhaps i missed it, or missed something in strcpy, but exit never returns so that is the problem.

>
>Too bad people aren't required as a matter of course to look at the 
>assembler output of code from compilers anymore.  You learn a lot seeing 
>how your statements get translated to machine code.

if you only knew how much ive learned just getting to this point. I totally agree.


>Satch

j


_____________________________________________________________
Sign up for FREE email from DoItYourself.com at http://doityourself.com

_____________________________________________________________
Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net  http://www.everyone.net/?btn=tag

Re: exploitable code?

[Glynn Clements]

jnf wrote:

> hi, ive got a question, is this code exploitable?
> 
> int main(int argc, char **argv) {
> char buf[256];
> 
> strcpy(buf,argv[1]);
> exit(1);
> }

Possibly.

> everything i read says yes, but i cant seem to get it. I don't see any
> way of overwriting esp for ret, so as far as i can tell i must go into
> the exit function, and exit comes before leave, so i cant land to arb. 
> code. So am I just dumb, or am I playing with code that isnt
> exploitable?

You have no idea what may be stored on the stack above main()'s stack
frame. It's quite possible that it contains data which will be used by
the run-time's termination code.

From the perspective of writing secure code, the solution is simply to
ensure that the buffer can't be overrun. From the perspective of
writing an exploit, you would need to understand the workings of the
run-time against which the program was linked.

-- 
Glynn Clements <glynn.clements@virgin.net>