It seems this is the last version to have Nginx in the base install. 5.7 Will only ship their in-house httpd(8) as the default web server, although Nginx will still be available in ports. Reyk explained the reasoning : http://undeadly.org/cgi?action=article&sid=20140827065755&pi...
> [nginx] uses custom memory allocators (for performance reasons) and it is wrapping or replacing standard C library functions all over the place. This could eliminate some of our built-in security mechanisms.
Isn't this what made most of OpenSSL bugs possible and made them go unnoticed for a long time?
And yet techniques like custom memory allocators can have compelling performance benefits.
To me the right tradeoff is: if you want to do fancy allocation, at least make the allocator injectable so that people can use standard malloc (or even a specialized security-hardened malloc) if they prefer. Robust low-level libraries like Lua, zlib, etc. usually take this approach: you can pass a pointer to a custom "malloc" function.
Unfortunately this isn't always possible: LuaJIT doesn't support the "custom allocator" part of the Lua API for a couple of reasons:
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.
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.
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.
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?
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.
I believe so. OpenSSL had a whole swath of other issues that contributed to its problems, but chief among them was a habit of implementing core functionality already provided by the OS. Also, as mentioned, the constantly lengthening codebase made checking for such issues difficult.
OpenBSD folks have worked hard to make their functions safe and it would be a shame if a duplicate function led to a vulnerability that didn't exist in the core.
Replacing the standard C memory allocator is a stupid idea.
Incorrect. There are a lot of reasons (for tracing, for debugging, for providing fast allocations, etc.) for replacing the standard malloc() implementation in a given program.
Simply put, recall that that allocator has to be good-enough for the general case, and as such cannot be the best for any particular case. It's tricky to get right, but it's hardly a "stupid idea".
Reyk also said that people could write papers on Nginx's http implementation because it's crazy how well optimized it is. There's a BSDNow.tv interview he brings this up and talks more about the change away from Nginx.
And the httpd(8) manual shows there are some similarities in the configuration to Nginx. http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/... It seems to be a much more simplified and streamlined setup.