DRAM data persistence

On a sunny day (Wed, 04 Jul 2007 17:13:42 GMT) it happened snipped-for-privacy@puntnl.niks (Nico Coesel) wrote in :

Well, maybe you should specify *what* OS you are talking about.

In not a single program or even OS I know about is memory cleared or as you state overwritten by some other value, _after_ an application ends. An application, if indeed written in C, ends normally by executing exit():

-----------------------------------------

- Function: void exit (int STATUS) The xit' function tells the system that the program is done, which causes it to terminate the process. STATUS is the program's exit status, which becomes part of the process' termination status. This function does not return.

Normal termination causes the following actions: 1. Functions that were registered with the
texit' or _exit' functions are called in the reverse order of their registration. This mechanism allows your application to specify its own "cleanup" actions to be performed at program termination. Typically, this is used to do things like saving program state information in a file, or unlocking locks in shared data bases.

1. All open streams are closed, writing out any buffered output data. See *Note Closing Streams::. In addition, temporary files opened with the mpfile' function are removed; see *Note Temporary Files::.
2. exit' is called, terminating the program. *Note Termination Internals::.

-----------------------------------------

If a program terminates abnormally (crash) exit is _not_ called. The memory stays as is in both cases, unless you specified something specific with 'atexit(your_function ) or on_exit(your_function, ..).

When an OS terminates all processes are killed, (or send a kill signal), and _unless_ these processes had special handlers programmed, memory will stay as is. On a PC platform often there is in BIOS a memory test that you can enable to run at boot time, and maybe that memory test is destructive, but it need not be (but likely is, as BIOS author will assume the system is booting up from a cold start).

It makes no sense to clear memory after program execution in DRAM _unless_ you are programming for some crypto sensitive stuff.

You can probably easily test on your PC if the memory is overwritten, by adding some pointers in your code, write some known data to it, and then restarting your application and dumping that area. Last time I did that all was still there...

Or you can just write a small program, do a malloc for some megabytes, and dump the code, good chance old and / or other application data is there.

All I know, what OS were you talking about? Not Vista I hope? As that is no OS but a scam. .

Any modern OS should do this.

Don't think C (there are other languages!) but think security where each application should live in its own sand box. In the end the OS gives and takes memory to an application. So its the OS which has the last thing to say about what happens to the memory that was used by the application.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

On a sunny day (Wed, 04 Jul 2007 18:27:51 GMT) it happened snipped-for-privacy@puntnl.niks (Nico Coesel) wrote in :

'Should' is a wish. However the genie has not yet emerged from the bottle.

I have mentioned that,

Not exactly,

That is a nice wish, but OS does not clear or overwrite memory when an application ends.

I will give you one example: memory mapped IO. In case of memory mapped IO (and this is ..electronics, some embedded systems use this a lot), memory locations (addresses) are actually IO ports. Now what do you think would happen if the OS decided to write random or _any_ value after your application exits????????

I disagree. Clearing memory takes time. If speed is the issue, you can save time by not clearing memory. Applications that handle secure data can clear the memory before freeing it so applications have control over the security issue.

The OS needs to keep overhead to a minimum. What you are suggesting adds a bunch of overhead. In time critical applications, this is a bad thing.

Name ONE operating system that does this. Besides, if I were to write a program for which leftover RAM (or swap) content was a security hole, I'd clear that memory myself before releasing it, rather than relying on your imaginary OS feature.

--Daniel

MVS, and I believe any other OS that is B2 rated.

--
  Keith

Yes, I think you are right. IBM's MVT didn't and this was the source of many security problems. This was because they assumed that anything in memory that had a key of zero was theirs but didn't enforce it. You could make a look alike for an OS data structure and free it then quickly use it. This way you could fool the OS into jumping to your code. I can imagine IBM nailing that door shut and bricking it up.

Read about security certification:

"- Object reuse functionality to clear file system and memory objects before re-use"

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

You have access to Google as well:

application ends.

REad the information at the link I posted above. The feature is mandatory for security certification.

use this

value

This sort of data is not allocated from the system's heap and not re-used by other applications.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

There seems to be some argument about what happens *after* an application ends.

I only know about Linux, so here is how Linux does it.

After an application ends, absolutely nothing is done with the memory. It gets returned to the kernel pool without clearing.

The kernel has access to to userspace anyway, so having old application memory contents turn up in the kernel is not a security problem.

To avoid leaking data into other processes, the kernel clears pages as they get mapped into user space.

When a program starts, it gets allocated 3GB (on X86-32) of virtual memory. All this memory is a repeat mapping of a single 4KB page containing zeros, but marked read-only.

If the application now calls malloc, it gets a block of virtual memory containing zeros. Only if the application

*writes* to the memory, a page fault gets triggered and the kernel maps a memory page at that location.

This memory is cleared before it gets mapped. Here is the kernel source code which does it:

