bugtraq - Suggestion: erase data posted to the Web

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Wed, 7 Jul 2004 11:30:00 -0700 (PDT)
From: Andrew Daviel <advax@...umf.ca>
To: BUGTRAQ@...URITYFOCUS.COM
Subject: Suggestion: erase data posted to the Web

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@...umf.ca