Skip to content

Navigation Menu

Sign in
Sign up
pyllyukko edited this page Mar 31, 2026 · 51 revisions

Hardening flags

To protect against various threats, it would be good to harden at least some binaries and libraries with various memory protections / binary hardening.

The following technologies should be considered:

This can be achieved by using something like the following in SlackBuilds:

SLKCFLAGS="-O2 -fPIC -fPIE -pie -Wl,-z,relro,-z,now -fstack-protector-all -fstack-clash-protection -fcf-protection=full -D_FORTIFY_SOURCE=2 -D_GLIBCXX_ASSERTIONS"

Position-independent executable (PIE)

Some packages can not be built with PIE, when they try to build shared libraries with it, and you can see the build failing for example like this:

building shared krb5support library (0.1)
set -x; objlist=`set -x && perl -p -e 'BEGIN { $SIG{__WARN__} = sub {die @_} }; $e=$ARGV; $e =~ s/OBJS\...$//; s/^/ /; s/ $//; s/ / $e/g;' OBJS.SH` && gcc -shared -fPIC -Wl,-h,libkrb5support.so.0 -Wl,--no-undefined -o libkrb5support.so.0.1 $objlist -Wl,--enable-new-dtags -Wl,-rpath -Wl,/usr/lib64 -L../../lib -lkeyutils -lresolv -ldl -Wl,--version-script binutils.versions 
++ set -x
++ perl -p -e 'BEGIN { $SIG{__WARN__} = sub {die @_} }; $e=$ARGV; $e =~ s/OBJS\...$//; s/^/ /; s/ $//; s/ / $e/g;' OBJS.SH
+ objlist=' threads.so init-addrinfo.so plugins.so errors.so k5buf.so gmt_mktime.so fake-addrinfo.so utf8.so utf8_conv.so zap.so path.so base64.so json.so hex.so hashtab.so bcmp.so strerror_r.so dir_filenames.so strlcpy.so'
+ gcc -shared -fPIC -Wl,-h,libkrb5support.so.0 -Wl,--no-undefined -o libkrb5support.so.0.1 threads.so init-addrinfo.so plugins.so errors.so k5buf.so gmt_mktime.so fake-addrinfo.so utf8.so utf8_conv.so zap.so path.so base64.so json.so hex.so hashtab.so bcmp.so strerror_r.so dir_filenames.so strlcpy.so -Wl,--enable-new-dtags -Wl,-rpath -Wl,/usr/lib64 -L../../lib -lkeyutils -lresolv -ldl -Wl,--version-script binutils.versions
/usr/bin/ld: utf8_conv.so: warning: relocation against `krb5int_utf8_mintab' in read-only section `.text'
/usr/bin/ld: threads.so: relocation R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:925: libkrb5support.so.0.1] Error 1
make[2]: Leaving directory '/tmp/krb5-1.21.3/src/util/support'
make[1]: *** [Makefile:857: all-recurse] Error 1
make[1]: Leaving directory '/tmp/krb5-1.21.3/src/util'
make: *** [Makefile:1521: all-recurse] Error 1

In these cases you need to remove the -fPIE -pie from SLKCFLAGS.

Which binaries

Here's some thoughts about which binaries should/could be hardened:

  • SSH (hardened by default)
  • Communication clients:
    • irssi (has canary, but no RELRO & PIE)
    • Pidgin
    • BitTorrent clients
    • Mail
      • mutt
      • Postfix
      • Dovecot
  • Libraries
    • OpenSSL
    • GnuTLS
    • gpgme
  • gpg
  • git
  • coreutils
  • Archiving tools:
    • tar
    • bzip2
    • rar
  • Tools that are used against binaries etc.
    • less
    • strings
    • file
    • *sum
    • hexdump
  • PDF readers
  • Traffic analyzers (tcpdump, wireshark)
  • Clamav
  • wget/curl
  • SUID binaries
    • sudo
  • Apache/PHP
  • krb5
  • OpenLDAP
  • PAM

TODO

  • ldd all the bins and find the most common libraries to harden.

Checking binaries

checksec

You can use checksec.sh to check binary hardenings. Do note, that the stack canary check will not work for stripped binaries, as the symbols do not exist and checksec.sh tries to look for __stack_chk_fail (in .dynstr section).

Modern checksec

A fork from checksec that is currently maintained is available here: https://github.com/slimm609/checksec.

radare2

You can use radare2 to check hardenings:

$ rabin2 -I $(which ssh) | grep '^\(canary\|nx\|pic\|relro\|rpath\)\b'
canary true
nx true
pic true
relro full
rpath NONE

GEF

GEF has a checksec command.

References

Secure Code Partitioning With ELF binaries, aka. SCOP:

A Secure ELF binary should have the following mitigations applied:

  • RELRO gcc -Wl,-z,relro,-z,now
  • SCOP gcc -Wl,-z,code-separation
  • PIE (Full ASLR) gcc -fPIC -pie
  • Stack Canaries gcc -fstack-protector
  • PaX mprotect(2) paxctl -M

Do not forget that statically linked executables do not officially support PIE or RELRO, but have had some solutions proposed in the paper "ASLR and RELRO protection for statically linked executables"

rpath

Signing

Signing binaries with either elfsign or bsign? Apparently bsign doesn't work against 64-bit binaries

Look into

Clone this wiki locally

AltStyle によって変換されたページ (->オリジナル) /