When a Memory Allocator Hides Security Bugs
blog.fuzzing-project.org
blog.fuzzing-project.org
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.
>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.
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.
If we, as programmers, want to be respected, we need to make every reasonable effort to improve security.
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.
.. another remote exploit for OpenBSD ?
That is just oh so gimmicky. It reflects quite poorly on the project.
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.
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
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.
OS security is rapidly decreased by increased running services. Minimizing your services reduces your risk footprint.
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.
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).