Dailydave mailing list archives
Re: Protecting against Pointer Subterfuge (Redux)
From: pageexec () freemail hu
Date: Fri, 06 Oct 2006 01:19:03 +0200
it all started at (read it before you go any further): http://blogs.msdn.com/michael_howard/archive/2006/08/16/702707.aspx but comments are now disabled (and tend to be delayed by days even when they're allowed) so i'll respond here as there's some lesson in all this. Steven Alexander said:
This scheme is used for general pointer protection. If it is used on saved instruction pointers (pehaps Mike can clarify but as far as I know it isn't), it would be in addition to any canary-based stack protection and the one-byte overflow scenario would probably not occur.
i mentioned 'saved return address' because in practice that's where partial overwrites are best known to be effective (and readers would already be familiar with), my comments apply to any pointer obfuscated this way (a 'write 4 bytes to an arbitrary address' primitive can be used to overwrite only parts of an obfuscated pointer by misaligning the target address of the write). second, the a priori assumption is that the attacker is already able to perform partial overwrites, therefore the presence of any other defense mechanism is irrelevant for this discussion: if they were able to prevent partial overwrites from occuring at all then there would be no need for protecting against them to begin with (which is what the added rotation was supposed to do), right?
The variable rotation does increase security because it decreases the predictability with which an attacker can manipulate a program.
the variable rotation in the presented form *cannot* possibly increase security: the entropy used for the rotation is derived from the entropy used in the XOR cookie, therefore whenever an attack attempt assumes a particular value for the cookie, the exact rotation amount is also known (namely, the lower 5 bits of the assumed cookie value). your statement would be true if the entropy in the rotation amount was independent from that of the XOR cookie. but in the bigger scheme it doesn't matter, it'd increase the attacker's work factor from 2^32 to 2^(32+5) - if an attacker can brute force 32 bits (another a priori assumption btw) then an extra 5 bits won't hold him up either.
In cases where only a single byte overwrite is possible, it does allow an attacker more flexibility (he has a chance of modifying a series of bits at some random point in the upper three bytes instead of being limited to the lowest byte).
so you're saying that on one hand, variable rotation increases security but on the other hand it gives the attacker more flexibility, how's that for a contradiction? ;-)
In the general case, it prevents an attacker from predictably overwriting only the bytes that he wants to modify. I think the rotation is a good thing.
this of course is wrong for the reason i explained above (targeting specific bytes requires an extra work factor of 32, that's not going to save you from a successful exploit). Michael Howard said:
First, I don't see how this will allow "return to to [sic] many more addresses" a one-byte overwrite is still a one-byte overwrite! Also, an attacker's 'sploit would have to survive the XOR operation post rotation.
as i alluded to at the beginning, there's a lesson here. in security, what i call 'naive common sense' reasoning often falls on its face, which is the case here. the naivety here is the assumption that 8 bits of input (for a single byte partial overwrite) provided by the attacker will affect 8 bits of output in the plaintext pointer. what you forgot to take into account is what happens in-between. namely, thanks to the rotation, the 8 bits of attacker input are combined with any of the 32 bits in the obfuscated pointer (vs. 8 bits without the rotation). this in turn means that when an attacker brute forces the 32 bits of randomness in the XOR cookie, he'll also get to influence more than the 8 bits he directly overwrote - the 'attack surface' explodes. to quantify this explosion i wrote a simple proof-of-concept enumerator (http://grsecurity.net/~paxguy1/howard-xorrot.c). the result will speak for itself, e.g., a single byte overwrite with a constant 0 can result in over 2600 possible reachable addresses (the current code enumerates only 8+5=13 bits of cookie space, change the code for more) - that's an order of magnitude higher than the 256 addresses reachable without rotation.
This is for long-lived pointers, which may of course point to code. But as Steven says, this is also just part of a layered defense, we have the /GS stuff in there as well as ASLR, heap randomization and stack randomization, etc.
due to the a priori assumption, this is all irrelevant here, the bottom line is that with the extra rotation you shot yourself in the foot and managed to weaken your pointer protection scheme (similar naive thinking had also weakened the /GS cookie as well, although that's less disastrous). _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- Re: Protecting against Pointer Subterfuge (Redux) pageexec (Oct 05)
- Message not available
- Re: Protecting against Pointer Subterfuge (Redux) pageexec (Oct 09)
- Message not available