4 ms·

For critical system daemons, using a custom memory allocator that disables the in-built system security is insane. Injectable allocators that fill the heap with

by aortega 12y ago

For critical system daemons, using a custom memory allocator that disables the in-built system security is insane. Injectable allocators that fill the heap with function pointers in predictable positions are what make exploiting them easy.

masklinn 12y ago
On the other hand, as far as I know most systems don't bundle security features in their standard allocators. I'm not sure any non-bsd system does.
- throwaway2048 12y ago
  Both OSX and especially Windows have extensive memory security features baked into their system allocators (ASLR, SSP, NX bit support, Guard pages, background page zeroing, etc) and even glibc has some basic security features. Its kind of funny that windows is way ahead of your average linux distro on this front, considering the typical attitude with regards to how secure one is compared to the other. Also its not really the BSDs that have these types of security features, its pretty much exclusively OpenBSD. FreeBSD has code support for several of these features but it is not enabled by default, and tends to break things badly when it is enabled, although work is (finally) being done to fix this situation.
  - Hello71 12y ago
    ASLR: enabled by default on virtually all Linux systems, can be improved with the installation of PaX. disabled by default on Windows systems. KASLR: Windows has it, Linux does too, but only since 3.14. SSP: libc specific, but MSVS since 2003 has basic stack-smashing support similar to gcc's -fstack-protector which has been enabled in Debian-based distros for many years, and is now being improved over MSVC /GS with -fstack-protector-strong. NX bit support: Support added around 2004 or XP. Again, PaX is far stronger than Windows here. "Guard pages": This is SSP with a different name. So at best, we can say that Windows added some security features slightly earlier, but has lagged in updating them to new standards.
    - robryk 12y ago
      I've thought that guard pages referred to the practice of having a page or a couple allocated before and after an accessible region and set to PROT_NONE (any access causes a trap) to prevent any new allocation from making those pages accessible. This way reads/writes at most a page past the beginning/end of our allocation will always fault. I don't see how is this "SSP with a different name" (the goals are similar but the method is very different). Did you mean some other kind of guard pages or am I missing something?
    - Ded7xSEoPKYNsDd 12y ago
      Full ASLR on Linux requires compiling with non-standard options (-pie -fPIE). Linux distributions seem to do this only on a case by case basis. They should've enabled these flags for most at-risk software by now, but I'm not convinced they got to all of them.

by aortega 12y ago

masklinn 12y ago

On the other hand, as far as I know most systems don't bundle security features in their standard allocators. I'm not sure any non-bsd system does.

throwaway2048 12y ago
Both OSX and especially Windows have extensive memory security features baked into their system allocators (ASLR, SSP, NX bit support, Guard pages, background page zeroing, etc) and even glibc has some basic security features. Its kind of funny that windows is way ahead of your average linux distro on this front, considering the typical attitude with regards to how secure one is compared to the other. Also its not really the BSDs that have these types of security features, its pretty much exclusively OpenBSD. FreeBSD has code support for several of these features but it is not enabled by default, and tends to break things badly when it is enabled, although work is (finally) being done to fix this situation.
- Hello71 12y ago
  ASLR: enabled by default on virtually all Linux systems, can be improved with the installation of PaX. disabled by default on Windows systems. KASLR: Windows has it, Linux does too, but only since 3.14. SSP: libc specific, but MSVS since 2003 has basic stack-smashing support similar to gcc's -fstack-protector which has been enabled in Debian-based distros for many years, and is now being improved over MSVC /GS with -fstack-protector-strong. NX bit support: Support added around 2004 or XP. Again, PaX is far stronger than Windows here. "Guard pages": This is SSP with a different name. So at best, we can say that Windows added some security features slightly earlier, but has lagged in updating them to new standards.
  - robryk 12y ago
    I've thought that guard pages referred to the practice of having a page or a couple allocated before and after an accessible region and set to PROT_NONE (any access causes a trap) to prevent any new allocation from making those pages accessible. This way reads/writes at most a page past the beginning/end of our allocation will always fault. I don't see how is this "SSP with a different name" (the goals are similar but the method is very different). Did you mean some other kind of guard pages or am I missing something?
  - Ded7xSEoPKYNsDd 12y ago
    Full ASLR on Linux requires compiling with non-standard options (-pie -fPIE). Linux distributions seem to do this only on a case by case basis. They should've enabled these flags for most at-risk software by now, but I'm not convinced they got to all of them.