Re: Protecting against Pointer Subterfuge (Redux)

[pageexec () freemail hu]

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