5 ms·

When a Memory Allocator Hides Security Bugs

66 points by hannob 8y ago

j16sdiz 8y ago
> and that indeed it seems some people did run the pool debugger in production (OpenBSD). .. another remote exploit for OpenBSD ?
- chousuke 8y ago
  OpenBSD doesn't include the Apache HTTP server, so while their default settings might expose Apache bugs if you choose to use it, it's not fair to say it's a vulnerability in OpenBSD
  - cryptonector 8y ago
    This reasoning is getting annoying. If you do nothing with your OS, it's secure! If you use software it bundles it's not secure and it's not their fault (but they'll fix it anyways)! That is just oh so gimmicky. It reflects quite poorly on the project.
    - bialpio 8y ago
      I think I'm missing something here. How is a bug in Apache an issue with OpenBSD?
      - mrkeen 8y ago
        I believe what's being referred to is the first sentence on the OpenBSD site: "Only two remote holes in the default install, in a heck of a long time!" A more cynical reading of it would be: "OpenBSD is secure as long as you don't run software on it." I share that cynicism. The discussion is relevant if you believe that an OS should have some responsibility for memory-related security issues.
        bialpio 8y ago
        Thanks for clarifying! Although I don't agree with the sentiment that OS should be responsible for these particular security issues...
        johnisgood 8y ago
        Emphasis on default install.
        wahern 8y ago
        > The discussion is relevant if you believe that an OS should have some responsibility for memory-related security issues. Pedantically speaking, your point is valid. But as a practical matter, OpenBSD is the operating system that takes these issues the most seriously. They formalized the notion of Unix-based privilege separation, and systematically employed it across the system. They regularly perform system-wide code audits (including of bundled software, such as Apache back when they actually bundled Apache) to identify and remediate high-risk source code patterns (e.g. strcpy -> strlcpy, realloc -> reallocarray, etc). While people [still] debate the merits and performance of things like seccomp or Capsium, OpenBSD has incorporated pledge(2) into the vast majority of binaries on the system. They were the first to apply stack canaries, ASLR, W^X, and most recently PIE globally by default. And apropos the article, they were the first to implement their system malloc in a robust way that maximized the chances of catching memory bugs, sometimes sacrificing performance in a way that would be inconceivable for Linux distributions. And all of these things have resulted in a steady stream of bug fixes upstream to third-party packages from the ports collection. One of the reasons OpenBSD forks projects like openssh or libressl, or implements from scratch services like iked, httpd, ntpd, relayd, smtpd, and many others, is precisely so they can assume full responsibility and control for things like memory management. See https://www.openbsd.org/innovations.html https://www.openbsd.org/innovations.html When a researcher points out a potential issue on OpenBSD, they're emphasizing their point by leveraging OpenBSD's credibility and the hard work put into the system.
      - detaro 8y ago
        It's an issue with the Apache package from the OpenBSD ports tree: it was set up in a configuration not recommended for production by upstream, which means bugs that weren't expected to actually trigger in practical use (and thus didn't get attention) could happen there.
    - pixl97 8y ago
      So I guess you love Windows with dozens of running executables and plenty of open ports out of the box? What, you don't want the Xbox service at start up?, too bad. OS security is rapidly decreased by increased running services. Minimizing your services reduces your risk footprint.
      - asveikau 8y ago
        It's funny how the tide of running executables seems to ebb and flow. Windows 7 seemed to be a good spot. With Windows 10 it's seemingly gone totally nuts again. They've had Windows Firewall enabled by default for several releases now so I don't think the open port thing is the same problem it used to be.
    - wahern 8y ago
      FWIW, OpenBSD doesn't bundle Apache. OpenBSD has shipped with a homegrown HTTP daemon for several years, now--https://www.openbsd.org/papers/httpd-asiabsdcon2015.pdf https://www.openbsd.org/papers/httpd-asiabsdcon2015.pdf Apache is available as a port/package, but not many people use it. Even when installing a port/package like PHP it's more common to run it through httpd using PHP-FPM (i.e. FastCGI).
nkurz 8y ago
Instead of switching to the debug allocator, might it instead be possible to teach ASAN about the pool allocator? I think I did this at some point in the past for Valgrind. I don't know if it would be sufficient, but with ASAN it's at least possible to "poison" and un-poison memory manually with macros: http://blog.hostilefork.com/poison-memory-without-asan/ http://blog.hostilefork.com/poison-memory-without-asan/
- maxlybbert 8y ago
  I really like APR. While pooled allocation isn’t always the best approach, it makes a lot of sense in server software, and reduces the risk of many classic memory problems (e.g., I don’t have to worry whether I pair 1000 mallocs with 1000 frees; it’s acceptable to pair 1000 apr_pallocs with a single apr_pool_free). ASAN is certainly helpful when using classic memory management techniques, but since so much C code uses custom memory management of some kind, it has to handle more than malloc and free. I certainly hope people improve ASAN instead of abandon things like memory pools. I would consider “malloc and free with ASAN” to be a step down from APR’s pools.
  - shereadsthenews 8y ago
    ASAN does handle this. As nkurz noted, custom allocators need only poison/unpoison memory regions to benefit from ASAN and MSAN. For example see how the absl "SwissTable" does: https://github.com/abseil/abseil-cpp/blob/master/absl/container/internal/raw_hash_set.h#L1587 https://github.com/abseil/abseil-cpp/blob/master/absl/contai...
- caf 8y ago
  Yes, Valgrind has support for annotating memory pool operations: http://valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools http://valgrind.org/docs/manual/mc-manual.html#mc-manual.mem...
gwern 8y ago
Heartbleed was also an example of a bug which was hidden from the various validation/static checking tools because OpenSSL was using custom memory allocation, wasn't it?
- nabnob 8y ago
  Yes. There's a good article here explaining why various static analysis tools didn't catch Heartbleed: https://dwheeler.com/essays/heartbleed.html https://dwheeler.com/essays/heartbleed.html >It is known that OpenSSL does not directly allocate and deallocate memory directly using standard calls. Instead, it used a caching freelist system internal to OpenSSL to reuse allocated memory. Since OpenSSL does not return (deallocate) memory back to the underlying system once it was done with it (in some cases), special tools could fail to detect some common weaknesses such as use-after-free or double-free that they would otherwise find. It also sometimes prevented some operating system and run-time mitigation mechanisms from working. In short, it is widely agreed that this OpenSSL memory allocation approach prevented many mitigation and weakness detection mechanisms from working.
jedisct1 8y ago
Expect many of these bugs with WebAssembly.
CJefferson 8y ago
I increasingly feel we need to apply more "sledgehammers" to security. If I was running servers with security I cared about, I would use a malloc which cleared all allocations, and the new llvm/clang flags which clear all stack variables to fix unitanialised problems. Maybe even try turning on the more advanced clang sanitizers, if I could afford the cpu time. If we, as programmers, want to be respected, we need to make every reasonable effort to improve security.
- cyphar 8y ago
  I believe OpenBSD does most of these things. The primary problem is that security is a tradeoff -- for instance OpenBSD completely disabled hyperthreading when it was discovered to be fundamentally insecure. That was a 50% performance hit right off the bat -- not everyone can afford to make such a tradeoff.
mattnewport 8y ago
Somewhat ironically, a major secondary reason we used custom allocators in games (performance bring the primary reason) was to find and diagnose memory bugs. Long before ASAN existed I worked with some very powerful in house memory debugging tools at EA, some of the functionality of which I still haven't seen matched in commercial or open source tools. Security wasn't the primary concern back then, it was avoiding memory leaks on platforms with no virtual memory and tight memory constraints and squashing bugs.
scoutt 8y ago
Misleading title... why all bugs are "security bugs" nowadays? It's just a bug. Also, the allocator does not hide the error. It's not a problem generated in or from the allocator. It's a problem generated by the programmer and the impossibility of static analyzers to know every allocator here and there.

66 points by hannob 8y ago

> and that indeed it seems some people did run the pool debugger in production (OpenBSD). .. another remote exploit for OpenBSD ?

chousuke 8y ago
OpenBSD doesn't include the Apache HTTP server, so while their default settings might expose Apache bugs if you choose to use it, it's not fair to say it's a vulnerability in OpenBSD
- cryptonector 8y ago
  This reasoning is getting annoying. If you do nothing with your OS, it's secure! If you use software it bundles it's not secure and it's not their fault (but they'll fix it anyways)! That is just oh so gimmicky. It reflects quite poorly on the project.
  - bialpio 8y ago
    I think I'm missing something here. How is a bug in Apache an issue with OpenBSD?
    - mrkeen 8y ago
      I believe what's being referred to is the first sentence on the OpenBSD site: "Only two remote holes in the default install, in a heck of a long time!" A more cynical reading of it would be: "OpenBSD is secure as long as you don't run software on it." I share that cynicism. The discussion is relevant if you believe that an OS should have some responsibility for memory-related security issues.
      - bialpio 8y ago
        Thanks for clarifying! Although I don't agree with the sentiment that OS should be responsible for these particular security issues...
      - johnisgood 8y ago
        Emphasis on default install.
      - wahern 8y ago
        > The discussion is relevant if you believe that an OS should have some responsibility for memory-related security issues. Pedantically speaking, your point is valid. But as a practical matter, OpenBSD is the operating system that takes these issues the most seriously. They formalized the notion of Unix-based privilege separation, and systematically employed it across the system. They regularly perform system-wide code audits (including of bundled software, such as Apache back when they actually bundled Apache) to identify and remediate high-risk source code patterns (e.g. strcpy -> strlcpy, realloc -> reallocarray, etc). While people [still] debate the merits and performance of things like seccomp or Capsium, OpenBSD has incorporated pledge(2) into the vast majority of binaries on the system. They were the first to apply stack canaries, ASLR, W^X, and most recently PIE globally by default. And apropos the article, they were the first to implement their system malloc in a robust way that maximized the chances of catching memory bugs, sometimes sacrificing performance in a way that would be inconceivable for Linux distributions. And all of these things have resulted in a steady stream of bug fixes upstream to third-party packages from the ports collection. One of the reasons OpenBSD forks projects like openssh or libressl, or implements from scratch services like iked, httpd, ntpd, relayd, smtpd, and many others, is precisely so they can assume full responsibility and control for things like memory management. See https://www.openbsd.org/innovations.html https://www.openbsd.org/innovations.html When a researcher points out a potential issue on OpenBSD, they're emphasizing their point by leveraging OpenBSD's credibility and the hard work put into the system.
    - detaro 8y ago
      It's an issue with the Apache package from the OpenBSD ports tree: it was set up in a configuration not recommended for production by upstream, which means bugs that weren't expected to actually trigger in practical use (and thus didn't get attention) could happen there.
  - pixl97 8y ago
    So I guess you love Windows with dozens of running executables and plenty of open ports out of the box? What, you don't want the Xbox service at start up?, too bad. OS security is rapidly decreased by increased running services. Minimizing your services reduces your risk footprint.
    - asveikau 8y ago
      It's funny how the tide of running executables seems to ebb and flow. Windows 7 seemed to be a good spot. With Windows 10 it's seemingly gone totally nuts again. They've had Windows Firewall enabled by default for several releases now so I don't think the open port thing is the same problem it used to be.
  - wahern 8y ago
    FWIW, OpenBSD doesn't bundle Apache. OpenBSD has shipped with a homegrown HTTP daemon for several years, now--https://www.openbsd.org/papers/httpd-asiabsdcon2015.pdf https://www.openbsd.org/papers/httpd-asiabsdcon2015.pdf Apache is available as a port/package, but not many people use it. Even when installing a port/package like PHP it's more common to run it through httpd using PHP-FPM (i.e. FastCGI).

nkurz 8y ago

Instead of switching to the debug allocator, might it instead be possible to teach ASAN about the pool allocator? I think I did this at some point in the past for Valgrind. I don't know if it would be sufficient, but with ASAN it's at least possible to "poison" and un-poison memory manually with macros: http://blog.hostilefork.com/poison-memory-without-asan/ http://blog.hostilefork.com/poison-memory-without-asan/

maxlybbert 8y ago
I really like APR. While pooled allocation isn’t always the best approach, it makes a lot of sense in server software, and reduces the risk of many classic memory problems (e.g., I don’t have to worry whether I pair 1000 mallocs with 1000 frees; it’s acceptable to pair 1000 apr_pallocs with a single apr_pool_free). ASAN is certainly helpful when using classic memory management techniques, but since so much C code uses custom memory management of some kind, it has to handle more than malloc and free. I certainly hope people improve ASAN instead of abandon things like memory pools. I would consider “malloc and free with ASAN” to be a step down from APR’s pools.
- shereadsthenews 8y ago
  ASAN does handle this. As nkurz noted, custom allocators need only poison/unpoison memory regions to benefit from ASAN and MSAN. For example see how the absl "SwissTable" does: https://github.com/abseil/abseil-cpp/blob/master/absl/container/internal/raw_hash_set.h#L1587 https://github.com/abseil/abseil-cpp/blob/master/absl/contai...
caf 8y ago
Yes, Valgrind has support for annotating memory pool operations: http://valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools http://valgrind.org/docs/manual/mc-manual.html#mc-manual.mem...

gwern 8y ago

Heartbleed was also an example of a bug which was hidden from the various validation/static checking tools because OpenSSL was using custom memory allocation, wasn't it?

nabnob 8y ago
Yes. There's a good article here explaining why various static analysis tools didn't catch Heartbleed: https://dwheeler.com/essays/heartbleed.html https://dwheeler.com/essays/heartbleed.html >It is known that OpenSSL does not directly allocate and deallocate memory directly using standard calls. Instead, it used a caching freelist system internal to OpenSSL to reuse allocated memory. Since OpenSSL does not return (deallocate) memory back to the underlying system once it was done with it (in some cases), special tools could fail to detect some common weaknesses such as use-after-free or double-free that they would otherwise find. It also sometimes prevented some operating system and run-time mitigation mechanisms from working. In short, it is widely agreed that this OpenSSL memory allocation approach prevented many mitigation and weakness detection mechanisms from working.

jedisct1 8y ago

Expect many of these bugs with WebAssembly.

CJefferson 8y ago

I increasingly feel we need to apply more "sledgehammers" to security. If I was running servers with security I cared about, I would use a malloc which cleared all allocations, and the new llvm/clang flags which clear all stack variables to fix unitanialised problems. Maybe even try turning on the more advanced clang sanitizers, if I could afford the cpu time. If we, as programmers, want to be respected, we need to make every reasonable effort to improve security.

cyphar 8y ago
I believe OpenBSD does most of these things. The primary problem is that security is a tradeoff -- for instance OpenBSD completely disabled hyperthreading when it was discovered to be fundamentally insecure. That was a 50% performance hit right off the bat -- not everyone can afford to make such a tradeoff.

mattnewport 8y ago

Somewhat ironically, a major secondary reason we used custom allocators in games (performance bring the primary reason) was to find and diagnose memory bugs. Long before ASAN existed I worked with some very powerful in house memory debugging tools at EA, some of the functionality of which I still haven't seen matched in commercial or open source tools. Security wasn't the primary concern back then, it was avoiding memory leaks on platforms with no virtual memory and tight memory constraints and squashing bugs.

scoutt 8y ago

Misleading title... why all bugs are "security bugs" nowadays? It's just a bug. Also, the allocator does not hide the error. It's not a problem generated in or from the allocator. It's a problem generated by the programmer and the impossibility of static analyzers to know every allocator here and there.