How can I get a buffer overflow in a global variable? - c

I'm working on detecting and preventing BOF attacks and I'd like to know, how can I overflow a global struct?
My code:
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
struct{
char name[20];
char description[10];
} test;
int main(int argc, char **argv){
if(argc != 2)
exit(-1);
*(*(argv+1)+20) = '\x00'; //terminate string after 20 characters
strcpy(test.name, argv[1]); //no BOF here... stopped at 20
printf("%s\n", test.name);
char *desc;
desc = malloc(10);
if(!desc){
printf("Error allocating memory\n");
exit(-1);
}
scanf("%s", desc); //no bounds checking - this is where I BOF
strcpy(test.description, desc); //copy over 10 characters into 10 char buffer
printf("%s\n", test.description); //this prints out whatever I type in
//even thousands of characters, despite it having a buffer of 10 chars
}

You overflow a global buffer the same way you do any other buffer type; you store more data in it than there are bytes allocated for it. Perhaps the question is "and what damage does that do?", and the answer is the usual: it depends.
Basically, when you overflow a specific global buffer, you write over some other global variables, and what happens next depends on whether the other variable is referenced again, and what it is supposed to hold. It won't, typically, have function return addresses and the like, so it can be more difficult to exploit.

char *desc = malloc(10);
scanf("%s", desc); //no bounds checking - this is where I BOF
strcpy(test.description, desc); //copy over 10 characters into 10 char buffer
One of the things you will need to address during testing on modern Linux systems are the calls to scanf and strcpy. Modern systems use FORTIFY_SOURCE, and it tries to remediate some classes of buffer overflows.
FORTIFY_SOURCE uses "safer" variants of high risk functions like memcpy and strcpy. The compiler uses the safer variants when it can deduce the destination buffer size. If the copy would exceed the destination buffer size, then the program calls abort().
To disable FORTIFY_SOURCE for your testing, you should compile the program with -U_FORTIFY_SOURCE or -D_FORTIFY_SOURCE=0.

Related

Reading 23 bytes even the buffer is of 10bytes

I know it's very dumb but I really don't get what the heck is happening here.
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
int getinput()
{
char buf[10];
int rv = read(0, buf, 1000);
printf("\nNumber of bytes read are %d\n", rv);
return 0;
}
int main()
{
getinput();
return 0;
}
I can't understand how this read() function is working.
read(0, buf, 1000)
Also, the buf is 10 bytes long why it is taking 23 bytes?
Array-pointer equivalence
In C, an array like the variable buf in your example is just a pointer to the memory address of the first allocated byte.
You can print the value of this pointer:
#include <stdio.h>
int main(void) {
char buf[10];
printf("Address of the first byte of buf: %p\n", buf);
return 0;
}
Output:
Address of the first byte of buf: 0x7ffd3699bfb6
Pointer arithmetic
When you write something into this buffer with an instruction like
buf[3] = 'Z';
It is in fact translated to
*(buf+3) = 'Z';
It means "add 3 to the value of the pointer buf and store the character 'Z' at the resulting address".
Nothing is stopping you from storing the character 'Z' at any given address. You can store it before or after the address pointed to by buf without any restriction. If the address you choose happen to be the address of another variable, it cannot produce a segmentation fault (the address is valid).
In C, you can even write the character 'Z' at the address 123456 if you like:
int main(void) {
char *address = (char *)123456;
*address = 'Z';
return 0;
}
The fact that your buffer is 10 bytes long does not change that. You cannot "fix" this because writing anything at any memory location is a fundamental feature of the C programming language. The only "fix" I can think of would be to use another language.
File descriptors opened at program startup
In your exemple, you pass the value 0 as the first argument of the function read(). It seems that this value corresponds to the file descriptor of the standard input. This file descriptor is automatically opened at program startup (normally you get such a file descriptor as the result of a call to the function open()). So, if you get 23 read bytes, it means that you typed in 23 characters on your keyboard during the program execution (for instance, 22 letters and 1 newline character).
It would be better to use the macro name of the standard input file descriptor:
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
int getinput()
{
char buf[10];
int rv = read(STDIN_FILENO, buf, 10);
printf("\nNumber of bytes read are %d\n", rv);
return 0;
}
int main()
{
getinput();
return 0;
}
your sample is a perfect example of a buffer overflow.
read(0, buff, 1000) will most probably corrupt the memory (stack on your case).
Read will take the start address of your buf pointer and will write those 23 bytes in your case... if there are some other structures on the memory they will be overwritten by those 13 bytes and can lead to very unwanted behavior (maybe even crashes of you application)
C gives the responsibility to handle memory correctly to the programmer. So there is no bounds checking.
You call read() with 3 arguments:
The file handle, in your case "0".
The pointer to the array of bytes to fill with the bytes read from the file, in your case buf.
The size of this array, in your case "1000".
Apparently the file has only 23 bytes, which is less or equal to 1000, so read() returns this value.
Note: But before, it happily wrote all these 23 bytes into the array. Since your buffer has just a capacity of 10 bytes, the memory after it gets overwritten. This is called "buffer overflow" and is a common error, abused for evil attacks, or possibly leading to crashes or malfunction (Thanks, ikegami!).
To fix this error, I recommend to change the read into:
read(0, buf, sizeof buf);
This way your are always giving the right size to read(). (If you declare buf as an array, of course.)

