I am trying to do a buffer-overflow for my security class, we are not allowed to call any function and we need to jump to secret function and also return 0 without segmentation fault. I wrote the code below and successfully jumped to secret but I am getting a segmentation fault. How can I terminate the program successfully? Or is it possible to just write to a single address instead of for loop, when I tried it did not change anything.
#include <stdio.h>
void secret()
{
printf("now inside secret()!\n");
}
void entrance()
{
int doNotTouch[10];
// can only modify this section BEGIN
// cant call secret(), maybe use secret (pointer to function)
for (int i = 0; i < 14; i++) {
*(doNotTouch + i) = (int) &secret;
}
// can only modify this section END
printf("now inside entrance()!\n");
}
int main (int argc, char *argv[])
{
entrance();
return 0;
}
In some semi-assembler, assuming some kind of x86. (BP is pseudocode for EBP or RBP, assuming you're not actually compiling for 16-bit mode. 32-bit mode is likely so int is the same width as a return address.)
; entrance:
; - stack has return address to main
push bp ; decrement SP by a pointer width
mov bp,sp
sub sp, 10*sizeof(int) ; reserve space for an array
;....
; doNotTouch[0] is probably at [bp - 10*sizeof(int)]
When you loop to 14, you first overwrite the saved bp at i==10 and then the return address to main (which is correct) and then overwrite some more which eventually causes the seg fault. So you only need to do *(doNotTouch + 11) = (int) &secret; - assuming int is the size of a function pointer. (Or a bit more if the compiler left a gap for stack-alignment or its own use. In a debug build other locals will have stack slots. Overwriting them could lead to an infinite loop that goes out of bounds.)
Then follows your printf and then the function returns, but it does not return to main but "jumps" to secret.
When secret returns, it is actually now the return from main but it couldn't do the return 0;
So secret should be:
int secret()
{
printf("now inside secret()!\n");
return 0;
}
Disclaimer: "....I think."
Related
The following code is for the lab https://cs50.harvard.edu/x/2021/labs/1/population/.
#include <cs50.h>
#include <stdio.h>
int main(void)
{
//Prompt for start size
int startPop;
do
{
startPop = get_int("Starting population: ");
}
while (startPop < 9);
//Prompt for end size
int endPop;
do
{
endPop = get_int("Ending population: ");
}
while (endPop < startPop);
int Years = 0;
while (startPop < endPop)
{
startPop = startPop + (startPop/3) - (startPop/4);
Years++;
}
printf("Total Years: %i", Years);
}
Why isn't return used after each integer is received? Like this
int startPop;
do
{
startPop = get_int("Starting population: ");
}
while (startPop < 9);
return startPop;
How do I know when and where to use it? What is the purpose of return?
It seems like every time I try to solve a problem I am completely off base and don't even know where/how to begin, even after hours of thinking about it and then the solution also mystifies me.
return will exit the function that you are currently in, and the remainder of the function will not execute. It may also return a value from that function, if it is a non-void function. Here is an example:
int main(void)
{
foo()
}
void foo()
{
//...some code...
return;
//..some more code...
}
In this case foo will be called and will run until it hits the return, at which point the execution will return to main, and all the code in foo after main will not execute.
In your program, there is only one function (main), and calling return from main will exit the program (not what we want in this case).
The return XX at the end of main is not necessary because the C standard says so:
C18 §5.1.2.2.3 Program termination
... reaching the } that terminates the main function returns a value of 0.
In other words, if there is no return xx the int main() function is presumed to return 0.
For all other functions that return a value, the function must explicitly return a value.
For void functions, the return statement is optional.
Return is the C syntax to tell the assembler to create a ret instruction.
What is a ret instruction? From Intel's x86 manual:
RET — Return from Procedure
Transfers program control to a return address located on the top of the stack. The address is usually placed on the stack by a CALL instruction, and the return is made to the instruction that follows the CALL instruction.
When you call and return from a function (here called a procedure), in reality you are executing the following code at assembly level:
push rbp // push rbp (base pointer) to the stack
mov rbp, rsp // store rsp (stack pointer) into rbp.
...
mov rsp, rbp // get back the value of rsp
pop rbp // pop rbp from the stack
ret
"The caller" is the original function in which the call to the other function, "the callee" happens.
Note that by default the C language will asssume (rightfully) that every function has a return point, and that is why for void function, as well as for main, a written return is not necessary.
The return along with a value (let say 20) is translated as (intel syntax):
mov eax, 20
ret
What is the relationship with your question?
In your example, there is no call to a callee function, you are executing code inside your function (the same as what would happen if you add "inline") so the the variable you are currently calculating startPop doesn't need a return.
PS: On a side note, having a do while with = does not make a lot of sense.
I want to, as the title says, print the contents of the stack in my C program.
Here are the steps I took:
I made a simple assembly (helper.s) file that included a function to return the address of my ebp register and a function to return the address of my esp register
.globl get_esp
get_esp:
movl %esp, %eax
ret
# get_ebp is defined similarly, and included in the .globl section
I called the get_esp () and get_ebp () functions from my C program ( fpC = get_esp (); where fpC is an int)
I (successfully, I think) printed the address of my esp and ebp registers ( fprintf (stderr, "%x", fcP); )
I tried, and failed to, print out the contents of my esp register. (I tried fprintf (sderr, "%d", *fcP); and fprintf (sderr, "%x", *((int *)fcP));, among other methods). My program hits a segmentation fault at runtime when this line is processed.
What am I doing wrong?
EDIT: This must be accomplished by calling these assembly functions to get the stack pointers.
EDIT2: This is a homework assignment.
If your utilising a GNU system, you may be able to use GNU's extension to the C library for dealing backtraces, see here.
#include <execinfo.h>
int main(void)
{
//call-a-lot-of-functions
}
void someReallyDeepFunction(void)
{
int count;
void *stack[50]; // can hold 50, adjust appropriately
char **symbols;
count = backtrace(stack, 50);
symbols = backtrace_symbols(stack, count);
for (int i = 0; i < count; i++)
puts(symbols[i]);
free(symbols);
}
get_esp returns esp as it is within the function. But this isn't the same as esp in the calling function, because the call operation changes esp.
I recommend replacing the function with a piece of inline assembly. This way esp won't change as you try to read it.
Also, printing to sderr wouldn't help. From my experience, stderr works much better.
I'm attempting to write a simple buffer overflow using C on Mac OS X 10.6 64-bit. Here's the concept:
void function() {
char buffer[64];
buffer[offset] += 7; // i'm not sure how large offset needs to be, or if
// 7 is correct.
}
int main() {
int x = 0;
function();
x += 1;
printf("%d\n", x); // the idea is to modify the return address so that
// the x += 1 expression is not executed and 0 gets
// printed
return 0;
}
Here's part of main's assembler dump:
...
0x0000000100000ebe <main+30>: callq 0x100000e30 <function>
0x0000000100000ec3 <main+35>: movl $0x1,-0x8(%rbp)
0x0000000100000eca <main+42>: mov -0x8(%rbp),%esi
0x0000000100000ecd <main+45>: xor %al,%al
0x0000000100000ecf <main+47>: lea 0x56(%rip),%rdi # 0x100000f2c
0x0000000100000ed6 <main+54>: callq 0x100000ef4 <dyld_stub_printf>
...
I want to jump over the movl instruction, which would mean I'd need to increment the return address by 42 - 35 = 7 (correct?). Now I need to know where the return address is stored so I can calculate the correct offset.
I have tried searching for the correct value manually, but either 1 gets printed or I get abort trap – is there maybe some kind of buffer overflow protection going on?
Using an offset of 88 works on my machine. I used Nemo's approach of finding out the return address.
This 32-bit example illustrates how you can figure it out, see below for 64-bit:
#include <stdio.h>
void function() {
char buffer[64];
char *p;
asm("lea 4(%%ebp),%0" : "=r" (p)); // loads address of return address
printf("%d\n", p - buffer); // computes offset
buffer[p - buffer] += 9; // 9 from disassembling main
}
int main() {
volatile int x = 7;
function();
x++;
printf("x = %d\n", x); // prints 7, not 8
}
On my system the offset is 76. That's the 64 bytes of the buffer (remember, the stack grows down, so the start of the buffer is far from the return address) plus whatever other detritus is in between.
Obviously if you are attacking an existing program you can't expect it to compute the answer for you, but I think this illustrates the principle.
(Also, we are lucky that +9 does not carry out into another byte. Otherwise the single byte increment would not set the return address how we expected. This example may break if you get unlucky with the return address within main)
I overlooked the 64-bitness of the original question somehow. The equivalent for x86-64 is 8(%rbp) because pointers are 8 bytes long. In that case my test build happens to produce an offset of 104. In the code above substitute 8(%%rbp) using the double %% to get a single % in the output assembly. This is described in this ABI document. Search for 8(%rbp).
There is a complaint in the comments that 4(%ebp) is just as magic as 76 or any other arbitrary number. In fact the meaning of the register %ebp (also called the "frame pointer") and its relationship to the location of the return address on the stack is standardized. One illustration I quickly Googled is here. That article uses the terminology "base pointer". If you wanted to exploit buffer overflows on other architectures it would require similarly detailed knowledge of the calling conventions of that CPU.
Roddy is right that you need to operate on pointer-sized values.
I would start by reading values in your exploit function (and printing them) rather than writing them. As you crawl past the end of your array, you should start to see values from the stack. Before long you should find the return address and be able to line it up with your disassembler dump.
Disassemble function() and see what it looks like.
Offset needs to be negative positive, maybe 64+8, as it's a 64-bit address. Also, you should do the '+7' on a pointer-sized object, not on a char. Otherwise if the two addresses cross a 256-byte boundary you will have exploited your exploit....
You might try running your code in a debugger, stepping each assembly line at a time, and examining the stack's memory space as well as registers.
I always like to operate on nice data types, like this one:
struct stackframe {
char *sf_bp;
char *sf_return_address;
};
void function() {
/* the following code is dirty. */
char *dummy;
dummy = (char *)&dummy;
struct stackframe *stackframe = dummy + 24; /* try multiples of 4 here. */
/* here starts the beautiful code. */
stackframe->sf_return_address += 7;
}
Using this code, you can easily check with the debugger whether the value in stackframe->sf_return_address matches your expectations.
I want to skip a line in C, the line x=1; in the main section using bufferoverflow; however, I don't know why I can not skip the address from 4002f4 to the next address 4002fb in spite of the fact that I am counting 7 bytes form <main+35> to <main+42>.
I also have configured the options the randomniZation and execstack environment in a Debian and AMD environment, but I am still getting x=1;. What it's wrong with this procedure?
I have used dba to debug the stack and the memory addresses:
0x00000000004002ef <main+30>: callq 0x4002a4 **<function>**
**0x00000000004002f4** <main+35>: movl $0x1,-0x4(%rbp)
**0x00000000004002fb** <main+42>: mov -0x4(%rbp),%esi
0x00000000004002fe <main+45>: mov $0x4629c4,%edi
void function(int a, int b, int c)
{
char buffer[5];
int *ret;
ret = buffer + 12;
(*ret) += 8;
}
int main()
{
int x = 0;
function(1, 2, 3);
x = 1;
printf("x = %i \n", x);
return 0;
}
You must be reading Smashing the Stack for Fun and Profit article. I was reading the same article and have found the same problem it wasnt skipping that instruction. After a few hours debug session in IDA I have changed the code like below and it is printing x=0 and b=5.
#include <stdio.h>
void function(int a, int b) {
int c=0;
int* pointer;
pointer =&c+2;
(*pointer)+=8;
}
void main() {
int x =0;
function(1,2);
x = 3;
int b =5;
printf("x=%d\n, b=%d\n",x,b);
getch();
}
In order to alter the return address within function() to skip over the x = 1 in main(), you need two pieces of information.
1. The location of the return address in the stack frame.
I used gdb to determine this value. I set a breakpoint at function() (break function), execute the code up to the breakpoint (run), retrieve the location in memory of the current stack frame (p $rbp or info reg), and then retrieve the location in memory of buffer (p &buffer). Using the retrieved values, the location of the return address can be determined.
(compiled w/ GCC -g flag to include debug symbols and executed in a 64-bit environment)
(gdb) break function
...
(gdb) run
...
(gdb) p $rbp
$1 = (void *) 0x7fffffffe270
(gdb) p &buffer
$2 = (char (*)[5]) 0x7fffffffe260
(gdb) quit
(frame pointer address + size of word) - buffer address = number of bytes from local buffer variable to return address
(0x7fffffffe270 + 8) - 0x7fffffffe260 = 24
If you are having difficulties understanding how the call stack works, reading the call stack and function prologue Wikipedia articles may help. This shows the difficulty in making "buffer overflow" examples in C. The offset of 24 from buffer assumes a certain padding style and compile options. GCC will happily insert stack canaries nowadays unless you tell it not to.
2. The number of bytes to add to the return address to skip over x = 1.
In your case the saved instruction pointer will point to 0x00000000004002f4 (<main+35>), the first instruction after function returns. To skip the assignment you need to make the saved instruction pointer point to 0x00000000004002fb (<main+42>).
Your calculation that this is 7 bytes is correct (0x4002fb - 0x4002fb = 7).
I used gdb to disassemble the application (disas main) and verified the calculation for my case as well. This value is best resolved manually by inspecting the disassembly.
Note that I used a Ubuntu 10.10 64-bit environment to test the following code.
#include <stdio.h>
void function(int a, int b, int c)
{
char buffer[5];
int *ret;
ret = (int *)(buffer + 24);
(*ret) += 7;
}
int main()
{
int x = 0;
function(1, 2, 3);
x = 1;
printf("x = %i \n", x);
return 0;
}
output
x = 0
This is really just altering the return address of function() rather than an actual buffer overflow. In an actual buffer overflow, you would be overflowing buffer[5] to overwrite the return address. However, most modern implementations use techniques such as stack canaries to protect against this.
What you're doing here doesn't seem to have much todo with a classic bufferoverflow attack. The whole idea of a bufferoverflow attack is to modify the return adress of 'function'. Disassembling your program will show you where the ret instruction (assuming x86) takes its adress from. This is what you need to modify to point at main+42.
I assume you want to explicitly provoke the bufferoverflow here, normally you'd need to provoke it by manipulating the inputs of 'function'.
By just declaring a buffer[5] you're moving the stackpointer in the wrong direction (verify this by looking at the generated assembly), the return adress is somewhere deeper inside in the stack (it was put there by the call instruction). In x86 stacks grow downwards, that is towards lower adresses.
I'd approach this by declaring an int* and moving it upward until I'm at the specified adress where the return adress has been pushed, then modify that value to point at main+42 and let function ret.
You can't do that this way.
Here's a classic bufferoverflow code sample. See what happens once you feed it with 5 and then 6 characters from your keyboard. If you go for more (16 chars should do) you'll overwrite base pointer, then function return address and you'll get segmentation fault. What you want to do is to figure out which 4 chars overwrite the return addr. and make the program execute your code. Google around linux stack, memory structure.
void ff(){
int a=0; char b[5];
scanf("%s",b);
printf("b:%x a:%x\n" ,b ,&a);
printf("b:'%s' a:%d\n" ,b ,a);
}
int main() {
ff();
return 0;
}
The code below is just not working.
Can anybody point out why
#define STACK_SIZE 1524
static void mt_allocate_stack(struct thread_struct *mythrd)
{
unsigned int sp = 0;
void *stck;
stck = (void *)malloc(STACK_SIZE);
sp = (unsigned int)&((stck));
sp = sp + STACK_SIZE;
while((sp % 8) != 0)
sp--;
#ifdef linux
(mythrd->saved_state[0]).__jmpbuf[JB_BP] = (int)sp;
(mythrd->saved_state[0]).__jmpbuf[JB_SP] = (int)sp-500;
#endif
}
void mt_sched()
{
fprintf(stdout,"\n Inside the mt_sched");
fflush(stdout);
if ( current_thread->state == NEW )
{
if ( setjmp(current_thread->saved_state) == 0 )
{
mt_allocate_stack(current_thread);
fprintf(stdout,"\n Jumping to thread = %u",current_thread->thread_id);
fflush(stdout);
longjmp(current_thread->saved_state, 2);
}
else
{
new_fns();
}
}
}
All I am trying to do is to run the new_fns() on a new stack. But is is showing segmentation fault at new_fns().
Can anybody point me out what's wrong.
Apart all other considerations, you are using "&stck" instead ok "stck" as stack! &stck points to the cell containing the POINTER TO the allocated stack
Then, some observations:
1) setjmp is not intended for this purpose: this code may work only on some systems, and perhaps only with som runtime library versions.
2) I think that BP should be evaluated in some other way. I suggest to check how you compiled composes a stack frame. I.e., on x86 platforms EBP points to the base of the local context, and at *EBP you can find the address of the base of the calling context. ESP points to EBP-SIZE_OF_LOCAL_CONTEXT, different compilers usually compute that size in a different way.
As far as I can see, you are implementig some sort of "fibers". If you are working on Win32, there is aready a set of function that implements in a safe way this functionality (see "fibers"). On linux I suggest you to have a look to "libfiber".
Regards