Suggestion: erase data posted to the Web

[Andrew Daviel]

A recent New Scientist article referred to the fact that
"sensitive data" may persist in computer memory, and be swapped to disk
and persist after a power-down.

http://www.newscientist.com/news/news.jsp?id=ns99995064

I had observed a while ago that text such as credit card numbers entered
into a form in Netscape could persist in RAM after the application exits,
and this seems to be still true for Mozilla.

As discussed earlier in Bugtraq ("When scrubbing secrets in memory doesn't
work", 19 Nov 2002), in Linux/Unix the mlock() call can be used to
discourage swapping (MmLockPagableSectionByHandle ? in Win32), while
overwriting can be used to erase freed memory (as is done in Gnupg).

It occurs to me that, while an unprivileged process cannot read system
memory directly, that a simple allocation of a large chunk of memory might
get data freed up or abandoned by previously running processes. Certain
data, such as credit card numbers and SINs, have a predictable pattern
that a regex such as
/4530[\s]{0,1}[\d]{4}[\s]{0,1}[\d]{4}[\s]{0,1}[\d]{4}[\s]{0,1}[\d]{4}/
might easily find.

Given the now common practice of leaving computers powered on with
"high-speed" internet access, and the recent appearance of trojans such as
Bankhook.A and Pwsteal.Refest, I suggest that best practice be updated to
include the erasure and protection of "sensitive data". This would include
obvious things like passwords, certificates etc. and be extended to
anything entered into an SSL-protected form in a Web browser. At some
expense in CPU time, it might include all https displayed pages and any
user-generated data such as word processor documents.

One (probably very CPU-intensive, for some apps) way to enforce this
behaviour for malloc'd memory would be to make free() do an erase
operation as a system option. Creating "secure_free()" would be better.

--
Andrew Daviel, TRIUMF, Canada
Tel. +1 (604) 222-7376
security@triumf.ca

[Michael Wojcik]

> From: Andrew Daviel [mailto:advax@triumf.ca]
> Sent: Wednesday, July 07, 2004 2:30 PM
>
> A recent New Scientist article referred to the fact that
> "sensitive data" may persist in computer memory, and be
> swapped to disk and persist after a power-down.
>
> I had observed a while ago that text such as credit card numbers
> entered into a form in Netscape could persist in RAM after the
> application exits, and this seems to be still true for Mozilla.
>
> As discussed earlier in Bugtraq ("When scrubbing secrets in
> memory doesn't work", 19 Nov 2002), in Linux/Unix the mlock() call can
> be used to discourage swapping (MmLockPagableSectionByHandle ? in
> Win32), while overwriting can be used to erase freed memory (as is done
> in Gnupg).

This conflates two related but different security issues: sensitive data
left in RAM, and sensitive data left on disk after having been paged out.
While the underlying problem (sensitive data outlasting the scope of its
proper use) is the same, the parameters are quite different (for example,
power-cycling generally takes care of the former but doesn't affect the
latter), so they need to be analyzed and addressed separately.

> It occurs to me that, while an unprivileged process cannot read system
> memory directly, that a simple allocation of a large chunk of
> memory might get data freed up or abandoned by previously running
> processes.

That shouldn't happen with any modern general-purpose OS. There's an Orange
Book requirement called "object reuse" that requires all systems certified
at C2 or above remove old data from an object (such as a region of memory)
when it is reallocated to a new process. That's a simple guarantee for a
virtual-memory OS to provide when allocating memory, so all the significant
players do.

> Given the now common practice of leaving computers powered on with
> "high-speed" internet access, and the recent appearance of
> trojans such as Bankhook.A and Pwsteal.Refest, I suggest that best
> practice be updated to include the erasure and protection of "sensitive
> data".

Many people would say they already do include that.

However, I think simply naming "best practices" is not particularly useful,
in the long run. What you need is a weighted threat model, so you can
address threats in an appropriate order. (The exact metric is debatable,
but it should probably combine attack probability, likely degree of damage,
and at a lesser weight the effort of implementing defense. And, of course,
where it's trivial to protect against a threat, it's worth adding that
protection even if the threat is unlikely.)

For the general populace, I suspect "phishing" and other technically
unsophisticated social-engineering attacks are likely more prominent than
and equally damaging as the considerably more difficult class of attacks
that involve gaining unfettered read access to physical memory and disk
paging areas and trolling them for sensitive data.

Of course, it's trivial to memset over a sensitive area when you're done
with it, so programs ought to do so. Locking pages to prevent them from
being written to disk may be more difficult: if it doesn't require special
privilege then it's a potential DOS against physical memory resources, and
if it does, then you may have to grant programs more privilege than they
should have, creating a worse security hole.

> One (probably very CPU-intensive, for some apps) way to enforce this
> behaviour for malloc'd memory would be to make free() do an erase
> operation as a system option. Creating "secure_free()" would
> be better.

I doubt you'd notice the CPU cost for nearly any normal application.
However, as I noted above, the "object reuse" C2 requirement is widely
satisfied and makes clearing memory when it's freed largely unnecessary. A
much better approach is to have each program clear its own sensitive data as
soon as possible.

--
Michael Wojcik
Principal Software Systems Developer, Micro Focus

[Luciano Miguel Ferreira Rocha]

On Wed, Jul 07, 2004 at 11:30:00AM -0700, Andrew Daviel wrote:
>
> A recent New Scientist article referred to the fact that
> "sensitive data" may persist in computer memory, and be swapped to disk
> and persist after a power-down.
>
> http://www.newscientist.com/news/news.jsp?id=ns99995064
>
> I had observed a while ago that text such as credit card numbers entered
> into a form in Netscape could persist in RAM after the application exits,
> and this seems to be still true for Mozilla.
>
> As discussed earlier in Bugtraq ("When scrubbing secrets in memory doesn't
> work", 19 Nov 2002), in Linux/Unix the mlock() call can be used to
> discourage swapping (MmLockPagableSectionByHandle ? in Win32), while
> overwriting can be used to erase freed memory (as is done in Gnupg).
>
> It occurs to me that, while an unprivileged process cannot read system
> memory directly, that a simple allocation of a large chunk of memory might
> get data freed up or abandoned by previously running processes. Certain
> data, such as credit card numbers and SINs, have a predictable pattern
> that a regex such as
> /4530[\s]{0,1}[\d]{4}[\s]{0,1}[\d]{4}[\s]{0,1}[\d]{4}[\s]{0,1}[\d]{4}/
> might easily find.

Moderm multi-user/process operating systems zero de memory before giving
it to any process. So this shouldn't be a problem unless the attacker can
access the memory directly (via /dev/mem under Unix, for example).

>
> Given the now common practice of leaving computers powered on with
> "high-speed" internet access, and the recent appearance of trojans such as
> Bankhook.A and Pwsteal.Refest, I suggest that best practice be updated to
> include the erasure and protection of "sensitive data". This would include
> obvious things like passwords, certificates etc. and be extended to
> anything entered into an SSL-protected form in a Web browser. At some
> expense in CPU time, it might include all https displayed pages and any
> user-generated data such as word processor documents.

It's not feasible to lock all that data in memory, and most probably the
kernel will impose strict limits on total memory lockable on the system
and/or by an umprivileged user.

> One (probably very CPU-intensive, for some apps) way to enforce this
> behaviour for malloc'd memory would be to make free() do an erase
> operation as a system option. Creating "secure_free()" would be better.

If the memory isn't mlock'ed, the sensitive data may have been swaped in.
An overwrite of the memory location will not overwrite the data on swap,
if the process exits before the kernel needs to swap that area again.

A maybe-good-enough solution would be to the browser (or any application)
to generate a random key on startup and some buffers, lock them (and zero
when finished), and use the key to encrypt the sensitive data (on disc
cache and memory cache).

By using a stream cipher, it could be possible to have in a given instance
(like entering a password) only a single character unprotected.

A trojan or malicious user with access to the browsers' memory (via
ptrace, etc.) will then need to search for the key and the encrypted data.

If the trojan is intelligent and complicated enough, it can still have
some success, but with so many heterogeneous systems the attacker will
have to be very skilled.

Regards,
Luciano Rocha

[devnull@Rodents.Montreal.QC.CA]

[I am so thoroughly sick of broken-bounces cluttering up my mailbox
every time I mail to bugtraq that I'm posting with a From: address that
accepts mail and completely discards it. Use the address in my
signature if you want to actually reach me.]

> Of course, it's trivial to memset over a sensitive area when you're
> done with it, so programs ought to do so. Locking pages to prevent
> them from being written to disk may be more difficult: if it doesn't
> require special privilege then it's a potential DOS against physical
> memory resources, and if it does, then you may have to grant programs
> more privilege than they should have, creating a worse security hole.

The only security hole you'd create would be that DOS you mention.

Unless, of course, you're using an OS with a severely broken privilege
system, like the all-or-nothing model most Unix variants use. But
nobody would be silly enough to try to write secure code under
something like that, surely?

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B