OpenBSD Journal

Extra paranoia for malloc(3)

Contributed by ray on from the can't-touch-this dept.

Damien Miller (djm@) recently committed some extra paranoia for malloc(3): 
CVSROOT:        /cvs
Module name:    src
Changes by:     djm@     2008/12/29 15:25:50

Modified files:
       lib/libc/stdlib: malloc.3 malloc.c

Log message:
extra paranoia for malloc(3):

Move all runtime options into a structure that is made read-only
(via mprotect) after initialisation to protect against attacks that
overwrite options to turn off malloc protections (e.g. use-after-free)

Allocate the main bookkeeping data (struct dir_info) using mmap(),
thereby giving it an unpredictable address. Place a PROT_NONE guard
page on either side to further frustrate attacks on it.

Add a new 'L' option that maps struct dir_info PROT_NONE except when
in the allocator code itself. Makes attacks on it basically impossible.

feedback tedu deraadt otto canacar
ok otto
Thanks Damien for the hard work!

(Comments are closed)

Comments

  1. By Frank DENIS (82.224.188.215) on http://00f.net

    Note that the L feature was just reverted.

    Comments

    1. By Brynet (Brynet) on

      > Note that the L feature was just reverted.

      Indeed, I guess the performance hit was too severe.. a shame. :(

      So.. Will this entry get axed? or.. revised?

      Comments

      1. By Otto Moerbeek (otto) on http://www.drijf.net

        > > Note that the L feature was just reverted.
        >
        > Indeed, I guess the performance hit was too severe.. a shame. :(
        >
        > So.. Will this entry get axed? or.. revised?

        Only the L part was reverted.

    2. By Anonymous Coward (99.246.35.67) on

      > Note that the L feature was just reverted.

      The relevant post to openbsd-cvs:

      http://marc.info/?l=openbsd-cvs&m=123062313320944&w=2

      Comments

      1. By Anonymous Coward (2a01:198:25d:0:20a:e4ff:fe32:17b2) on

        > http://marc.info/?l=openbsd-cvs&m=123062313320944&w=2

        GAAAH!

        > ... we
        > don't do optional security

        Why? I mean, *all* of the malloc options are optional.
        That's why they are options. Non sequitur.

        Comments

        1. By Can Acar (72.130.182.114) canacar@ on

          > > http://marc.info/?l=openbsd-cvs&m=123062313320944&w=2
          >
          > GAAAH!
          >
          > > ... we
          > > don't do optional security
          >
          > Why? I mean, *all* of the malloc options are optional.
          > That's why they are options. Non sequitur.

          Other malloc *options* are not security features. Some of them such as guard pages also help security, but they are mainly used for development and debugging. Real security features like randomized allocations and canaries are not options at all. The proposed 'L' option was a security-only feature, and it was expensive. Nobody would turn it on if it was off by default.

          No need to add code that nobody will use. It makes the code more complex to maintain. These pieces would remain untested and unmaintained, perhaps introducing subtle bugs in the future.

          Look at what Microsoft did with their own address space randomization work. They added address space randomization and non-execute (NX) support with XP SP2. They also have an impressive heap implementation with canaries and all. The problem is that applications have to 'opt-in' to use most of these "features". The result: Check out the exploits for recent Internet Explorer vulnerabilies -- an attacker can force any one of the non-randomized modules to be loaded and therefore bypass all the security that address randomization provides.

          Optional security does NOT work.

          Comments

          1. By rgouveia (rgouveia) on cosmico.net

            >Look at what Microsoft did with their own address space randomization work.

            Are you talking about DEP?

            Comments

            1. By Can Acar (137.110.192.40) canacar@ on

              > >Look at what Microsoft did with their own address space randomization work.
              >
              > Are you talking about DEP?
              >

              This is a good technical summary of the IE vulnerability:
              http://blogs.msdn.com/sdl/archive/2008/12/18/ms08-078-and-the-sdl.aspx

              and there were some related presentations at BlackHat/DefCon as well.

  2. By Anonymous Coward (92.74.50.230) on 

    what's the purpose of this code?

+	while ((mopts.malloc_canary = arc4random()) == 0)
+		;


thanks.

    Comments

    1. By Anonymous Coward (92.74.50.230) on

      >
      > what's the purpose of this code?
      >
      > + while ((mopts.malloc_canary = arc4random()) == 0)
      > + ;
      >
      >
      > thanks.
      >

      ugh. looks like to make it random but not 0.

      Comments

      1. By Peter J. Philipp (62.75.160.180) on http://solarscale.de

        > >
        > > what's the purpose of this code?
        > >
        > > + while ((mopts.malloc_canary = arc4random()) == 0)
        > > + ;
        > >
        > >
        > > thanks.
        > >
        >
        > ugh. looks like to make it random but not 0.

        This is bothersome, 0 is random too.

        Comments

        1. By Igor Sobrado (156.35.192.2) on

          > > ugh. looks like to make it random but not 0.
          >
          > This is bothersome, 0 is random too.

          A cracker will probably overwrite memory with zeroes. To be really useful (i.e., to detect nasty events), a canary should take a random value different from zero.

          Cheers,
          Igor.

          Comments

          1. By Daniel Gracia (paladdin) on http://www.alpuntodesal.com

            > > > ugh. looks like to make it random but not 0.
            > >
            > > This is bothersome, 0 is random too.
            >
            > A cracker will probably overwrite memory with zeroes. To be really useful (i.e., to detect nasty events), a canary should take a random value different from zero.
            >
            > Cheers,
            > Igor.

            Just to evade divide by zero errors (if aritmetics are applied later), skip zero values in random variables is a good idea mostly everywhere!

            Comments

            1. By Igor Sobrado (89.128.5.72) on

              > Just to evade divide by zero errors (if aritmetics are applied later), skip zero values in random variables is a good idea mostly everywhere!

              Huh? Where is mopts.malloc_canary used that way?

              Comments

              1. By Anonymous Coward (88.65.246.72) on

                > > Just to evade divide by zero errors (if aritmetics are applied later), skip zero values in random variables is a good idea mostly everywhere!
                >
                > Huh? Where is mopts.malloc_canary used that way?

                it's used for xor operation later.

                Comments

                1. By Igor Sobrado (89.128.5.72) on

                  > > > Just to evade divide by zero errors (if aritmetics are applied later), skip zero values in random variables is a good idea mostly everywhere!
                  > >
                  > > Huh? Where is mopts.malloc_canary used that way?
                  >
                  > it's used for xor operation later.

                  xor is a logical operation that can be used to quickly check if the canary has changed (it shouldn't!). However, xor will never elicit a divide by zero error. The reason to skip zero values in mopts.malloc_canary is avoid a case that will not allow detecting a possible problem.

              2. By Anonymous Coward (219.90.157.173) on

                > > Just to evade divide by zero errors (if aritmetics are applied later), skip zero values in random variables is a good idea mostly everywhere!
                >
                > Huh? Where is mopts.malloc_canary used that way?

                I think this was a general comment regarding usage of random numbers.

                In any event, one should always be aware of the range of possible values their random variables may hold (and limit the range accordingly). Problems can occur not only from zero values.

        2. By tedu (udet) on


          > This is bothersome, 0 is random too.

          Just not random enough.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]