Smalloc: secure malloc

After identifying sensitive variables, it becomes possible to erase their contents before shipping the core file. A difficulty arises in determining where the information resides in the core file, however, since in general the sensitive variables will be scattered throughout the entire core file. We need a way to communicate sensitivity information from the static analysis to the runtime cleaning process.

One method to recognize sensitive variables would be to append an immutable tag to each sensitive variable; the tag would describe the variable's sensitivity status. The post-processing cleaning step could then iterate over the core file and remove or overwrite all sensitive variables by checking for the tag.

An alternative approach, which we utilize, groups sensitive memory locations together and places an identifying header at the start of the region. This approach is ultimately more space-efficient than tagging each variable separately and simplifies the process of removing sensitive data from the core file.

Figure 1: Layout of a process's memory when using Scrash. Both heap regions are managed by Smalloc. The sensitive globals, sensitive stack, and sensitive heap are embedded within the insensitive heap region. The arrows indicate the direction of stack growth.

We have written Smalloc, a region-aware memory allocator, to manage this ``secure'' region. It is based on the Vmalloc package, which provides an ideal platform for creating allocators [15]. The interface to Smalloc is similar to malloc. The only difference is that we add an extra parameter to the smalloc function to identify whether the new memory should be allocated in the sensitive or insensitive memory region. The signatures of the realloc and free functions remain unchanged. See Figure 2 for the complete Smalloc interface.

Smalloc creates sensitive memory regions for heap allocated variables, sensitive global variables, and the sensitive stack. We will discuss these regions below. Each of the regions is actually embedded within the normal heap segment. The globals and stack regions are statically sized and allocated at program initialization. The size of the sensitive heap region is dynamic.

Figure 2: The Smalloc allocator interface. The allocation functions take an extra boolean parameter that specifies whether the data should be allocated in the sensitive region or on the insecure heap.

Figure 3: A sample code fragment that we will use to illustrate some of the transformations that Scrash uses (see Figure 4). It contains a sensitive global, a pointer to sensitive data, and a sensitive stack variable.

Figure 4: The results of running Scrash on the code fragment from Figure 3. Note that the constructor function __smalloc_global_init allocates the sensitive global inside the __smalloc_globals structure, which is allocated on the sensitive heap. This constructor function runs prior to main and is specified with the __constructor__ attribute. The sensitive heap variable password is now allocated on the secure heap. Finally, the sensitive local array cryptpw is allocated on the shadow stack. A new structure, check_shadow, contains this variable. Maintenance of the shadow stack is performed on entry and exit of the check function.