It seems like phkmalloc saved us in the wuftpd case. I cannot 100%
say that one couldn't subvert it, but it would be a LOT harder to
arrange things just right with phkmalloc. It certainly does not
seem feasible to write a sure-fire-on-any-system exploit since the
order and size of malloc(3) calls will have to be controlled.

But this brought back memories of an old idea of mine: Back in 1996
I considered adding a bit of randomness to some of the layout
decisions in phkmalloc to improve benchmark quality.

As the layout changes from time to time the RAM/cache will become
less determinstic. According to statistics the mean will probably
stay the same but the stddev will increase, so in some small way
the benchmarks would be more honest I guess.

At the time I filed this away for future consideration and here it
is again...

Therefore, question(s) to the list:

Would it, from a security point of view, make sense to add a bit
of dithering to phkmalloc's layout in order to frustrate attacks
which "know where things are in RAM" ?

The randomness used would have to be something very cheap, and
cannot involve filedescriptors, so something as simple as
the bits in the PID of the process or similar. Would the use
of weak entropy negate any positive effect ?

Would it inconvenience debugging that malloc(3) becomes non
deterministic in its layout ?

Would the increased uncertainty on program run-time be good or bad ?

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phkFreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]