Thread: Shared system resources

On Tue, Dec 22, 2015 at 04:52:23PM -0600, oleg yusim wrote:
> Greetings,
>
> I'm looking at the following security control right now:
>
> The DBMS must prevent unauthorized and unintended information transfer via
> shared system resources.
>
> The purpose of this control is to prevent information, including encrypted
> representations of information, produced by the actions of a prior user/role
> (or the actions of a process acting on behalf of a prior user/role) from being
> available to any current user/role (or current process) that obtains access to
> a shared system resource (e.g., registers, main memory, secondary storage)
> after the resource has been released back to the information system. Control of
> information in shared resources is also referred to as object reuse.
>
> From previous discussions, I understood that session in PostgreSQL is closely
> associated with process, and it is essentially new process for every user
> connection. In regards to that, my question would be:
>
> When user disconnects, process is terminated and all resources are released,
> does memory, session/process stored information at gets "sanitized" or just
> released as is?

On Linux the memory pages of an exiting process aren't sanitized at
exit, however it is impossible(?) for userspace to reallocate them
without the kernel first zeroing their contents.

It might be possible for root to use some debugging mechanisms to access
the freed memory, but certainly there is no mechanism for a non-root
user to do so.

Regarding PG in particular, I can't speak for any shared internal state
that might be maintained after a session has exitted (e.g. in the SHM
regions PG maintains). Since that state lives longer than an individual
process, it's possible some information leakage could occur that way,
but "object reuse", it seems doubtful.


David

The DBMS must prevent unauthorized and unintended information transfer via shared system resources.

-- 
john r pierce, recycling bits in santa cruz

On 12/22/15 6:03 PM, oleg yusim wrote:
> Absolutely. But we are not talking about that type of data leakage here.
> We are talking about potential situation when user, who doesn't have
> access to database, but has (or gained) access to the Linux box DB is
> installed one and gets his hands on data, database processes stored in
> memory (memory would be a common resource here).

Of far larger concern at that point is unauthorized access to the
database files.

Basically, if someone gains access to the OS user that Postgres is
running as, or to root, it's game-over.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

On Tue, 22 Dec 2015 23:21:27 +0000, David Wilson <dw+pg@hmmz.org>
wrote:

>On Linux the memory pages of an exiting process aren't sanitized at
>exit, however it is impossible(?) for userspace to reallocate them
>without the kernel first zeroing their contents.

Not impossible, but it requires a non-standard kernel.

Since 2.6.33, mmap() accepts the flag MAP_UNINITIALIZED which allows
pages to be mapped without being cleared.  The flag has no effect
unless the kernel was built with CONFIG_MMAP_ALLOW_UNINITIALIZED.


No mainstream distro enables this.  AFAIK, there is NO distro at all
that enables it ... it's too big a security risk for a general purpose
system.  It's intended to support embedded systems where the set of
programs is known.

George

On Wed, Dec 23, 2015 at 07:07:31AM -0600, oleg yusim 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?

Sure it might be possible, but they would not have much useful
information about which old processes the pages belonged to, and
besides, they could most likely simply dump memory of a connected client
in this case, or indeed just examine the filesystem or cache to get at
the raw PG database files.

Once someone has this level of access to the system it's not really
useful to model threats much further.

One minor correction from my first mail: MAP_UNINITIALIZED is indeed
accessible to non-root, but as George mentions only when a non-default
kernel parameter has been enabled.


David

On 12/23/15 7:55 AM, oleg yusim wrote:
> Sure David. For simplicity of modeling here, let's assume raw database
> data was encrypted and the only possibility for attacker to get
> something from raw data is to go and dig into sessions leftovers. Now,
> with that has been said, do you happen to know what information actually
> gets stored during the session into memory, reserved by session process?
> I'm trying to determine, basically, does it even worth a talk - maybe
> there is nothing at all valuable.

There's tons of raw data stored in the shared memory segment, and some
of that can be copied to process local memory at any time. If they OS
doesn't secure that adequately there's certainly nothing that Postgres
or any other database can do about it.

As David said, by the time you're concerned about someone getting access
to raw memory it's already way too late.

As for memory pages being zero'd after they are returned to the OS,
that's entirely up to the OS. The only thing you could do on the
Postgres side is to compile with memory debugging enabled, which will
over-write any memory that's freed with a magic value. That's done to
help hunt down memory access bugs, but would have the obvious side
effect of obliterating any data that was in the page.

Uh, only thing is, I don't know if this is done if we're going to be
returning the memory to the OS.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

On 12/23/2015 8:16 AM, oleg yusim wrote:
>
> To my knowledge, many databases are using what called TDE to encrypt
> data at rest and protect data from being accessed by attacker on host
> this way. Here is the reference to quick guide on it:
> https://www.simple-talk.com/sql/database-administration/transparent-data-encryption/

that article is talking about a specific feature of Microsoft SQL Server
Enterprise Edition, which upon a quick skim sounds to me to be smoke and
mirrors 'security-by-checklist' protection.   If the encryption keys are
stored on the system, then anyone with access to the raw data can
decrypt it, no matter how much smoke and mirrors you wave around to
obfuscate this fact.

In PostgreSQL 'shared memory' has a quite specific meaning, its
referring to the pool of buffer memory (ram) shared by all postgres
server processes.   this is primarily used as the buffer cache. In a
properly secured operating system, ONLY the postgres server processes
have access to this shared memory segment, but the details of OS level
memory management are outide postgres's scope, since its portable and
designed to be able to run on most any OS that provides basic memory
management, multiple processes, and a reliable/robust file system, with
tcp/ip socket support.



--
john r pierce, recycling bits in santa cruz

Hi Oleg,

On Wed, 23 Dec 2015 07:07:31 -0600, oleg yusim <olegyusim@gmail.com>
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

On 12/23/15 12:05 PM, Melvin Davidson wrote:
> As others have pointed out, worrying about someone accessing database
> shared memory is like worrying about an asteroid striking the earth and
> wiping out all life.
> It's a one in a billion chance compared to other security violations
> that can occur.
> You are better off concentrating on proper O/S security and user/table
> permissions. That is how to implement database security!

True, but in my experience security audits have nothing to do with
security and everything to do with marking off checkboxes and
complicating lawsuits. ;)
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

On 2015-12-23 11:55:36 -0500, George Neuner wrote:
> 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.

You just have to load a kernel module to do so - it's just a few dozen
lines of C.