Go Back   Xisp.org Forums > Porn Password Cracking > Porn Password Cracking Help Section

calculating return addresses for buffer overflow exploits

Reply
Views: 880 - Replies: 2  
Thread Tools Display Modes

calculating return addresses for buffer overflow exploits
Old 03-20-2006, 12:16 PM   #1
Permutant
Banned
 
Permutant is offline Offline
Join Date: Jan 2006
Posts: 178
Threads: 23
Permutant is on a distinguished road
Default calculating return addresses for buffer overflow exploits

When exploiting a typical buffer overflow vulnerability where user input is copied into a local buffer without boundary checking, the best way to fill the stack is probably

local buffer | old base pointer value | return address
NOP NOP NOP ... NOP (SHELL)CODE FAKE RETURN ADDRESS

Where NOP stand for the target machine's no operation instruction opcode, and FAKE RETURN ADDRESS has to be a memory address, hopefully the address of one of the NOPs, so that the injected (SHELL)CODE will be executed once the function tries to return. The problem now is finding an appropriate value for FAKE RETURN ADDRESS ... The best thing I can think of is guessing the current stack pointer value and subtracting the size of the local variables defined before the buffer + half of the buffer size. That will only work if you do a good job in guessing the stack pointer value, though, and that's tough since the height of the stack depends on the programs running on the target machine and is changing since programs are usually busy calling and returning from subroutines ... So, are there any hints for guessing the stack pointer value? Or is there a better method for calculating the address of your nops?

Last edited by Permutant; 03-20-2006 at 07:46 PM..
  Reply With Quote

Old 04-20-2006, 04:46 PM   #2
Permutant
Banned
 
Permutant is offline Offline
Join Date: Jan 2006
Posts: 178
Threads: 23
Permutant is on a distinguished road
Lightbulb

I did some more research on the topic and found some information and URLs that seem to be worth sharing, I'll start with a buffer overflow exploit variation called return to libc. In this one, you basically overwrite the return address with the address of a function or opcode you wish to execute within the address space of the vulnerable process.

For example, the return address could be overwritten with a memory address containing the opcode for "jmp esp", in order to have code you've put on the stack executed.

Another nice possibility is calling the function system() with arguments you've prepared on the stack, I heard there are some nasty people out there who use this for binding a shell to a port or other evil deeds

Advantages of this method are:
- you can exploit overflow vulnerabilities in much smaller buffers
- you don't have to guess address of injected NOPs
- you can exploit overflows on non executable stacks (note that in the system() example, not a single instruction on the stack is executed!)

Disadvantages are:
- You aren't as flexible with the code you want to have executed; you're limited to abusing the instructions flying around in a given address space in combination with stuff you can place on the stack.
- You can't always do this since you have to be able to figure out the absolute address of a usable piece of code after all.

Here's a detailed description of the attack:
http://www.infosecwriters.com/text_resources/pdf/return-to-libc.pdf

A short discussion about it from the Vulnerability Development mailing list (with interesting comments about when it makes sense to use the attack in the second reply) :
http://seclists.org/lists/vuln-dev/2004/Mar/0028.html

And here's the mentioned database from the metasploit website with usable addresses in windows modules:
http://metasploit.com/users/opcode/msfopcode.cgi

An interesting tutorial about exploiting buffer overflow vulnerabilities on the heap instead of the stack:
http://www.w00w00.org/files/articles/heaptut.txt

And, finally, what appears to be another way for improving the stability of a buffer overflow exploit for win32 applications (Frankly, I hardly understand a word of that one, I think some knowledge about win32 system programing (keyword event handling) comes in handy here - but for now, I have an input overflow )
http://www.securiteam.com/securityreviews/6Y00H20BPA.html
  Reply With Quote

Old 04-23-2006, 10:34 AM   #3
therealshp
Poor Replier
 
therealshp is offline Offline
Join Date: Jan 2006
Posts: 158
Threads: 12
therealshp is on a distinguished road
Default

Great stuff, thank you.
  Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump



All times are GMT -4. The time now is 04:24 PM.


vBulletin skin developed by: Xisp.org Crew
Powered by vBulletin®
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
2005 Copyright Xisp.org