0

Is stack canary located between the local variable in stack and the place that the function saved the registers in the beginning of function? push r5,lr

so I can't change any registers (while the function pop them from stack) ? Or only protect on the place of PC register?

1

Short answer

Stack canary have nothing to do with registers.

As it's name may suggest, it is located on the stack.

I think you have misunderstood something, because "between the local variable stack and registers" don't mean anything.

Some of your registers values may have been pushed on the stack, but the stack don't have a direct relation with the registers. Value are taken from the stack then placed in registers (pop instructions) or the opposite (push instruction) or modified through certain instructions.

So it should not prevent you from overwriting register's values, as long as you are not corrupting the stack cookie.

Stack canary

The goal of a stack cookie is to prevent stack-based buffer overflow.

A value is pushed on the stack just before the return address of the function.

The layout of the stack would be something like that:

 -------------
|             |
| local vars  |
|             |
 -------------
|   old FP    |
 -------------
|   Canary    |
 -------------
|     Ret     |
 -------------  

The goal of a stack cookie is to prevent an attacker to overwrite the saved return address in order to manipulate the execution flow.

If the exploitation of the program leads to an overflow resulting in the following stack layout:

 -------------
|             |
|  AAAAAAAAAA |
| AAAAAAAAAAA | <- Overflow leading to corruption of the stack
 -------------
| AAAAAAAAAAA | 
 -------------
| AAAAAAAAAAA | <- Canary overwritten
 -------------
|  0xDEADBEEF | <- New arbitrary return address 
 -------------  

The program will not returns to 0xDEADBEEF because the stack cookie was lost in the process. The stack cookie is checked at the end of the function, before returning the execution to the parent's function.

In this case, an exception is raised, and the execution is never changed.

You may understand through this that it have nothing to do with registers. It is only protecting the function's return value. If you find a way (in an exploitation process) to change a local value that is affecting a register, the stack cookie will never prevent you from doing that.

5
  • Maybe I didn't get you. But the eet value is actually a PC register that push to stack in the beginning if function. So the canary will be between the local variable of the function to the saves registers?(including the pc)? That looks like push r5,lr and in the end of function pop r5,pc so if I want to overflow and change the place only of r5, can I do that? Or stack canary protect only in the place in stack that belong to ret?
    – Arm
    Jul 28 at 10:10
  • The saved value of the canary is stored somewhere on memory (not the stack nor registers). When a function is called, it takes this "original" canary value, and put it on the stack, just before the saved IP (used to return to the caller). When the function is using local arguments, it is pushed on the stack. So the stack cookie is between the local variables and the return address. Nothing related to registers in this process. Your canary may transit through a register in the process, but it is not store here (otherwise it would be too easy to break the canary).
    – Guillaume
    Jul 28 at 10:21
  • push r5,lr would imply that stack is: locals, canary, old r5, old lr (and there probably is no fp here; otherwise, it would also have been pushed). @Arm if you overflow that stack frame, it will overflow the canary, the old r5, and old lr on the stack. When the canary is checked by reading off the stack it will not be correct and the pop never occurs (ie r5 and pc are not written to), but instead branches to __stack_chk_fail. Your overflow must start after the canary or jump over it somehow leaving it intact to successfully write to pop a new r5 and new pc
    – mumbel
    Jul 28 at 21:55
  • "The goal of a stack cookie is to prevent stack-based buffer overflow" --> this statement is incorrect. the goal is not to prevent overflow, but to detect if frame overflowed to protect return address
    – R4444
    Jul 29 at 13:48
  • @Guillaume your statement "nothing related to registers" is a bit imprecise. Sure, the canary itself has nothing to do with them, but it does precede (on the stack) and prevents modification of values that are going to be popped into various registers. Aug 1 at 14:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.