Date: Sat, 01 Dec 2001 15:43:04 +0100 From: Poul-Henning Kamp <phk@freebsd.org> To: security@freebsd.org Subject: philosophical question... Message-ID: <36180.1007217784@critter.freebsd.dk>
next in thread | raw e-mail | index | archive | help
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 phk@FreeBSD.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 majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36180.1007217784>