Password theft from memory?

[Lowell Gilbert]

Modulok <modulok at gmail.com> writes:

>>> On Sun, Apr 24, 2011 at 7:10 PM, Modulok <modulok at gmail.com> wrote:
>>> > I don't know if this is a problem on FreeBSD...
>>> >
>>> > Process A requests memory.
>>> > Process A Stores a plaintext password in memory or other sensitive
>>> > data. Process A terminates and the memory is reclaimed by kernel.
>>> >
>>> > Process B requests a *huge* chunk of memory.
>>> > Process B crawls the uninitialized memory, looking for ProcessA's
>>> > previously stored password.
>>> >
>>> > Does anyone know if this is even possible on FreeBSD?
>
>> AFAIK it's the responsibly of the programmer to avoid  data leaking.
>> Passwords are commonly overwritten as soon as they no longer needed. I
>> think geli keeps persistent key information in kernel wired-memory.
>
> If you're writing in an language which has direct memory access you can easily
> overwrite sensitive regions of memory upon program exit. But what about higher
> level, dynamic languages where direct memory access is not available? For
> example, if I write program in Python (or a some other language) which
> processes plaintext passwords or credit card numbers, on a shared host, can
> that data be found in memory by another user's process designed to recognize
> such patterns in large allocations? (Patterns like SS numbers, credit cards,
> regions near strings like 'password' and so on.)
>
> I know that each process has its own private memory segment, but after a
> process exits, it nolonger owns that memory. What happens to it? If it's not
> zeroed out by my process, and it doesn't turn into pixie food, and it's not
> zeroed out by malloc... it still exists somewhere.
>
> Maybe this would be best on hackers?

In my opinion, no, -chat would be better.  This is a well established
area and all multi-user operating systems cover it in some way.

You are missing an important point that had been glossed over somewhat
in the earlier messages in this thread.  In particular, you're missing
that an unprivileged process doesn't have direct access to real memory
addresses no matter what language it was written in.  Languages that
support memory pointers have access to a "virtual" address space on
FreeBSD (and most other general-purpose operating systems of the last
decade or two), which does not give them access to the memory of other
processes.  

When a process exits (and, indeed, "it no longer owns that memory"), the
real memory pages behind its virtual memory will be returned to the
kernel, which will zero out those pages before letting another process
reuse them.  The details other people have been discussing have to do
with the fact that there is more than one mechanism through which pages
might get allocated to a process, but in all of those mechanisms, the
old data is obliterated first.

In practice, programmers used to Unix-ish systems may assume that their
memory allocations are always zero-filled.  On embedded systems (and
other specialized environments, but I mostly deal with embedded systems
for routers), this may not be a good assumption.  Even on a Unix system,
it's not necessarily a good assumption -- you won't get memory that was
written by a different process, but you may well get memory that was
released by your own process without being overwritten.  Needless to
say, this isn't a security concern.

Be well.