Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Monday November 13 2017, @09:27AM   Printer-friendly
from the good-fast-and-cheap? dept.

A small team of researchers at the University of Texas at San Antonio has released their source code for a drop-in malloc replacement and published a paper, FreeGuard: A Faster Secure Heap Allocator (warning for PDF), describing it in detail. It utilizes a novel memory layout, reduces a large number of mmap calls, borrows the "freelist" idea from performance-oriented allocators, and introduces a range of additional security capabilities, all with only a very small performance hit. The paper makes frequent comparisons to the Linux and OpenBSD allocators.

In spite of years of improvements to software security, heap-related attacks still remain a severe threat. One reason is that many existing memory allocators fall short in a variety of aspects. For instance, performance-oriented allocators are designed with very limited countermeasures against attacks, but secure allocators generally suffer from significant performance overhead, e.g., running up to 10× slower. This paper, therefore, introduces FreeGuard, a secure memory allocator that prevents or reduces a wide range of heap-related attacks, such as heap overflows, heap over-reads, use-after-frees, as well as double and invalid frees. FreeGuard has similar performance to the default Linux allocator, with less than 2% overhead on average, but provides significant improvement to security guarantees. FreeGuard also addresses multiple implementation issues of existing secure allocators, such as the issue of scalability. Experimental results demonstrate that FreeGuard is very effective in defending against a variety of heap-related attacks.

The code itself is dual licensed GPL and proprietary.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1) by dwilson on Tuesday November 14 2017, @06:38AM (1 child)

    by dwilson (2599) Subscriber Badge on Tuesday November 14 2017, @06:38AM (#596687) Journal

    If you're using GNU Coreutils plus two other major components of GNU, such as glibc, GCC, Bash, or Emacs, you're using a GNU-based environment.

    Really? You're elevating Emacs to that level?

    So, if I use a linux kernel, GNU Coreutils, GCC, some other libc, Z shell, and... vim... ?

    --
    - D
  • (Score: 2) by Pino P on Tuesday November 14 2017, @05:02PM

    by Pino P (4721) on Tuesday November 14 2017, @05:02PM (#596860) Journal

    In this case I'd call it "ProvingAPoint/Linux" as a lead-in to the discussion of the practical advantages of "some other libc" over glibc, and conversely of GNU Coreutils over some other implementation of the core utilities. Most distributions I've seen that replace one of GNU Coreutils and glibc for either size or copyleft avoidance reasons also replace the other for the same reason.