Thank you very much George, that is exactly the piece of information I was missing.
Oleg
On Wed, Dec 23, 2015 at 10:55 AM, George Neuner <gneuner2@xxxxxxxxxxx> wrote:
Hi Oleg,
On Wed, 23 Dec 2015 07:07:31 -0600, oleg yusim <olegyusim@xxxxxxxxx>
wrote:
>May we run into situation, when attacker dumps memory and analyses it for
>valuable content, instead of reserving it for own process, where it would
>be zeroed? My understanding, it is a possibility. Does kernel have any
>safeguard against it?
With recent kernels, by default there is no way for a userspace
process (even root) to dump memory. Older kernels by default
permitted a root process unrestricted access to /dev/mem and
/dev/kmem, however in general that isn't needed and has long been
disabled by the mahor distros. [see CONFIG_STRICT_DEVMEM]. IIRC, the
default setting was changed in 2011.
With sufficient privileges, a debugger-like process can attach and
examine the memory of a running - or just terminated - process, but it
won't have access to discarded (unmapped) memory.
The MAP_UNINITIALIZED trick, even if it works, is not a predictable
attack vector. There is no way to ask for any *particular* VMM page -
mmap() just gives you a set of pages sufficient to cover the requested
address range ... you don't know what process those pages previously
belonged to. Obviously there is a known algorithm for satisfying the
page requests, but the set of free pages includes both code and data
and depends on the history of system activity. There's no guarantee
to get anything useful.
I'm not sure any of this really answers your question.
George
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
