[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160211191119.GO9915@port70.net>
Date: Thu, 11 Feb 2016 20:11:19 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: list of security features in musl
* Rich Felker <dalias@...c.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
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.
