Pantek Library
Hosting Provided By
CybrHost
High Speed Hosting
Mailing Lists: securityfocus.com > vuln-dev > 03 > 030304.html (Request Expert securityfocus.com Support)

RE: Automatic discovery of shellcode address

From: Adam Gilmore <vuln(at)optusnet.com.au>
Date: Mon Mar 24 2003 - 08:44:08 EST


Erm, correct me if I'm wrong, but the idea of placing your shellcode (prepended with x number of NOPs) and then filling the rest of your buffer with the address of the shellcode is a very old idea and very commonly used.

In fact I'm sure you'd find the vast majority of normal stack overflow exploits using this idea.

Also, I find an easier method to find the shellcode address is trial and error. i.e. gdb ./myprog, run `perl -e'print "A"x1000'` - wait for the segfault, take a look at esp/ebp then do a dump of say.. x/255xb. Chances are if you subtract/add a little with either esp or ebp, you're bound to find your 0x41 0x41 0x41 somewhere =)

Another interesting method is to use ptrace. Have a look at nslconf.c on packetstorm which uses this method to find the shellcode. Quite nifty.

-----Original Message-----
From: steve@uk.intasys.com [mailto:steve@uk.intasys.com] Sent: Saturday, 22 March 2003 10:19 AM
To: vuln-dev@securityfocus.com
Subject: Automatic discovery of shellcode address

Hi,

  I've been playing around with LD_PRELOAD under Linux to modify  some functions commonly susceptible to buffer overflows, strcpy,  sprintf, etc.

  During the course of this work I had an interesting idea, and  I thought I'd post it here for comments.

Do you need help?X

  There are many programs which are exploitable via user supplied  variables such as command line arguments, and environmental variables.

  When these inputs are not adequately bounds tested they can be  used to subvert control flow.

  A common method of exploitation is to run a program with a long  argument, and see if EIP is overtaken, for example:

         /usr/bin/foo `perl -e "print 'a' x 1000'`

  If this is vulnerable you'd see something like "cannot access memory  at 0x41414141". This indicated that you've managed to overwrite  ESP, with an address you control.

  After that it's endgame - it's just a matter of working out where  your shellcode may be placed and the magic offsets to modify to  point to it.

  Whilst this isn't terribly difficult it's a time consuming and  fragile process. (Maybe that's just me!)

  It occurs to me that if you know where the buffer in memory which  you're overflowing is, (in the case of sprintf, strcpy etc), you  might be able to cheat.

Do you need more help?X

  Knowing the direction the stack goes down all you need to do  is overwrite the memory with: 

 	# shellcode
	# address of the start of the buffer x 1000

  If the start of the buffer being copied to is know then stick the  shellcode there, and afterwards just append that address, so that  all the likely return pointers are left sticking at your shellcode  in a known location.

  How do you get the address of the buffer in the first place?  Use LD_PRELOAD to modify 'strcpy', 'sprintf' to display the address  they're writing to. Simple.

  (OK LD_PRELOAD doesn't work for setuid binaries, but typically  copying the target to your machine will work, and you're safe as  the displayed addresses won't change).

  Does this sound reasonable, or am I imagining things?

  I wrote a small textfile on it, available below, (note it's  still work in progress):

         http://www.steve.org.uk/Hacks/preload.txt

Steve 

---
www.steve.org.uk
Received on Mon Mar 24 13:14:55 2003
Can we help you?X

This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:07:38 EDT

Contact Us  Legal Notices  Order Services Online 
Pantek Home  Privacy Policy  IT news  Site Map  Pantek Library