3 ms·

pl is a variable. So this array size is variable. What would happen if the allocation cannot be made on the stack?

by enqk 8y ago

ua16s1 8y ago
I don't do much C, or any at all. What would happen? Would the allocation fail and you'd end up with prefix pointing to NULL? Or would it overwrite something else on the stack?
- rambojazz 8y ago
  As far as I know if there is not enough space it should trigger a page fault, which in turn triggers an exception, which should probably result in a segmentation fault.
  - pjmlp 8y ago
    Not necessarily, it might just corrupt neighbouring data, changing the behaviour of the exploited function.
Someone 8y ago
Traditionally, the allocation would nevertheless be made. Effect would be that the stack and the memory allocator shared memory. That typically doesn’t go well for long. The moment you write to that local variable (which technically need not happen, but if you don’t write to it, why have the variable at all?), you overwrite data in the heap and/or heap data structures. That will become a problem when the program reads that data or when the memory allocator walks the heap. Debugging this kind of problem is hard, as the buggy code often will run fine. It ‘just’ triggers problems at some unspecified later time, likely in a completely unrelated part of the program. So, guard pages ‘below’ the stack were added. They trigger exceptions that kill the offending program when it tries to write to or read from those pages. That doesn’t fully prevent this problem; large stack objects may jump over the protected area (especially in 32-bit code, you don’t want to give up lots of virtual address space to such guard pages, and the amount of address space ‘lost’ can add up fast in multi-threaded programs) Another way to detect this is to periodically (say in an interrupt handler, or whenever a call to the memory allocator is made) check that the stack pointer has a valid value. That isn’t sure-fire, either. Firstly, it can only detect problems after the fact and secondly, it may not see short violations of the rules.
- rambojazz 8y ago
  How do large stack objects jump over the protected area? Even if the OS allocates so much stack space that the stack pointer overlaps with the heap area, if the stack is written sequentially I would think that it's going to write to the protected area before it writes to memory beyond it. EDIT: maybe I got this. Basically, if my stack pointer jumps the protected page and ends up in the heap, I can address prefix[last_pos] without triggering any page fault, thus corrupting memory. Is this correct? I guess guard pages are a very weak protection mechanism, the OS should check the position of the stack pointer at every memory allocation.
  - Someone 8y ago
    Yes, that’s correct. For example, if the stack grows downwards (which, AFAIK, is the case on most current architectures): - stack pointer is at S - protected area starts at B, ends at E (with B<E<S) - stack is decreased by something larger than (S-B), making it point somewhere before the start of the protected area Compilers won’t allocate large local variables on the stack, so guard pages work fine for accidental stack overflows, such as when a call stack gets too deep. They also work reasonably well against intentional (by an attacker, not by the programmer who wrote the code) ones, but indeed aren’t perfect. That’s why some compilers have compiler flags that, when allocating a stack variable that they don’t know to be ‘small’ will insert extra code that will hit the protected area, even if the allocation jumps over it.

pl is a variable. So this array size is variable. What would happen if the allocation cannot be made on the stack?

by enqk 8y ago

pl is a variable. So this array size is variable. What would happen if the allocation cannot be made on the stack?

I don't do much C, or any at all. What would happen? Would the allocation fail and you'd end up with prefix pointing to NULL? Or would it overwrite something else on the stack?

rambojazz 8y ago
As far as I know if there is not enough space it should trigger a page fault, which in turn triggers an exception, which should probably result in a segmentation fault.
- pjmlp 8y ago
  Not necessarily, it might just corrupt neighbouring data, changing the behaviour of the exploited function.

Someone 8y ago

Traditionally, the allocation would nevertheless be made. Effect would be that the stack and the memory allocator shared memory. That typically doesn’t go well for long. The moment you write to that local variable (which technically need not happen, but if you don’t write to it, why have the variable at all?), you overwrite data in the heap and/or heap data structures. That will become a problem when the program reads that data or when the memory allocator walks the heap. Debugging this kind of problem is hard, as the buggy code often will run fine. It ‘just’ triggers problems at some unspecified later time, likely in a completely unrelated part of the program. So, guard pages ‘below’ the stack were added. They trigger exceptions that kill the offending program when it tries to write to or read from those pages. That doesn’t fully prevent this problem; large stack objects may jump over the protected area (especially in 32-bit code, you don’t want to give up lots of virtual address space to such guard pages, and the amount of address space ‘lost’ can add up fast in multi-threaded programs) Another way to detect this is to periodically (say in an interrupt handler, or whenever a call to the memory allocator is made) check that the stack pointer has a valid value. That isn’t sure-fire, either. Firstly, it can only detect problems after the fact and secondly, it may not see short violations of the rules.

rambojazz 8y ago
How do large stack objects jump over the protected area? Even if the OS allocates so much stack space that the stack pointer overlaps with the heap area, if the stack is written sequentially I would think that it's going to write to the protected area before it writes to memory beyond it. EDIT: maybe I got this. Basically, if my stack pointer jumps the protected page and ends up in the heap, I can address prefix[last_pos] without triggering any page fault, thus corrupting memory. Is this correct? I guess guard pages are a very weak protection mechanism, the OS should check the position of the stack pointer at every memory allocation.
- Someone 8y ago
  Yes, that’s correct. For example, if the stack grows downwards (which, AFAIK, is the case on most current architectures): - stack pointer is at S - protected area starts at B, ends at E (with B<E<S) - stack is decreased by something larger than (S-B), making it point somewhere before the start of the protected area Compilers won’t allocate large local variables on the stack, so guard pages work fine for accidental stack overflows, such as when a call stack gets too deep. They also work reasonably well against intentional (by an attacker, not by the programmer who wrote the code) ones, but indeed aren’t perfect. That’s why some compilers have compiler flags that, when allocating a stack variable that they don’t know to be ‘small’ will insert extra code that will hit the protected area, even if the allocation jumps over it.