On Wed, 2015-12-09 at 07:47 -0500, Ted Unangst wrote: > This is a kind of two steps forward, one step back diff. > > I would like for the canary to be placed directly adjacent to the end > of the > user specified size. No slack. To accomplish this, we record the > original size > of the allocation at the end, then we can walk backwards to find the > canary. > Mechanically, this requires passing the real size down a little deeper > in some > places.
Makes sense. The goal was reliably catching small overflows but the size class rounding proved to be a major problem (especially with the coarse power of two size classes). And it doesn't seem like it would reduce the potential for using this as a security feature. > I also changed the canaries to be entirely random, with the correct > value > stored in each chunk. This is a security tradeoff, since now an > attacker can > overwrite the whole works predictably. But I consider this more of a > debugging > feature than a security feature, so I'd prefer to greatly improve the > ability > to catch one byte overwrites. A fair trade. An alternative to this would be storing a random value in the metadata for the chunk pages. That would avoid needing to spend more memory for the inline random value and wouldn't have a negative security impact. It wasn't really meant for protecting against sequential overflows since it would usually detect them too late, but ideally it could still work as a defence against them in some cases. Not quite as good as a random value per canary, but a random value per page would already be pretty fine-grained and each canary can still be made unique via something like the current `random ^ hash(address)`. There also might be a much better way of generating the canaries from the random value. I just copied the existing pattern and added the hash call to make it a little less bad. If performance wasn't a concern, it could simply use SipHash but... it's way too slow. Hiding the seed from people able to leak the canary value would only require encryption but ideally it would actually be a proper MAC (that just seems unrealistic).