How to concatenate char pointers using strcat in c? [duplicate]

This question already has answers here:
Why do I get a segmentation fault when writing to a "char *s" initialized with a string literal, but not "char s[]"?
(19 answers)
Closed 3 years ago.
I'm learning pointers in C, using Linux. I'm trying to use the strcat function, but it doesn't work and I don't understand why.
I'm passing a username to the main as an argument because I need to concatenate and put a number 1 in the first position of this username. For example if the I got as argument username123 I need to convert this to 1username123
I got this code:
#include <stdio.h>
#include <string.h>
int main(int argc, char *arg[]){
const char *userTemp;
char *finalUser;
userTemp = argv[1]; //I got the argument passed from terminal
finalUser = "1";
strcat(finalUser, userTemp); //To concatenate userTemp to finalUser
printf("User: %s\n",finalUser);
return 0;
}
The code compiles, but I got a segmentation fault error and doesn't know why. Can you please help me going to the right direction?
It is undefined behaviour in C to attempt to modify a string literal (like "1"). Often, these are stored in non-modifiable memory to allow for certain optimisations.
Let's leave aside for the moment the fact that your entire program can be replaced with:
#include <stdio.h>
int main(int argc, char *argv[]){
printf("User: 1%s\n", (argc > 1) ? argv[1] : "");
return 0;
}
The way you ensure you have enough space is to create a buffer big enough to hold whatever you want to do. For example:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, char *argv[]){
// Check args provded.
if (argc < 2) {
puts("User: 1");
return 0;
}
// Allocate enough memory ('1' + arg + '\0') and check it worked.
char *buff = malloc(strlen(argv[1]) + 2);
if (buff == NULL) {
fprintf(stderr, "No memory\n");
return 1;
}
// Place data into memory and print.
strcpy(buff, "1");
strcat(buff, argv[1]);
printf("User: %s\n", buff);
// Free memory and return.
free(buff);
return 0;
}
What you shouldn't do is to allocate a fixed size buffer and blindly copy in the data provided by a user. That's how the vast majority of security problems occur, by people overwriting buffers with unexpected data.
I'm trying to use the strcat function, but it doesn't work and I don't understand why.
For starters, you really shouldn't use strcat(). Use strlcat() instead. The "l" version of this and other functions take an extra parameter that let you tell the function how large the destination buffer is, so that the function can avoid writing past the end of the buffer. strcat() doesn't have that parameter, so it relies on you to make sure the buffer is large enough to contain both strings. This is a common source of security problems in C code. The "l" version also makes sure that the resulting string is null-terminated.
The code compiles, but I got a segmentation fault error and doesn't know why.
Here's the prototype for the function: char *strcat( char *dest, const char *src );
Now, you're calling that essentially like this: strcat("1", someString);. That is, you're trying to append someString to "1", which is a string constant. There's no extra room in "1" for whatever string is in someString, and because you're using a function that will happily write past the end of the destination buffer, your code is effectively writing over whatever happens to be in memory next to that string constant.
To fix the problem, you should:
Switch to strlcat().
Use malloc() or some other means to allocate a destination buffer large enough to hold both strings.
Unlike in other languages there is no real string type in C.
You want this:
#include <stdio.h>
#include <string.h>
int main(int argc, char *arg[]){
const char *userTemp;
char finalUser[100]; // finalUser can contain at most 99 characters
userTemp = argv[1]; //I got the argument passed from terminal
strcpy(finalUser, "1"); // copy "1" into the finalUser buffer
strcat(finalUser, userTemp); //To concatenate userTemp to finalUser
printf("User: %s\n",finalUser);
return 0;
}
or even simpler:
#include <stdio.h>
#include <string.h>
int main(int argc, char *arg[]){
char finalUser[100]; // finalUser can contain at most 99 characters
strcpy(finalUser, "1"); // copy "1" into the finalUser buffer
strcat(finalUser, argv[1]); //To concatenate argv[1] to finalUser
printf("User: %s\n",finalUser);
return 0;
}
Disclaimer: for the sake of brevity this code contains a fixed size buffer and no check for buffer overflow is done here.
The chapter dealing with strings in your C text book should cover this.
BTW you also should check if the program is invoked with an argument:
int main(int argc, char *arg[]){
if (argc != 2)
{
printf("you need to provide a command line argument\n");
return 1;
}
...
You're missing some fundamentals about C.
finalUser = "1";
This is created in "read-only" memory. You cannot mutate this. The first argument of strcat requires memory allocated for mutation, e.g.
char finalUser[32];
finalUser[0] = '1';

What is the vulnerability in this C code?

I'm trying to understand buffer overflow attacks better, this is one of the exercises that came up, that has a buffer overflow vulnerability. I would like to know how one can exploit the vulnerability in this code.
I wasn't sure how to search for it.
int
main(int argc, char **argv)
{
(void) foo(argv[1]);
exit(0);
}
int
foo(char *arg)
{
return bar(arg);
}
int
bar(char *arg)
{
char lbuf[1024];
if (strlen(arg) >= 1024)
return -1;
memset(lbuf, 0, sizeof(lbuf));
sprintf(lbuf, "%s", "Welcome: ");
read(0, lbuf + strlen(lbuf), sizeof(lbuf) - strlen(lbuf) - 1);
printf(lbuf);
fflush(stdout);
return 0;
}
There is no buffer-overflow there, at all. But that doesn't mean it's secure.
The problem you are expected to find is this line:
printf(lbuf);
Whenever you provide a format-string, make sure it is safely under your control and only asks for those arguments you provided. Accessing arguments not provided, or of the wrong type, results in undefined behavior (all kinds of bizarre and potentially dangerous things can happen). Additionally, one can use %n to poke some memory, which is more obviously dangerous.
In this case, lbuf contains Welcome: followed by arbitrary insecure user-input.
In addition, the program unconditionally reads argv[1] (assumption argc > 0), and further assumes it points to a string (assumption argc > 1) when passing it to strlen().
Your code is just an UB without any possible hacks (if we consider only the buffer overflow and will analyze any other possible ones).
Buffer overflow to be used a attacking technique must overwrite some data used later in the program. It may be changing the variables, or placing some code (less common but possible)
an example:
#include <stdio.h>
#include <string.h>
int CheckPassword(void)
{
char passwd[5];
int passwordcorect = 0;
printf("Enter password:");
gets(passwd);
if(!strcmp(passwd, "1234"))
{
passwordcorect = 1;
}
return passwordcorect;
}
int main()
{
if(CheckPassword())
{
printf("\nSpecial priviledges granted!!\n");
}
else
{
printf("\nWrong!!\n");
}
return 0;
}
Compiled with mingw.
And the result:
Why did it happen? Because the buffer has overwritten the passwordcorrect variable. It is system, implementation etc related but hacking is not something abstract or portable :)

