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>
index | next in thread | previous in thread | raw e-mail
> 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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201404201831.s3KIVCSY054778>