> 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
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"