DieHard, the Software

Roland Piquepaille writes "No, it's not another movie sequel. DieHard is a piece of software which helps programs to run correctly and protects them from a range of security vulnerabilities. It has been developed by computer scientists from the University of Massachusetts Amherst — and Microsoft. DieHard prevents crashes and hacker attacks by focusing on memory. Our computers have thousands times more memory than 20 years ago. Still, programmers are privileging speed and efficiency over security, which leads to the famous "buffer overflows" which are exploited by hackers."

Comments

Vista already doing some of this

[PurifyYourMind]

Along the same lines anyway... a new feature in Vista: Address space layout randomization (ASLR) is a computer security technique which involves arranging the positions of key data areas, usually including the base of the executable and position of libraries, heap, and stack, randomly in a process' address space. http://en.wikipedia.org/wiki/Address_space_layout_ randomization

Re:Vista already doing some of this

[Ristretto]

Hi Slashdot readers,

DieHard's randomization is very different from what OpenBSD does, not to mention Vista's address-space randomization. I've added a note to the FAQs that explains the difference in some detail, and answers several other questions, but in short: "address-space randomization" randomizes the base address of the heap and also mmapped-chunks of memory, leaving the relative position of objects intact. By contrast, DieHard randomizes the location of every single object across the entire heap. It also goes further in that it prevents a wide range of memory errors automatically, like double frees and illegal frees, and effectively eliminates heap corruption.

-- Emery Berger

Re:Vista already doing some of this

[strider44]

You could have just looked it up and seen that it's been in Linux for a similar length of time (in 2.6.x). I just googled for "linux address randomization" and clicked the top link.

Re:Vista already doing some of this

[nacturation]

Seems like OpenBSD's implementation does what DieHard claims, or at least some of it. See this interview from August 2005 for information:

http://kerneltrap.org/node/5584

Any thoughts?

Re:Vista already doing some of this

[iamacat]

No, it won't. Programs need to interoperate - you might want to explicitly upload a photo to shutterfly using your web browser, but you don't want a rogue website to just siphon off all your private photos by exploiting a memory bug in one of the endless plugins.

The real solution is programming in a language with secure memory management, such as .Net, Java or even LISP. I suspect that overhead is far smaller than running 3 copies of the program at once like DieHard does.

Re:Vista already doing some of this

[Alioth]

OpenBSD prevents double frees and illegal frees and heap corruption too, and has been doing so for at least a couple of years. The code is BSD licensed too, so you can use it in closed source products like Windows. OpenBSD also has had something called W^X (Write XOR execute) for several years now, even for CPU architectures that don't support making executable pages read-only.

Re:Vista already doing some of this

[Ristretto]

Hi,

Here's a more detailed answer -- I'll add it to the FAQ.

OpenBSD (a variant of PHKmalloc) does some of what DieHard's allocator does, but DieHard does much more. On the security side, DieHard adds much more "entropy"; on the reliability side, it mathematically reduces the risk that a programmer bug will have any impact on program execution.

OpenBSD randomly locates pages of memory and allocates small objects from these pages. It improves security by avoiding the effect of certain errors. Like DieHard, it is resilient to double and invalid frees. It places guard pages around large chunks and frees such large chunks back to the OS (causing later references through dangling pointers to fail unless the chunk is reused). It attempts to block some buffer overflows by using page protection. Finally, it shuffles some allocated objects around on a page, randomizing their location within a page.

DieHard goes much further. First, it completely segregates heap metadata from the heap, making heap corruption (and hijack attacks) nearly impossible. On OpenBSD, a large-enough underflow on OpenBSD can overwrite the page directory or local page info struct (at the beginning of each page), hijacking the allocator. This presentation describes several ways OpenBSD's allocator can be attacked. By contrast, none of DieHard's metadata is located in the allocated object space.

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

DieHard's complete randomization is key to provably avoiding a range of errors with high probability. It reduces the worst-case odds that a buffer overflow has any impact to 50%. The actual likelihood is even lower when the heap is not full. DieHard also avoids dangling pointer errors with very high probability (e.g., 99.999%), making it nearly impervious to such mistakes. You can read our PLDI paper for more details and formulae.

-- Emery Berger

Different program?

[Anonymous Coward]

I thought DieHard was a random number generator test suite. It is annoying when people dont even look around for other programs with the same name and do similar things.

nothing to do with VMs - just exception handling

[Anonymous Coward]

Ada's been doing that kind of runtime checking and throwing exceptions for 20 years now without needing a VM to enable exception handling.

Corrections

[SuperKendall]

Basically almost every point you raised can be addressed simply by saying "get your head out of five years in the past". Moderm GC can take little overhead, and will run when needed even with the CPU being consumed.

Swing does not really have the problems you speak of any longer, if you are using it right... heck, it didn't really have those problem to any great degree about seven years ago when I was building a large custom client app all in swing for only desktop deployment.

Complaining about the build system is like saying GCC has a bad build system - really it has no build system, and you should use something made for building Java. That is why we have Ant and the like...

Of the remainder, I really only think #7 has much in the way of merit. Have you looked into the java.nio package? This makes working with binary data much simpler...

Do NOT INSTALL THIS

[cowholio4]

BTW Do not install this crap... I do software development and this program has made it impossible to compile/run my programs (even after I uninstalled it) and also while it was running it would not allow Eclipse to run. So basically this program screwed me over big time. I am writing a database that is is to be deployed tomorrow morning. **&**&**&*&* ..... Note to self: Do this crap in a virtual machine and not while developing a program.

It's the programmers fault?

[X-Phile]

I don't think it's typically the programmers fault that there are security issues with the software. If the programmer was taught how to do things properly, then they would do things properly. Also, if they weren't so rushed to get a product out the door, they would be able to do a proper review and test of the code and find a majority of the bugs before the product hits the streets (or the server room in the case of custom software)

Typically, a programmer is doing their job. The programmers manager is doing their job, by squeezing the work and deadlines of the programmers.

My $0.02 CDN

Re:Correction

[durdur]

> Sure, the major platforms are supported, but that's it

What platforms do you want? Java is on 32- and 64-bit Windows, 32- and 64-bit Linux, Solaris (SPARC + Intel), AIX, HP-UX, OS X (Intel + PPC), IBM z/OS and iSeries, AND FreeBSD (http://www.freebsd.org/java/) among other platforms. FreeBSD guys negotiated a license (but with Java GPL now they won't need to in future).

I would also disagree about portability of code. J2SE apps are very portable. Usually with zero platform specific code changes. J2EE is another story.