Date: Thu, 11 Feb 2016 03:41:05 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: list of security features in musl On Thu, Feb 11, 2016 at 08:56:13AM +0100, Natanael Copa wrote: > Hi, > > Once in a while I get question about what security features there are > in musl. Are there such list some where? Some are briefly mentioned in the libc comparison: http://www.etalabs.net/compare_libcs.html but it's not very complete in this area. The things I would really call security _features_ in musl are: - Stack protector, with failure handling that rapidly terminates the process rather than continuing along error-reporting code paths which can themselves provide an attack surface. - Double-free protection (to the extent possible), with the same rapid termination. - Moderate level heap overflow protection - checking for clobbered heap chunk footers on realloc and free, also with rapid termination. - Ability to build libc itself with stack protector enabled, to catch libc-internal stack smashing. - Password hashing with bcrypt. - Ability to use PIE together with static linking (load static-linked program at randomized address). - Blocking all LD_* for suid/sgid binaries, not just partially restricting what they can do. - Translatable text in libc is purely literal strings, no format strings, so buggy or malicious translations are not a format string attack vector. In addition, the following design concepts/practices contribute to security: - Simplicity/reviewability of code ("The main security feature is that you can read the code" - nsz). - Non-use of arbitrary-size VLA/alloca, minimal dynamic allocation. - Attention to subtle race condition and async-signal safety issues, as demonstrated by the extensive list of such bugs found in glibc by musl developers. - Aim to avoid/remove all undefined behavior even when it's not yet dangerous with current compiler technology. - Safe, fully-standards-conforming handling of UTF-8. - Producing consistent results even under transient errors (failure to obtain a file/resource does not cause silent fallback to defaults that may be wrong). - No late/lazy allocation that would require aborting the program if it fails. There are probably more interesting points for security, but I think I covered the most important ones. If I missed any, reply with additions. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.