README.md

if downloading from GitHub, make sure to use --recursive, as in:git clone --recursive https://github.com/emeryberger/DieHard

DieHard

DieHard: An error-resistant memory allocator for Windows, Linux, and Mac OS X

DieHard / Exterminator / DieHarder

Copyright (C) 2005-2018 by Emery Berger
University of Massachusetts Amherst

http://www.emeryberger.com
http://www.diehard-software.org
http://www.die-harder.org

This distribution includes the source for three systems.

DieHard was the direct inspiration for the Fault-Tolerant Heapincorporated in Windows 7, though it goes far beyond it in terms ofreliability.

DieHard automatically hardens software applications against a widerange of bugs. These bugs -- known as memory errors -- often end upas serious security vulnerabilities, cause crashes, or lead tounpredictable behavior. DieHard either eliminates these bugsaltogether, or avoids them with high probability. In other words,DieHard can take some buggy programs and make them bug-free (or closeto it).

DieHard was first described in the Berger and Zorn PLDI 2006 paperDieHard: Probabilistic Memory Safety for UnsafeLanguages (ACMlink), though theDieHarder paper presents a more up-to-date description.

Exterminator builds on DieHard (in fact, using a variant calledDieFast, and uses statistical inference to locate and fix memoryerrors. Exterminator first appeared in the PLDI 2007 paper Exterminator: automatically correcting memory errors with high probability(ACM link),and Communications of the ACM featureda more concise version as a technical highlight in December 2008 (ACM link).

Build and usage instructions

Windows

To build the Windows version (randomized runtime only), do this:

% nmake /f Makefile.win32

To use DieHard as a library with your application, link your programas follows:

% cl /MD yourapp.cpp usewinhard.obj winhard.lib

Copy winhard.dll to the same directory as the executable.

Linux / Solaris

Build the shared library with make. You can either link in theresulting shared object (libdiehard.so), or use DieHard bysetting the LD_PRELOAD environment variable, as in:

% setenv LD_PRELOAD /path/to/diehard/libdiehard.so

To use the replicated version, invoke your program with (for example):

% diehard 3 /path/to/libdiehard_r.so yourapp

This would create 3 replicas of yourapp. If the application does notread from standard input, add < /dev/null to the command line.

Mac OS X

To use DieHard, build with "make darwin" and set two environment variablesas follows:

% export DYLD_INSERT_LIBRARIES=/path/to/libdiehard.dylib

DieHard will then replace the system malloc in any new application executedfrom that terminal window.

Notes about the source code:

This directory contains the source code for DieHard. The version hereuses an adaptive algorithm that differs substantially from thatdescribed in the PLDI 2006 paper (../docs/pldi2006-diehard.pdf). Inparticular, this version adjusts its heap size dynamically rather thanrelying on a static, a priori heap choice.

The original version, as described in the PLDI 2006 paper, is in thesubdirectory static/. In addition, the support for replication is inthe subdirectory replicated/.

The fault injectors described in the PLDI paper are in the util/directory. The library libbrokenmalloc.so can be used to inject bufferoverflows and dangling pointer errors. To inject buffer overflows,just set LD_PRELOAD to point to libbrokenmalloc.so, and set theappropriate environment variables (shown at startup). To injectdangling pointer errors, you must first run the program withlibtrackalloc.so preloaded, and then run it on the same inputs withlibbrokenmalloc.so.

Frequently Asked Questions

What does DieHard do?

DieHard prevents some nasty errors - ones that crash programs and leadto security vulnerabilities. These are memory errors, includingdouble-frees & heap corruption (which DieHard eliminates), anddangling pointer errors (or stale pointers) and heap buffer overflows(which DieHard makes unlikely to have any effect). Who should useDieHard?

DieHard is good for software developers, since it makes programmererrors unlikely to crash a program and reduces the risk of securityvulnerabilities. It's also good for end users, who can take advantageof DieHard's protections now. What versions of Windows (& Firefox)does DieHard support?

In addition to supporting nearly any application for Linux andSolaris, DieHard currently protects Firefox on Windows XP and2003. DieHard works with Firefox versions 1.5.0.9 and higher, as wellas version 2.0.0.1.

Can DieHard protect any other application than Mozilla?

On Windows, the DieHard protection system currently supports Mozillaonly; we plan to add more applications soon. On Linux, DieHard canprotect any application. In addition, programmers using DieHard (onWindows or Linux) can protect any application they are developing.

My security program claims that the DieHard zip file contains a virus - can that be true?

Absolutely not. Your security program (so far, I only know of one, by"astaro") noticed that the distribution contains an example HTML filethat shows how DieHard works. And that HTML does not contain a virus,either! It just causes certain versions of Mozilla to crash if youaren't running DieHard.

Does running DieHard significantly slow down a system?

Unless your system had too little memory installed, DieHard generally has noperceptible performance impact on applications like Firefox.

How much more memory does DieHard require?

That depends on your application, but in general, memory consumption will increase somewhat.

Does DieHard protect only programs launched after it is activated?

Yes.

I see that DieHard runs multiple copies of a program and "votes". How many copies of a program are running at the same time?

There is a version of DieHard for Linux that runs multiple replicassimultaneously, and then you can choose how many replicas you wouldlike to run. However, the Windows version runs just one copy of yourprogram.

Does DieHard prevent all crashes? If not, what does it prevent?

No, although that would be nice. DieHard completely preventsparticular memory management errors from having any effect (these are"double frees" and "invalid frees"). It dramatically reduces thelikelihood of another kind of error known as "dangling pointer"errors, and lowers the odds that moderate buffer overflows will haveany effect. It prevents certain library-based heap overflows (e.g.,through strcpy), and all but eliminates another problem known as "heapcorruption."

How does DieHard differ from Vista's, OpenBSD's, and Linux's "address space randomization"?

Address space randomization places large chunks of memory (obtainedvia mmap / VirtualAlloc) at different places in memory, but leavesunchanged the relative position of heap objects. Linux adds somechecks for particular memory management errors (and then aborts theprogram).

Longer technical answer: OpenBSD (a variant of PHKmalloc) does some ofwhat DieHard's allocator does, but DieHard does much more. On thesecurity side, DieHard adds much more "entropy"; on the reliabilityside, it mathematically reduces the risk that a programmer bug willhave any impact on program execution.

OpenBSD randomly locates pages of memory and allocates small objectsfrom these pages. It improves security by avoiding the effect ofcertain errors. Like DieHard, it is resilient to double and invalidfrees. It places guard pages around large chunks and frees such largechunks back to the OS (causing later references through danglingpointers to fail unless the chunk is reused). It attempts to blocksome buffer overflows by using page protection. Finally, it shufflessome allocated objects around on a page, randomizing their locationwithin a page.

DieHard goes much further. First, it completely segregates heapmetadata from the heap, making heap corruption (and hijack attacks)nearly impossible. On OpenBSD, a large-enough underflow on OpenBSD canoverwrite the page directory or local page info struct (at thebeginning of each page), hijacking the allocator. By contrast, none ofDieHard's metadata is located in the allocated object space.

Second, DieHard randomizes the placement of objects across the entireheap. This has numerous advantages. On the security side, it makesbrute-force attempts to locate adjacent objects nearly impossible --in OpenBSD, knowing the allocation sequence determines which pagesobjects will land on (see the presentation pointed to above).

DieHard's complete randomization is key to provably avoiding a rangeof errors with high probability. It reduces the worst-case odds that abuffer overflow has any impact to 50%. The actual likelihood is evenlower when the heap is not full. DieHard also avoids dangling pointererrors with very high probability (e.g., 99.999%), making it nearlyimpervious to such mistakes. You can read the PLDI paper for moredetails and formulae.

Acknowledgements

This work is supported in part by the National Science Foundation,Intel Corporation, and Microsoft Research. This material is based uponwork supported by the National Science Foundation under Grant NoCNS-0615211. Any opinions, findings and conclusions or recommendationsexpressed in this material are those of the author(s) and do notnecessarily reflect the views of the National Science Foundation(NSF).