Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 16 submissions in the queue.
posted by martyb on Monday November 13, @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

Display Options Threshold/Breakthrough

Reply to Article

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.
(1)
  • (Score: -1, Offtopic) by Anonymous Coward on Monday November 13, @10:49AM (3 children)

    by Anonymous Coward on Monday November 13, @10:49AM (#596122)

    SOPA is being pushed again. Anyone give a shit any more!?

  • (Score: 0) by Anonymous Coward on Monday November 13, @02:22PM (8 children)

    by Anonymous Coward on Monday November 13, @02:22PM (#596192)

    The code itself is dual licensed GPL and proprietary.

    That rules out the BSDs.

    Not that they would care, this is supposedly comparable to the Linux malloc implementation (that would be the GNU malloc implementation?), and as far as I know, the FreeBSD one is much faster than the Linux one.

    • (Score: 0) by Anonymous Coward on Monday November 13, @04:09PM

      by Anonymous Coward on Monday November 13, @04:09PM (#596245)

      this is supposedly comparable to the Linux malloc implementation (that would be the GNU malloc implementation?)

      Yes, the paper talks about userspace applications, so they are presumably talking about the GNU C library (glibc) and not Linux.

    • (Score: 5, Informative) by Pino P on Monday November 13, @04:24PM (6 children)

      by Pino P (4721) on Monday November 13, @04:24PM (#596257) Journal

      The malloc() in Linux proper is either kmalloc() or vmalloc(). The difference [stackoverflow.com] is that vmalloc() is for large allocations, and kmalloc() is for anything that might be used for DMA.

      But reference 22 in the paper makes it clear that the authors are using "Linux" to mean glibc, a GNU component used in the GNU/Linux OS:

      Figure 1 provides an overview of Linux's default memory allocator [22].

      [...]

      [22] Doug Lea. [n. d.]. The GNU C Library. http://www.gnu.org/software/libc/libc.html. [gnu.org] ([n. d.]).

      Other user-space C standard library implementations used on top of Linux may or may not use Lea's dlmalloc:

      • (Score: 0) by Anonymous Coward on Tuesday November 14, @12:57AM

        by Anonymous Coward on Tuesday November 14, @12:57AM (#596589)

        I certainly can't take them seriously now.

      • (Score: 2) by darkfeline on Tuesday November 14, @04:37AM (4 children)

        by darkfeline (1030) on Tuesday November 14, @04:37AM (#596661) Homepage

        I’d just like to interject for a moment. What you’re refering to as Linux, is in fact, GNU/LInux, or as I’ve recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.

        Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called “Linux”, and many of its users are not aware that it is basically the GNU system, developed by the GNU Project.

        There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine’s resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called “Linux” distributions are really distributions of GNU/Linux.

        • (Score: 2) by Pino P on Tuesday November 14, @05:46AM (3 children)

          by Pino P (4721) on Tuesday November 14, @05:46AM (#596670) Journal

          The GNU project refuses to clarify how much of the GNU OS qualifies an operating environment for the "GNU/" label. But in response to David Johnson's attempt to reduce to absurdity [usermode.org] by turning Debian into a Ship of Theseus with the FreeBSD userland, I created a rule of thumb [pineight.com]. 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. This means DJGPP is GNU/MS-DOS, and MSYS, Cygwin, and WSL are GNU/Windows. (In fact, that's what the "gwin" stands for.)

          • (Score: 1) by dwilson on Tuesday November 14, @06:38AM (1 child)

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

            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, @05:02PM

              by Pino P (4721) on Tuesday November 14, @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.

          • (Score: 2) by Jesus_666 on Tuesday November 14, @11:12PM

            by Jesus_666 (3044) on Tuesday November 14, @11:12PM (#597048)
            Actually, MSYS, Cygwin and WSL should rather be called GNU\Windows.
(1)