Bugtraq mailing list archives
Re: Suggestion: erase data posted to the Web
From: Luciano Miguel Ferreira Rocha <strange () nsk no-ip org>
Date: Wed, 7 Jul 2004 23:22:46 +0100
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
Current thread:
- Suggestion: erase data posted to the Web Andrew Daviel (Jul 07)
- Re: Suggestion: erase data posted to the Web Nick Lamb (Jul 08)
- Re: Suggestion: erase data posted to the Web Luciano Miguel Ferreira Rocha (Jul 08)
- <Possible follow-ups>
- RE: Suggestion: erase data posted to the Web Michael Wojcik (Jul 08)
- Re: Suggestion: erase data posted to the Web devnull (Jul 09)