Check binaries for security hardening properties
Syntax:
qchecksec [--debug] [--dir=directory] [--file=file] [--help] [--no-color]
[--verbose] [--version]
Options:
- --debug
- Display additional debugging information in the scan results.
- --dir=directory
- Scan all files in the specified directory.
- --file=file
- Scan the specified file.
- --help
- Display the help menu.
- --no-color
- Do not use colors when displaying the scan results.
- --verbose
- Display additional information in the scan results.
- --version
- Display the utility's version.
Runs on:
Linux, Mac, Microsoft Windows
Description:
The qchecksec utility checks binaries for the use of compile-time
hardening options such as NX (non-executable stack), RELRO (Relocation Read-Only),
and PIE (Position Independent Executable). It provides results as short phrases that
are color-coded by default.
- RELRO
- Indicates whether RELRO is enabled. Possible values are Full RELRO
(green), Partial RELRO (yellow), and No RELRO (red). For
more information, see RELRO in the System Security Guide.
- STACK CANARY
- Indicates whether the binary was compiled with a
-fstack-protector* option, which enables stack canaries
(stack cookies).
- Canary found (green) — The signature of a canary that
checks enforcement was found in the binary.
- No canary needed (green) — Detected that the canary
compiler option was enabled but no canary is used in the binary. The
binary code may simply not require the use of a canary.
- No canary found (red) — No trace of stack canaries was
found in the binary by looking at symbols or compiler options.
- Canary unknown (yellow) — Couldn't tell if canaries were
enabled. Couldn't inspect compiler options to confirm or deny the
canary compiler option was enabled.
For more information, see Stack protection in the System Security
Guide.
- PIE
- Indicates whether the binary was compiled with -pie, which
compiles it as a position-independent executable.
- PIE enabled (green) — Executable was compiled with PIE
options.
- DSO (green) — Dynamic Shared Library. PIE check is not
applicable.
- No PIE (red) — Executable was not compiled with PIE options
or executable is a static binary (i.e., does not reference any
shared libraries).
- No ELF exec (yellow) — Not an ELF executable. Could be an
ELF binary of another type, such as firmware.
- NX
- Indicates whether the stack is non-executable:
- NX enabled (green) — Stack is marked as
non-executable.
- DSO (green) — Dynamic Shared Library. The stack's
executable state has no effect on QNX Neutrino.
- NX disabled (red) — Stack is marked executable.
- NX unknown (yellow) — Executable state of the stack can't
be determined. It may be an older binary that does not automatically
add the information.
For more information, see Stack protection in the System Security
Guide.
- RPATH, RUNPATH
- Indicates whether the binary contains a hard-coded equivalent of
LD_LIBRARY_PATH, which can be abused and shouldn't be present.
- RPATH disabled (green) — No RPATH paths
found in the ELF section.
- RUNPATH disabled (green) — No RUNPATH paths
found in the ELF section.
- RPATH enabled (red) — RPATH paths found in
the ELF section.
- RUNPATH enabled (red) — RUNPATH paths found
in the ELF section.
- FORTIFY
- Indicates whether -D_FORTIFY_SOURCE=[1|2] was specified when
compiling the source, which enables the use of fortified system functions.
- FORTIFY enabled (green) — Binary was compiled with fortify source enabled.
- FORTIFY disabled (red) — Binary was not compiled with fortify source enabled.
- FORTIFY unknown (yellow) — Couldn't tell if the binary was compiled
with fortify source enabled. Couldn't inspect compiler options to confirm or
deny the fortify source compiler option was enabled.
Fortified system functions are designed to detect out-of-bounds memory
accesses by performing lightweight parameter validation at compile-time,
runtime, or both.For this check to work, you need to compile your
binaries with the -frecord-gcc-switches compiler option, which
records compiler flags that qchecksec uses to detect
whether fortified system functions are used.
Checking for the use
of fortified system functions by checking whether the binaries
contain any of the *_chk() functions is
unreliable. If the code is entirely deterministic (i.e., no buffer
overflow can happen), then the linker optimizes the code and
downgrades to the regular, non-*_chk()
functions.
For more information, see
Fortified System Functions in the System Security Guide.
Examples:
Check libc.so.5. In the actual output, the headers and values
are displayed in a table format:
qchecksec --file=${QNX_TARGET}/x86_64/lib/libc.so.5
RELRO: Full RELRO
STACK CANARY: Canary found
PIE: DSO
NX: DSO
RPATH: RPATH disabled
RUNPATH: RUNPATH disabled
FORTIFY: FORTIFY disabled
FILE: /Volumes/devel/sdp/mainline/target/qnx7/x86_64/lib/libc.so.5 [sym,options]