Retrieve information using stack buffer overflow (C)

I found one interesting exercises on the net, it states that the specific input can overflow the buffer in such a way that the 'secret' will be printed to stdout.
I tried to figure it out by my self but I haven't done well.
Here is the code:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
void get_name(char *name, char *pr) {
char local[20];
printf("%s:",pr);
gets(local);// BUG
strncat(name,local,20);
}
int foo () {
char name[28]="Hello..";
char secret[12]="TOP SECRET";
char buf[24];
char n1[]="Enter your name";
char n2[]="Enter Secret code";
get_name(name,n1);
memset(buf, 0, sizeof(buf));
// Lets ONLY use strncpy for better control!!!
strncpy(buf, name, sizeof(buf));//BUG
printf("%s\n", buf);
memset(name,0,sizeof(name));
get_name(name, n2);
if (strncmp(secret,name,10)==0)
printf("Welcome and %s\n",buf);
else {printf("Wrong code, better try again..\n");}
return 0;
}
int main(int argc, char **argv)
{
foo();
printf("Bye\n");
return 0;
}
There is no way to know what the outcome of such buffer overflows will do. You can't know or assume what memory they will overwrite. Most likely they will only cause some sort of run-time crash. Any exploit would have to have a very specific system in mind. Which means that nobody would be able to answer your question without knowing the details of a given system.
What your "random internet person" is aiming for, is likely to overwrite the null termination of Hello.. with some garbage, so that the "TOP SECRET" string will get printed along with it. You can't assume that those two strings are allocated adjacently, however. You could try to type 28 letter long input to gets and see what happens... there are no guarantees of any given behavior. On my computer it does nothing exciting apart from printing some garbage. Reverse-engineering of my binary reveals that that's because the arrays are indeed not allocated adjacently.
In addition, your comments about strncpy are misguided, strncpy is dangerous and should be avoided, see this.

