From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: list of security features in musl
Date: Thu, 11 Feb 2016 20:11:19 +0100 [thread overview]
Message-ID: <20160211191119.GO9915@port70.net> (raw)
In-Reply-To: <20160211084105.GL9349@brightrain.aerifal.cx>
* 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
next prev parent reply other threads:[~2016-02-11 19:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-11 7:56 Natanael Copa
2016-02-11 8:41 ` Rich Felker
2016-02-11 19:11 ` Szabolcs Nagy [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160211191119.GO9915@port70.net \
--to=nsz@port70.net \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).