OpenBSD Journal

heartbleed vs malloc.conf (updated)

Contributed by tbert on from the exploit-mitigation-mitigation dept.

Ted Unangst (tedu@) has posted an article about how OpenSSL has managed to sidestep OpenBSD's malloc.conf(3) protections:

About two years ago, OpenSSL introduced a new feature that you’ve never used or even heard about until yesterday, after somebody discovered a bug that could be used to read process memory.

As they say, read the whole thing.

Update:
tedu@ has a follow up post in which he finds a particularly nasty bug in the code which sidesteps the malloc.conf options, which means that it cannot, unpatched, be disabled:

Instead of telling people to find themselves a better malloc, OpenSSL incorporated a one-off LIFO freelist. You guessed it. OpenSSL misuses the LIFO freelist. In fact, the bug I’m about to describe can only exist and go unnoticed precisely because the freelist is LIFO.

As they say, read this other thing.

(Comments are closed)


Comments
  1. By Sebastian Rother (80.153.96.240) on

    An interesting inview.
    During reading malloc.conf I came up with the question: Can a user apply serval settings at once?

    So combining J with G?

    --
    # cat /etc/malloc.conf
    A
    G
    F
    --

    What mode would be used? All, the last one, the first one?
    I know about S but what if a user wants just a mix of specific options?

    Kind regards,
    Sebastian

    Comments
    1. By Anonymous Coward (86.41.44.204) on

      malloc.conf should by a symlink. Read malloc options section in the man page.

      Comments
      1. By Sebastian Rother (80.153.96.240) on

        Well I thought I did read the manpage....

        The manpage states:

        --
        Malloc will first look for a symbolic link called /etc/malloc.conf and
        next check the environment for a variable called MALLOC_OPTIONS and
        finally for the global variable malloc_options and scan them for flags in
        that order. Flags are single letters, uppercase means on, lowercase
        means off.
        --

        It does not state if you can or can not specify multiple different options like each a line or how the file gets parsed (last match wins, first match wins, all options are used). Does each option has to be on a seperated line, could I maybe line them up behind each others?

        The manpage is not clear about such specific use cases.
        And that I wrote about the "S" option should imply that I read this section already.

        At least it aint clear for me if somebody can use 3 different options or not and if so how the file needs to look like (one option per line?).

        If you could point me out to the part of the manpage where this is clarified it would be kind from you because I seam to miss it.

        Kind regards,
        Sebastian Rother

        Comments
        1. By phessler (phessler) on why in god's name am I wearing pants?

          So to set a systemwide reduction of the cache to a quarter of the default
          size and use guard pages:
          # ln -s 'G<<' /etc/malloc.conf

          The flags are mostly for testing and debugging. If a program changes
          behavior if any of these options (except X) are used, it is buggy.

          That sets the 'G', the '<' and the '<' options.

          To set more options, just add them to the symlink that is created.

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

          It helps to read the whole section. It even contains an example.

          Comments
          1. By Marc Espie (espie) on

            > It helps to read the whole section. It even contains an example.

            Otto, you're assuming people know how to read. I'm pretty sure at least one of the contributors to this thread "fakes" it. That he knows how to parse basic english, and is able to generate almost lifelike drivels, but it doesn't mean all the dots are connected, and that he's actually able to make sense of what he parses...

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.]