Preventing stack guard-page hopping

Posted Jun 19, 2017 23:40 UTC (Mon) by jengelh (guest, #33263)
Parent article: Preventing stack guard-page hopping

>Someday, perhaps, we'll all have memory-type bits in pointers that will enable the hardware to detect and block such attacks.

Maybe the i286's segmented memory model wasn't all that useless! Set %cs, %ds and %ss to non-overlapping regions of memory, and if %sp overflows, it will just wrap back onto the same stack you already had, not touching other regions or threads. The proposed memory-type bits are implicit and sort of given by way of the selectors.

So… let's extend that to 64 bits? The segment registers appear to already be 64 bit in LM (they were not renamed like ax->eax->rax was). One extra thing is needed, an MSR, or TSS field/CR reg, to configure a modulus for %rsp, so that it wraps at a set boundary (e.g. 21 bit) on ADD/SUB/PUSH/POP instructions.

Preventing stack guard-page hopping

Posted Jun 20, 2017 5:18 UTC (Tue) by eru (subscriber, #2753) [Link]

Actually the stack overflow probably traps, because it goes out of the size allocated for the stack segment. At least if you use it on 386/486/Pentium, where wrapping completely around is less likely. This has been used in a proprietary OS I have worked with. Almost everything there is in separately allocated, 386- supported segments (probably one of the very few OS'es to use the segmentation features as Intel designers intended!), but all the other pain caused by segmented memory probably makes this not worthwhile.

Preventing stack guard-page hopping

Posted Jun 20, 2017 8:47 UTC (Tue) by jikos (subscriber, #43140) [Link]

> Set %cs, %ds and %ss to non-overlapping regions of memory, and if %sp overflows, it will just wrap back onto the same stack you already had, not touching other regions or threads

That would not really make the situation any better, as that'd effectively allow the attacker to overflow the stack using the same attack vector and manipulate contents of the stack, turning this into a rather boring and easy to exploit stack overflow.

Fortunately that's not how x86 behaves with respect to segment limits; as long as the address goes over the limit, it faults.

Preventing stack guard-page hopping

Posted Jul 6, 2017 3:37 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

My understanding of the Mill architectures is that they handle the stack themselves. There are no stack pointers at all either (I suspect "large" arrays move out to elsewhere). It's not something really feasible for the existing arches, but it seems much better than going back to segmentation to me.