Now that I'm running most of my services on Alpine Linux, I was curious about the state security-wise of its libc, musl, which used to be dire to say the least last time I looked at it.
Zeroing memory
Albeit bzero is deprecated (marked as LEGACY in POSIX.1-2001, removed in POSIX.1-2008),
musl provides bzero,
as well as the nonstandard explicit_bzero (also known as memset_explicit() or memset_s() in other libc)
to ensure that secret don't stay laying around in memory.
Support of _FORTIFY_SOURCE
_FORTIFY_SOURCE is supported via a libc-agnostic set of headers.
Invalid state handling
musl uses assert, which is a wrapper around __assert_fail to validate
assumptions and catch invalid states/violations, resulting in an immediate halt
of the program, instead of doing some dangerous magic to parse the callstack
and the environment.
CSPRNG
Currently, musl doesn't provide a CSPRNG, but it's on the todo-list.
Support for %n
Nowadays, the only reasonable usage of the %n specifier in printf and its
friends is to mount format-string attacks.
But since musl aims at being as compliant as possible, this specifier is unfortunately implemented and
available.
It could be interesting to put it being a define, a bit like Visual Studio is
doing.
RELRO
RELRO is supported since musl 1.1.0, released in April 2014.
atexit hardening
It's old
news that atexit is a
cool vector to transform and arbitrary r/w into arbitrary code exec. glibc is
using
mangling,
like
microsoft,
OpenBSD marks them as
RO. Unfortunately,
musl doesn't do any defensive in this area.
Stack cookies
Building musl with stack-based overflow hardening (think "cookies") is possible since musl 1.1.9, released in May 2015.
Setjmp/longjmp hardening
setjmp/longjmp can be used to transform a limited write + jmp into an
arbitrary write to registers and more. The glibc does some mangling, like the OpenBSD libc,
while Microsoft does sanity check (validating that the stack pointer is pointing to the stack, that the instruction pointers points within the current module, all well as validated setjmp callsites, …). musl doesn't do any hardening there.
Compatibility with *SAN
Currently, musl isn't compatible with ASAN/MSAN/TSAN/UBSAN/… which isn't really super-duper important since I'm not fuzzing with musl anyway.
Development practises
musl's development is pretty old school: a mailing list for bug tracker, a cgit repository, no continuous builds nor integrations with static analysers like coverity or LGTM, no fuzzing, … meh.
Memory allocator
This is the juicy part of the blogpost: userland heap management. musl
used to have a terrible (security-wise) allocator, replaced with malloc-ng
as part of musl 1.2 released in August
2020.
- jemalloc, ptmalloc, nedmalloc, … are all using per thread memory pools, while musl uses a global lock, likely to guarantee global consistency and avoid race-conditions that could result in undetected memory corruption exploitations. On the downside, this might result in contention on multi-threaded programs.
- Freed and allocated memory isn't zeroed, so data leak from previously
allocated memory is possible. Zeroing on free and checking if the zone is
still zeroed upon allocation would detect
write-after-freeat this time, but this would likely be too expensive. Zeroing the first 8-bytes would be a good compromise, and doing so on allocation is not that expensive, since it's priming up caches. Android is doing it. - There are no guard pages everywhere à la Electric Fence, but only a fixed-size one below the out-of-band metadata. But since the allocator is often returning freed memory to the system, this tends to leave unmmaped chunks scattered around.
- There is a single global secret, generated once via ASLR, or using
AT_RANDOMif available, used to check that chunks aren't forged. Unfortunately, it's not recomputed for every chunk but simply stored in them, meaning that if leaked once, it's game over. - There are pointers to the OOB metadata inside of the chunk, allowing an attacker with limited reads to rapidly gain access to the secret.
- It's not possible to free unaligned chunks, and if the attacker doesn't have read capabilities, it's also impossible to free non-allocated chunks, making it possible to detect double-free and invalid-free deterministically.
- When freed, chunks are put in a FIFO, making it a bit harder to trigger an
use-after-free, but since no randomization is applied there, it's not that
hard. Also, it could be interesting to quarantine the memory by marking it as
PROT_NONEto catch low-hanging stuff. - Zero-size allocations aren't treated as a special case. They used to be
pretty wild due to their underspecified interaction with
realloc, but are still scary nowadays. malloc-ng's design prevents using pointing at a non-rw area instead, and decision was made that the added complexity of wiring something to handle this special case wasn't worth it. - Single-byte overflows are detected via a NULL-canary at the end of the allocation at re-allocation/free time, to prevent string-related problems, but it could be interesting to make it a bit larger, and add some randomization to it.
Conclusion
Generally better than glibc/µClibc/dietlibc/µClibc-ng/… allocator-wise, which is the biggest attack-surface, but worse than OpenBSD's one. More than decent in my threat model.