Q Parent topic: Q

qchecksec

Updated: April 19, 2023

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]
Parent topic: Q