Are uninitialized values ever a security risk?

Question

While learning C, I made some mistakes and printed elements of a character array that were uninitialized. If I expand the size of the array to be quite large, say 1 million elements in size and then print the contents, what comes out is not always user unreadable, but seems to contain some runtime info. Consider the following code: ``` #include <stdio.h> main() { char s[1000000]; int c, i; printf("Enter input string:
"); for (i = 0; ( c = getchar()) != '
'; i++) { s[i] = c; } printf("Contents of input string:
"); for (i = 0; i < 999999; i++) { putchar(s[i]); } printf("
"); return 0; } ``` Just scrolling through the output, I find things such as: ???l????????_dyldVersionNumber_dyldVersionString_dyld_all_image_infos_dyld_fatal_error_dyld_shared_cache_ranges_error_string__mh_dylinker_header_stub_binding_helper_dyld_func_lookup_offset_to_dyld_all_image_infos__dyld_start__ZN13dyldbootstrapL30randomizeExecutableLoadAddressEPK12macho_headerPPKcPm__ZN13dyldbootstrap5startEPK12macho_header…

Accepted Answer

Most `C` programs use `malloc` to allocate memory. A common misunderstanding is that `malloc` zeros out the memory returned. It actually does not. As a result, due to the fact that memory chunks are "recycled" it is quite possible to get one with information of "value". An example of this vulnerability was the `tar` program on Solaris which emitted contents of `/etc/passwd`. The root cause was the fact that the memory allocated to `tar` to read a block from disk was not initialized and before getting this memory chunk the `tar` utility made a OS system call to read `/etc/passwd`. Due to the memory recycling and the fact that `tar` did not initialize the chunk fragments of `/etc/passwd` were printed to logs. This was solved by replacing `malloc` with `calloc`. This is an actual example of security implication if you don't explicitly and properly initialize memory. So yes, do initialize your memory properly.

Update:

Is there no way for a program to declare its memory content protected to allow the OS to restrict any access to it other than the program that initialized that memory?

The answer is yes (see in the end) and no. I think that you view it the wrong way here. The more appropriate question would be for example, why doesn't `malloc` initialize the memory on request or clears the memory on release but instead recycles it? The answer is that the designers of the API explicitly decided not to initialize (or clear memory) as doing this for large blocks of memory 1)would impact performance and 2)is not always necessary (for example you may not deal, in your application or several parts in your application with data that you actually care if they are exposed). So the designers decided not to do it, as it would inadvertently impact performance, and to drop the ball to the programmer to decide on this. So carrying this also to the OS, why should it be the OS's responsibility to clear the pages? You expect from your OS to hand you memory in a timely manner but security is up to the programmer.

Having said that there are some mechanism provided that you could use to make sure that sensitive data are not stored in swap using mlock in Linux.

mlock() and mlockall() respectively lock part or all of the calling process's virtual address space into RAM, preventing that memory from being paged to the swap area. munlock() and munlockall() perform the converse operation, respectively unlocking part or all of the calling process's virtual address space, so that pages in the specified virtual address range may once more to be swapped out if required by the kernel memory manager. Memory locking and unlocking are performed in units of whole pages.

Are uninitialized values ever a security risk?

Solution

Problem

Related problems