From owner-freebsd-security Sat Dec 1 6:45: 0 2001 Delivered-To: freebsd-security@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id E020137B433 for ; Sat, 1 Dec 2001 06:44:24 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fB1Eh4Y36182 for ; Sat, 1 Dec 2001 15:43:04 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: security@freebsd.org Subject: philosophical question... From: Poul-Henning Kamp Date: Sat, 01 Dec 2001 15:43:04 +0100 Message-ID: <36180.1007217784@critter.freebsd.dk> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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