4 ms·

PPC only leaves the return address in a register for leaf functions. Otherwise, it's saved to the stack and exploitable just like any other architecture.

ANTSANTS 12y ago
EDIT: I'm misread your post because I'm tired, but I'll leave this explanation of -fomit-frame-pointer up anyway. With most architecture+compiler combinations, a register is dedicated to holding the frame pointer, a pointer to a fixed position in the stack frame of a function containing the return address to the caller. For x86, ebp (rbp in 64 bit mode) is used for this purpose, and a stack frame looks something like this: var_2 at [ebp-8] <-- top of stack, lowest address (yes this is counter-intuitive) var_1 at [ebp-4] return_address [ebp] <-- ebp points here arg_1 at [ebp+4] arg_2 at [ebp+8] No matter how much data you push onto the stack in local variables (even variable length structures eg with alloca or variable length arrays in C), the parameters are always accessible at positive offsets from ebp while the (fixed-size) local variables are at negative offsets. Without a frame pointer, parameters must be accessed relative to the stack pointer instead. Disadvantages of this include: Both parameters and local variables are at positive offsets in comparison to esp, so it's harder to tell the two apart. The offsets can change throughout the function as variables are pushed and sometimes popped from the stack, making analysis even more difficult. You can't allocate variable width structures on the stack because then the compiler would not know at what offsets the parameters/variables would lie. And it's not even necessarily a performance win either, because x86 uses longer instruction encodings for sp-relative addressing vs. bp-relative addressing. x86_64 and most RISC architectures don't have this problem, there are enough spare registers that the negatives of -fomit-frame-pointer outweigh the positives.
- ANTSANTS 12y ago
  >I'm misread your post because I'm tired Ok, it's officially past my bedtime.
millstone 12y ago
That's right. But it's more difficult to exploit, because you have to smash the caller's return address, not your own, and then wait for the caller to return. Anyways, my point is merely that if you wanted to design an ISA that maximizes exploitability of buffer overflows, you'd be hard pressed to do better than x86.
- WallWextra 12y ago
  Sometimes I wonder how much better off we'd be with something exactly like x86, but with a stack that grows upwards.
  - munin 12y ago
    not much, wouldn't matter. what you REALLY should wonder is, something like x86, but with code pointers stored in a separate address space.
    - ANTSANTS 12y ago
      We kinda already had this with the old segmented memory model. That AMD mostly dropped support for it in x86_64 should tell you something. https://en.wikipedia.org/wiki/X86_memory_segmentation https://en.wikipedia.org/wiki/X86_memory_segmentation
  - Scaevolus 12y ago
    A stack that grows upwards means that you exploit the return address of called functions instead of your current function. void dangerous() { char buf[10]; gets(buf); // the return in gets could be redirected }
  - SamReidHughes 12y ago
    If the buffer is on the stack and being overflowed by the function that declared it, not some callee.

ANTSANTS 12y ago

EDIT: I'm misread your post because I'm tired, but I'll leave this explanation of -fomit-frame-pointer up anyway. With most architecture+compiler combinations, a register is dedicated to holding the frame pointer, a pointer to a fixed position in the stack frame of a function containing the return address to the caller. For x86, ebp (rbp in 64 bit mode) is used for this purpose, and a stack frame looks something like this: var_2 at [ebp-8] <-- top of stack, lowest address (yes this is counter-intuitive) var_1 at [ebp-4] return_address [ebp] <-- ebp points here arg_1 at [ebp+4] arg_2 at [ebp+8] No matter how much data you push onto the stack in local variables (even variable length structures eg with alloca or variable length arrays in C), the parameters are always accessible at positive offsets from ebp while the (fixed-size) local variables are at negative offsets. Without a frame pointer, parameters must be accessed relative to the stack pointer instead. Disadvantages of this include: Both parameters and local variables are at positive offsets in comparison to esp, so it's harder to tell the two apart. The offsets can change throughout the function as variables are pushed and sometimes popped from the stack, making analysis even more difficult. You can't allocate variable width structures on the stack because then the compiler would not know at what offsets the parameters/variables would lie. And it's not even necessarily a performance win either, because x86 uses longer instruction encodings for sp-relative addressing vs. bp-relative addressing. x86_64 and most RISC architectures don't have this problem, there are enough spare registers that the negatives of -fomit-frame-pointer outweigh the positives.

ANTSANTS 12y ago
>I'm misread your post because I'm tired Ok, it's officially past my bedtime.

millstone 12y ago

That's right. But it's more difficult to exploit, because you have to smash the caller's return address, not your own, and then wait for the caller to return. Anyways, my point is merely that if you wanted to design an ISA that maximizes exploitability of buffer overflows, you'd be hard pressed to do better than x86.

WallWextra 12y ago
Sometimes I wonder how much better off we'd be with something exactly like x86, but with a stack that grows upwards.
- munin 12y ago
  not much, wouldn't matter. what you REALLY should wonder is, something like x86, but with code pointers stored in a separate address space.
  - ANTSANTS 12y ago
    We kinda already had this with the old segmented memory model. That AMD mostly dropped support for it in x86_64 should tell you something. https://en.wikipedia.org/wiki/X86_memory_segmentation https://en.wikipedia.org/wiki/X86_memory_segmentation
- Scaevolus 12y ago
  A stack that grows upwards means that you exploit the return address of called functions instead of your current function. void dangerous() { char buf[10]; gets(buf); // the return in gets could be redirected }
- SamReidHughes 12y ago
  If the buffer is on the stack and being overflowed by the function that declared it, not some callee.