/** * vmalloc_user - allocate zeroed virtually contiguous memory for userspace * @size: allocation size * * The resulting memory area is zeroed so it can be mapped to userspace * without leaking data. */ void *vmalloc_user(unsigned long size) { struct vm_struct *area; void *ret;

ret = __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO,_KERNEL); if (ret) { write_lock(&vmlist_lock); area = __find_vm_area(ret); area->flags |= VM_USERMAP; write_unlock(&vmlist_lock); } return ret; }

Kind regards,

Iwo

On a sunny day (Thu, 05 Jul 2007 16:21:56 GMT) it happened snipped-for-privacy@puntnl.niks (Nico Coesel) wrote in :

Is this what yo uare referring to?

# Object reuse functionality to clear file system objects as well as memory # and IPC objects before they can be reused by a process belonging to a # different user.

If so, note the words 'different user'. Also note 'before', not 'after' as you suggest. For the rest is is worthless, as root user can acces anything anytime. Further 'memory objects' likely (but I am not sure) refers to structures. As that is under 'object reuse' it has nothing to do with clearing DRAM IMO. It is sales men babble, and anyways RatHead is in bed with MS these days, the NSA / MS / RatHead combination will make sure anybody with the rank of assistent police traffic warden or higher will have full certified access to your data and full control and root pasword of your computers. Duh.

Almost falling of chair laughing.

Bad idea. Rule number one: never leave security to an application programmer. There should be a seperate 'layer' which deals with security (like a firewall).

Depends on your application. If you are developing stuff that is somehow connected to the outside world I'd rather invest in a faster CPU than having to explain my customers why their system was vulnerable to an attack. A lot of embedded hardware gets connected to a network these days. This makes life a lot easier but it comes with a huge amount of security issues which need to be addressed.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

On a sunny day (Thu, 05 Jul 2007 18:29:27 GMT) it happened snipped-for-privacy@puntnl.niks (Nico Coesel) wrote in :

I have just run the following program: #include #include

int main(int argc, char **argv) { int a, i; char *ptr; char t[1000];

ptr = t; for(i = 0; i < 1000; i++) { a = *ptr & 0xff; fprintf(stdout, "%02x", a); ptr++; }

ptr = t; for(i = 0; i < 1000; i++) { a = *ptr & 0xff; fprintf(stdout, "%c", a); ptr++; }

exit(1); } /* end function main */

Compiled like this: gcc -o test test.c

Gives as result: grml: ~ # ./test 2c57f2b77cadf3b78f50000010b0f3b7c088e3b7000000008255f2b7ac8204081037f2b7cc51f2b700000000fc53f2b7000000008caff3b705 etc etc...

So, pure DRAM, stack space... And this is one of the latest Linux kernels: grml: ~ # uname -a Linux grml 2.6.21 #1 Sat May 5 17:08:45 CEST 2007 i686 GNU/Linux

gcc version 4.0.3 20060104

If you do the same with malloc() you get zeros only (as explained by an otehr poster). Try it :-)

But that just invites trying to crash your program in such a way that it's cleanup routine won't be run.

You are assuming that unlimited CPU power can be bought and that it doesn't increase cost or power consuption. A simple bit of good programming practice of clearing the secret stuff before giving the memory back solves the security problems at much less cost in performance.

It invites the attempt but doesn't mean it will happen. An OS that clears memory before it allocates can still have failure modes where it doesn't do that right. Also lowering the CPU voltage or stopping its clock or running a huge program with a high priority to force a swap to disk followed by a power off. I can think of many ways to try.

2c57f2b77cadf3b78f50000010b0f3b7c088e3b7000000008255f2b7ac8204081037f2b7cc51f2b700000000fc53f2b7000000008caff3b705

Hi Jan,

what you see are left over stack frames from the C-library initialisation. If you extend the stack into virgin territory you get the same zeros. Try this:

#include

void fun(int stage) { unsigned char b[1024]; if (stage>0) fun(stage-1); else { int i; for (i=0; i

On a sunny day (Fri, 06 Jul 2007 14:34:49 +0100) it happened Iwo Mergler wrote in :

That sure is an interesting recursive code :-) Had to look several times before I understood it.

Yes, it seems you are right, I get all zeros too with it.

Well, there is much talk about buffer overflows, where the stack for example is used to execute code. Some picture viewers and even some media players were (or are?) affected.

Good info, thank you. Why make so much trouble to read memory, just break in as root[kit or is it kid ;-)]:

#include #include

int main(int argc, char **argv) { int a, i; FILE *fptr;

fptr = fopen("/proc/kcore", "r"); if(! fptr) { fprintf(stderr, "test3: could not open /proc/kcore for read, aborting.\\n");

exit(1); }

for(i = 0; i < 1000; i++) { a = fgetc(fptr); fprintf(stdout, "%02x ", a); }

exit(0); } /* end function main */

Right?

it is correct.

nope. the malloc system is internal to the application. the memory that malloc arranges for your app was cleared by the operating system before it is given to malloc the first time. malloc may recycle it, so that's why it can be dirty...

maybe... it depends, clearing ram is a useful task for an operating system to do in idle time, that way it's ready for the next application that needs more ram.

Bye. Jasen