"hcoin" <[email protected]> wrote: > local variables) harms performance. It's also true doing both of these > things would not fix the flaw that 'opened the window' onto these data. > However it is true that doing so would make the exploit valueless as > 'opening a window' onto erased data would reveal nothing and could erase > trojan/virus 'hijack via code-injection then trampoline' opportunities. In the heartbleed case, was the bug returning stale freed memory, though? Couldn't it just as easily have been that the over-read was returning any other memory that the process has had allocated for other variables - data that was still in use? > If the variable stack and free() functions erased data spaces, there > would be no security value in having application edge malloc effectively > be calloc. Yeah. I had wrongly assumed that this was a throwback to more innocent days, and that these days, malloced space was effectively cleared by every sane OS, but due to backwards compatibility, the spec only defines calloc as acually clearing data, so you should never assume malloced memory was cleared, even though effectively it is these days. But Nathan and RW helpfully showed me where my reasoning failed! > There may be marginal security value in having OS edge free() erase data > before subsequent OS edge malloc of the same page to a process owed by a > different userid. Now this I don't get. Marginal? Surely in this case, this is a MUST. Otherwise we'd continually be getting local users getting data they shouldn't.... Every machine would be a 'heartbleed' for local users, even when running bug free code! I'd even extend this policy to different processes - even with the same id, because, of course, many daemons spawn children that deal with different connections simultaneously. (But of course in this case any leak would be down to bad programming if data leaks were discovered to be exploitable.) But yeah, surely if the UID (or more accurately, the EUID) were different but the data wasn't erased by the system prior to malloc, a leak would be unpreventable (unless, of course, the careful programmer never frees data, until he/she has erased it themselves beforehand. And who does that? > This entire discussion, (clear-on-free and > clear-stack-on-function-return) are resource heavy ways of managing > complexity. It is for the community to decide whether it is 'worth it' > on a case by case basis given there is no way to prove a program > 'correct' from a security perspective. I agree. More generally, all exploit busting mechanisms add to complexity and resources, whether it's DNS randomizing outgoing udp ports, or stack protection/pro police/canaries etc. You have to make a judgement call based between the protection of your software against speed, throwing into the equation the competence of your programming team! cheers, Jamie _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"