list of security features in musl

list of security features in musl

[Natanael Copa]

Hi,

Once in a while I get question about what security features there are
in musl. Are there such list some where?

-nc

Re: list of security features in musl

[Rich Felker]

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

Re: list of security features in musl

[Szabolcs Nagy]

* 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

Re: list of security features in musl

[Solar Designer]

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

Re: list of security features in musl

[Szabolcs Nagy]

* 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

Re: list of security features in musl

[Rich Felker]

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

Re: list of security features in musl

[Szabolcs Nagy]

* 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