Date: Sun, 20 Apr 2014 19:31:12 +0100 From: Jamie Landeg-Jones <jamie@dyslexicfish.net> To: hcoin@quietfountain.com, freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? Message-ID: <201404201831.s3KIVCSY054778@catnip.dyslexicfish.net> In-Reply-To: <53540307.1070708@quietfountain.com> References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org> <201404200548.s3K5mV7N055244@catnip.dyslexicfish.net> <53540307.1070708@quietfountain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I wonder how many security holes, both those known and as yet unrevealed
> or unknown, would not be of any exploit value if in all security related
> libraries and applications the routine to free allocated memory
> allocation closest to the user app/library set the newly free memory to
> a known pattern or something from /dev/random before returning. And,
> similarly, a compiler option causing function returns using more than a
> few dozen bytes of stack space to erase the newly freed stack region
I'm probably being really dense here, and realise I can't delete this
post once sent! But....
Once memory has been freed, I thought any attempt by a user process to
access it would cause a SIGSEV.
I thought the issue was with programs that inadvertantly expose (either
to read or write) other parts of their active memory.
Of course, if a process rolls it's own in-process implementation
of malloc/free, then this point is moot, but once you free memory back
to the system, isn't in no longer accessable anyway?
Cheers,
Jamie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201404201831.s3KIVCSY054778>