* list of security features in musl @ 2016-02-11 7:56 Natanael Copa 2016-02-11 8:41 ` Rich Felker 0 siblings, 1 reply; 7+ messages in thread From: Natanael Copa @ 2016-02-11 7:56 UTC (permalink / raw) To: musl Hi, Once in a while I get question about what security features there are in musl. Are there such list some where? -nc ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: list of security features in musl 2016-02-11 7:56 list of security features in musl Natanael Copa @ 2016-02-11 8:41 ` Rich Felker 2016-02-11 19:11 ` Szabolcs Nagy 0 siblings, 1 reply; 7+ messages in thread From: Rich Felker @ 2016-02-11 8:41 UTC (permalink / raw) To: 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: list of security features in musl 2016-02-11 8:41 ` Rich Felker @ 2016-02-11 19:11 ` Szabolcs Nagy 2016-02-16 17:45 ` Solar Designer 0 siblings, 1 reply; 7+ messages in thread From: Szabolcs Nagy @ 2016-02-11 19:11 UTC (permalink / raw) To: musl * Rich Felker <dalias@libc.org> [2016-02-11 03:41:05 -0500]: > 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). > + public git repo with detailed commit messages and pgp signed releases. > - 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. > i would also add that the tc3 update of the posix-2008 standard is due in april, it will fix 190 reported issues in the system interfaces and base definitions categories, 30 of which were reported by dalias or me. some of those are safety related issues. (in case you wonder: redhat reported 23, openbsd 16 out of the 190.) > - 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. > - (mostly) iso c code (so all static and dynamic analyzer tools can be easily applied as well as hardening or debugging instrumentation like asan, cfi, etc. doing that with other c runtimes is harder). - more consistent behaviour across archs (minimal asm). - minimal global state manipulation across translation units (cf. glibc dynamic linker code) - safe atomic update (easy to deploy libc security updates). - safer dynamic linking: always relro, no lazy binding (and no madness like https://github.com/bx/elf-bf-tools ) - no dynamically loaded extensions (like glibc nss modules, gconv modules, unwind library, etc) that can crash the runtime, break api behaviour and limit static linking. - internals are not exposed via underspecified apis that can break the semantics of standard apis. (examples from glibc: gnu indirect function, callback apis like fopencookie or printf.h, malloc hooks and interposition for internal allocations.) - tcb shadow (allows nosuid passwd tools) - about 'security feature lists': the fedora project lists 'sha256 based passwd hash' in glibc as a security feature[0], that implementation is - a denial of service attack vector (computation depends on key length more than the admin controlled round count). - arch dependent(!), one can craft a passwd entry such that only 32bit machines can log in. - unbounded alloca(!) use was fixed in 2012, long after fedora added support for it (the reference implementation in the spec still has the problem, among other issues[1]). - uses arbitrary sized realloc for the global crypt state even though 100 bytes would be enough (checks salt len after reallocation). - not standard conform c code: aligned attribute, alloca, section attribute, undefined behaviour: (tmp - (char *) 0). - meant to be used outside the libc, but secrets are cleared with memset which can be optimized away. (i think there are other issues in this sha256-crypt.c, but the point is: implementation details matter so security check lists should be taken with a grain of salt.) [0]: https://fedoraproject.org/wiki/Security_Features#Glibc_Enhancements [1]: http://www.openwall.com/lists/musl/2012/08/19/9 > Rich ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: list of security features in musl 2016-02-11 19:11 ` Szabolcs Nagy @ 2016-02-16 17:45 ` Solar Designer 2016-02-16 19:44 ` Szabolcs Nagy 0 siblings, 1 reply; 7+ messages in thread From: Solar Designer @ 2016-02-16 17:45 UTC (permalink / raw) To: musl On Thu, Feb 11, 2016 at 08:11:19PM +0100, Szabolcs Nagy wrote: > - about 'security feature lists': > the fedora project lists 'sha256 based passwd hash' in glibc > as a security feature[0], that implementation is > - a denial of service attack vector (computation depends on > key length more than the admin controlled round count). > - arch dependent(!), one can craft a passwd entry such that > only 32bit machines can log in. What do you mean here? 32-bit overflow/wraparound with very high rounds= specification? > - unbounded alloca(!) use was fixed in 2012, long after > fedora added support for it (the reference implementation > in the spec still has the problem, among other issues[1]). > - uses arbitrary sized realloc for the global crypt state > even though 100 bytes would be enough (checks salt len > after reallocation). > - not standard conform c code: aligned attribute, alloca, > section attribute, undefined behaviour: (tmp - (char *) 0). > - meant to be used outside the libc, but secrets are cleared > with memset which can be optimized away. > (i think there are other issues in this sha256-crypt.c, but > the point is: implementation details matter so security check > lists should be taken with a grain of salt.) > > [0]: https://fedoraproject.org/wiki/Security_Features#Glibc_Enhancements > [1]: http://www.openwall.com/lists/musl/2012/08/19/9 Another issue is that SHA-crypt leaks 8 bits via timing (total execution time, not just cache-timing), for no good reason at all (not a tradeoff): "18. repeast the following 16+A[0] times, where A[0] represents the first byte in digest A interpreted as an 8-bit unsigned value add the salt to digest DS" For comparison, bcrypt is not cache-timing-safe, but that's a tradeoff. Alexander ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: list of security features in musl 2016-02-16 17:45 ` Solar Designer @ 2016-02-16 19:44 ` Szabolcs Nagy 2016-02-16 20:39 ` Rich Felker 0 siblings, 1 reply; 7+ messages in thread From: Szabolcs Nagy @ 2016-02-16 19:44 UTC (permalink / raw) To: musl * Solar Designer <solar@openwall.com> [2016-02-16 20:45:32 +0300]: > On Thu, Feb 11, 2016 at 08:11:19PM +0100, Szabolcs Nagy wrote: > > - about 'security feature lists': > > the fedora project lists 'sha256 based passwd hash' in glibc > > as a security feature[0], that implementation is > > - a denial of service attack vector (computation depends on > > key length more than the admin controlled round count). > > - arch dependent(!), one can craft a passwd entry such that > > only 32bit machines can log in. > > What do you mean here? 32-bit overflow/wraparound with very high > rounds= specification? > no, rounds setting is specified in terms of strtoul which has saturating semantics so large values are not a problem (and out of range values are clamped into [1000,999999999]). but negative values are accepted by strtoul with different meaning on 32 vs 64bit systems (wraparound). (e.g. rounds=-4294967295 is clamped to 1000 vs 999999999). of course arch dependent output is not a useful property for a pbkdf so musl rejects negative rounds settings. http://git.musl-libc.org/cgit/musl/tree/src/crypt/crypt_sha256.c#n211 Rich, it seems musl has the wrong ROUNDS_MAX setting, do you mind adding two more 9s there: http://git.musl-libc.org/cgit/musl/commit/?id=aeaceb1fa89b865eb0bca739da9c450b5a054866 to follow the official spec: https://www.akkadia.org/drepper/SHA-crypt.txt (or reject large rounds so we don't generate non-portable hashes) > > - unbounded alloca(!) use was fixed in 2012, long after > > fedora added support for it (the reference implementation > > in the spec still has the problem, among other issues[1]). > > - uses arbitrary sized realloc for the global crypt state > > even though 100 bytes would be enough (checks salt len > > after reallocation). > > - not standard conform c code: aligned attribute, alloca, > > section attribute, undefined behaviour: (tmp - (char *) 0). > > - meant to be used outside the libc, but secrets are cleared > > with memset which can be optimized away. > > (i think there are other issues in this sha256-crypt.c, but > > the point is: implementation details matter so security check > > lists should be taken with a grain of salt.) > > > > [0]: https://fedoraproject.org/wiki/Security_Features#Glibc_Enhancements > > [1]: http://www.openwall.com/lists/musl/2012/08/19/9 > > Another issue is that SHA-crypt leaks 8 bits via timing (total execution > time, not just cache-timing), for no good reason at all (not a tradeoff): > > "18. repeast the following 16+A[0] times, where A[0] represents the first > byte in digest A interpreted as an 8-bit unsigned value > > add the salt to digest DS" > and key length is leaked too :) > For comparison, bcrypt is not cache-timing-safe, but that's a tradeoff. > > Alexander ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: list of security features in musl 2016-02-16 19:44 ` Szabolcs Nagy @ 2016-02-16 20:39 ` Rich Felker 2016-02-16 20:44 ` Szabolcs Nagy 0 siblings, 1 reply; 7+ messages in thread From: Rich Felker @ 2016-02-16 20:39 UTC (permalink / raw) To: musl On Tue, Feb 16, 2016 at 08:44:35PM +0100, Szabolcs Nagy wrote: > * Solar Designer <solar@openwall.com> [2016-02-16 20:45:32 +0300]: > > On Thu, Feb 11, 2016 at 08:11:19PM +0100, Szabolcs Nagy wrote: > > > - about 'security feature lists': > > > the fedora project lists 'sha256 based passwd hash' in glibc > > > as a security feature[0], that implementation is > > > - a denial of service attack vector (computation depends on > > > key length more than the admin controlled round count). > > > - arch dependent(!), one can craft a passwd entry such that > > > only 32bit machines can log in. > > > > What do you mean here? 32-bit overflow/wraparound with very high > > rounds= specification? > > > > no, > > rounds setting is specified in terms of strtoul which has > saturating semantics so large values are not a problem > (and out of range values are clamped into [1000,999999999]). > > but negative values are accepted by strtoul with different > meaning on 32 vs 64bit systems (wraparound). > (e.g. rounds=-4294967295 is clamped to 1000 vs 999999999). > > of course arch dependent output is not a useful property > for a pbkdf so musl rejects negative rounds settings. > http://git.musl-libc.org/cgit/musl/tree/src/crypt/crypt_sha256.c#n211 > > Rich, > it seems musl has the wrong ROUNDS_MAX setting, do you > mind adding two more 9s there: > http://git.musl-libc.org/cgit/musl/commit/?id=aeaceb1fa89b865eb0bca739da9c450b5a054866 > to follow the official spec: > https://www.akkadia.org/drepper/SHA-crypt.txt > (or reject large rounds so we don't generate non-portable hashes) The intent was to preclude extreme-DoS-range values of rounds, but clamping is the wrong behavior to achieve that. Instead we should just return 0 (fail the operation) if the value is greater than our ROUNDS_MAX. Does that sound ok? Rich ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: list of security features in musl 2016-02-16 20:39 ` Rich Felker @ 2016-02-16 20:44 ` Szabolcs Nagy 0 siblings, 0 replies; 7+ messages in thread From: Szabolcs Nagy @ 2016-02-16 20:44 UTC (permalink / raw) To: musl * Rich Felker <dalias@libc.org> [2016-02-16 15:39:14 -0500]: > On Tue, Feb 16, 2016 at 08:44:35PM +0100, Szabolcs Nagy wrote: > > * Solar Designer <solar@openwall.com> [2016-02-16 20:45:32 +0300]: > > > On Thu, Feb 11, 2016 at 08:11:19PM +0100, Szabolcs Nagy wrote: > > > > - about 'security feature lists': > > > > the fedora project lists 'sha256 based passwd hash' in glibc > > > > as a security feature[0], that implementation is > > > > - a denial of service attack vector (computation depends on > > > > key length more than the admin controlled round count). > > > > - arch dependent(!), one can craft a passwd entry such that > > > > only 32bit machines can log in. > > > > > > What do you mean here? 32-bit overflow/wraparound with very high > > > rounds= specification? > > > > > > > no, > > > > rounds setting is specified in terms of strtoul which has > > saturating semantics so large values are not a problem > > (and out of range values are clamped into [1000,999999999]). > > > > but negative values are accepted by strtoul with different > > meaning on 32 vs 64bit systems (wraparound). > > (e.g. rounds=-4294967295 is clamped to 1000 vs 999999999). > > > > of course arch dependent output is not a useful property > > for a pbkdf so musl rejects negative rounds settings. > > http://git.musl-libc.org/cgit/musl/tree/src/crypt/crypt_sha256.c#n211 > > > > Rich, > > it seems musl has the wrong ROUNDS_MAX setting, do you > > mind adding two more 9s there: > > http://git.musl-libc.org/cgit/musl/commit/?id=aeaceb1fa89b865eb0bca739da9c450b5a054866 > > to follow the official spec: > > https://www.akkadia.org/drepper/SHA-crypt.txt > > (or reject large rounds so we don't generate non-portable hashes) > > The intent was to preclude extreme-DoS-range values of rounds, but > clamping is the wrong behavior to achieve that. Instead we should just > return 0 (fail the operation) if the value is greater than our > ROUNDS_MAX. Does that sound ok? > ok > Rich ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-02-16 20:44 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-02-11 7:56 list of security features in musl Natanael Copa 2016-02-11 8:41 ` Rich Felker 2016-02-11 19:11 ` Szabolcs Nagy 2016-02-16 17:45 ` Solar Designer 2016-02-16 19:44 ` Szabolcs Nagy 2016-02-16 20:39 ` Rich Felker 2016-02-16 20:44 ` Szabolcs Nagy
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).