Malloc and scanf

I'm fairly competent in a few scripting languages, but I'm finally forcing myself to learn raw C. I'm just playing around with some basic stuff (I/O right now). How can I allocate heap memory, store a string in the allocated memory, and then spit it back out out? This is what I have right now, how can I make it work correctly?
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
char *toParseStr = (char*)malloc(10);
scanf("Enter a string",&toParseStr);
printf("%s",toParseStr);
return 0;
}
Currently I'm getting weird output like '8'\'.
char *toParseStr = (char*)malloc(10);
printf("Enter string here: ");
scanf("%s",toParseStr);
printf("%s",toParseStr);
free(toParseStr);
Firstly, the string in scanf is specifies the input it's going to receive. In order to display a string before accepting keyboard input, use printf as shown.
Secondly, you don't need to dereference toParseStr since it's pointing to a character array of size 10 as you allocated with malloc. If you were using a function which would point it to another memory location, then &toParseStr is required.
For example, suppose you wanted to write a function to allocate memory. Then you'd need &toParseStr since you're changing the contents of the pointer variable (which is an address in memory --- you can see for yourself by printing its contents).
void AllocateString(char ** ptr_string, const int n)
{
*ptr_string = (char*)malloc(sizeof(char) * n);
}
As you can see, it accepts char ** ptr_string which reads as a pointer which stores the memory location of a pointer which will store the memory address (after the malloc operation) of the first byte of an allocated block of n bytes (right now it has some garbage memory address since it is uninitialized).
int main(int argc, char *argv[])
{
char *toParseStr;
const int n = 10;
printf("Garbage: %p\n",toParseStr);
AllocateString(&toParseStr,n);
printf("Address of the first element of a contiguous array of %d bytes: %p\n",n,toParseStr);
printf("Enter string here: ");
scanf("%s",toParseStr);
printf("%s\n",toParseStr);
free(toParseStr);
return 0;
}
Thirdly, it is recommended to free memory you allocate. Even though this is your whole program, and this memory will be deallocated when the program quits, it's still good practice.
You need to give scanf a conversion format so it knows you want to read a string -- right now, you're just displaying whatever garbage happened to be in the memory you allocated. Rather than try to describe all the problems, here's some code that should at least be close to working:
char *toParseStr = malloc(10);
printf("Enter a string: ");
scanf("%9s", toParseStr);
printf("\n%s\n", toParsestr);
/* Edit, added: */
free(toParseStr);
return 0;
Edit: In this case, freeing the string doesn't make any real difference, but as others have pointed out, it is a good habit to cultivate nonetheless.
Using scanf() (or fscanf() on data you don't control) with a standard "%s" specifier is a near-certain way to get yourself into trouble with buffer overflows.
The classic example is that it I enter the string "This string is way more than 10 characters" into your program, chaos will ensue, cats and dogs will begin sleeping together and a naked singularity may well appear and consume the Earth (most people just state "undefined behaviour" but I think my description is better).
I actively discourage the use of functions that cannot provide protection. I would urge you (especially as a newcomer to C) to use fgets() to read your input since you can control buffer overflows with it a lot easier, and it's more suited to simple line input than scanf().
Once you have a line, you can then call sscanf() on it to your heart's content which, by the way, you don't need to do in this particular case since you're only getting a raw string anyway.
I would use:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define BUFFSZ 10
int main(int argc, char *argv[]) {
char *toParseStr = malloc(BUFFSZ+2);
if (toParseStr == NULL) {
printf ("Could not allocate memory!\n");
return 1;
}
printf ("Enter a string: ");
if (fgets (toParseStr, BUFFSZ+2, stdin) == NULL) {
printf ("\nGot end of file!\n");
return 1;
}
printf("Your string was: %s",toParseStr);
if (toParseStr[strlen (toParseStr) - 1] != '\n') {
printf ("\nIn addition, your string was too long!\n");
}
free (toParseStr);
return 0;
}
You don't need an & before toParseStr in scanf as it is already a pointer
also call free(toParseStr) afterwards
First, the errors that was keeping your program from working: scanf(3) takes a format-string, just like printf(3), not a string to print for the user. Second, you were passing the address of the pointer toParseStr, rather than the pointer toParseStr.
I also removed the needless cast from your call to malloc(3).
An improvement that your program still needs is to use scanf(3)'s a option to allocate memory for you -- so that some joker putting ten characters into your string doesn't start stomping on unrelated memory. (Yes, C will let someone overwrite almost the entire address space with this program, as written. Giant security flaw. :)
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
char *toParseStr = malloc(10);
printf("Enter a short string: ");
scanf("%s",toParseStr);
printf("%s\n",toParseStr);
return 0;
}

Resources