RE: [VulnDiscuss] Re: iDEFENSE Security Advisory 01.28.03: SSH2 Clients Insecurely Store Passwords

Michal,

That the window of opportunity shrinks is exactly it.  Obviously
scrubbing the memory won't prevent people with read access to memory, swap
devices, or any other point in the system where the data persists from
obtaining it.  Off-list I mentioned to Dragos that the idea is to
minimize the amount of time that the data is stored in accessible memory.
Should some memory be exposed to adversaries during the life of the
process, the probability is reduced that it will be sensitive.  A good
example of why scrubbing is not a bad idea are the recent vulnerabilities
in ethernet drivers (padding frames with unscrubbed memory).  In our
vulnerability database, the failure to scrub credentials buffers
is considered a 'weakness' rather than a 'vulnerability' -- the
distinction being that weaknesses are noteworthy conditions that
cannot be exploited on their own.

David Mirza Ahmad
Symantec

0x26005712
8D 9A B1 33 82 3D B3 D0 40 EB  AB F0 1E 67 C6 1A 26 00 57 12

On Thu, 30 Jan 2003, Michal Zalewski wrote:

> On Thu, 30 Jan 2003, David Endler wrote:
>
> > Non issue? Even though it's a low severity risk, isn't it plausible that
> > memory containing this sensitive information gets swapped to disk?
>
> And how does scrubbing the memory alone prevent this? It does not.
> Scrubbing the memory does not prevent any attack vector from being
> exercised, it only shrinks the window of opportunity, but it's irrelevant
> in most real-world scenarios anyway.
>
> The only way to prevent this is to lock some pages, and this is not
> available on all OSes, on others, root privileges are required - and even
> then, it's possible to circumvent this protection scheme. On a side note,
> this still does not prevent the information from being retained in
> kernel-space circular buffers and queues.
>