ifscan

Know what is inside a QNX image before it ships: contents, hardening audit, third-party components, known CVEs and a CycloneDX SBOM, from any host.

Comment

Inspiration

A QNX system ships as an image filesystem: one binary file that holds the kernel, drivers, libraries and startup script. Once mkifs has built it, the image is opaque. Regulations such as the EU Cyber Resilience Act and UNECE R155 now expect a manufacturer to say exactly which third-party components are in a product and which known vulnerabilities affect them, and a QNX image has no package database to ask.

What it does

ifscan is a host-based tool. It reads an image filesystem directly on Linux, macOS or Windows, with no target and no QNX tools installed, and answers three questions:

  1. What is in it? Every file with mode, owner and SHA-256.
  2. What third-party code is in it? Libraries are identified by the version banner they compile into themselves (OpenSSL, zlib, curl, BusyBox, OpenSSH and others). ifscan vulns then asks the NVD which known CVEs apply to those exact versions.
  3. Is it built safely? Each ELF binary is checked for PIE, RELRO, executable stack and stack protector. Setuid and world-writable files are flagged, and libraries a binary needs but the image lacks are listed.

Results are printed for people, or written as a CycloneDX 1.5 SBOM for existing compliance tools. audit and vulns return exit code 2 on high-severity results, so one line in CI blocks a bad image.

How it was built

In Rust, as a library plus a command-line tool. The image reader follows the public sys/image.h and sys/startup.h structures and handles little- and big-endian images and zlib- and LZO-compressed ones. ELF inspection uses the object crate. An AI coding assistant was used during development.

Challenges

  • The first run on a real image flagged all 136 binaries for an executable stack. Binaries from the QNX toolchain carry no PT_GNU_STACK header, so the usual Linux rule is wrong there; ifscan now reports it only when a binary explicitly asks for an executable stack.
  • With no package database, component detection has to rely on evidence inside the binaries, and it must not mistake prose like "OpenSSL error" for a version.

Accomplishments

On the public Raspberry Pi image from the varghes/Raspberry-QNX board support package, ifscan lists all 238 entries and 136 ELF binaries, identifies OpenSSL 1.0.0e, libpng 1.4.0 and two zlib versions, and returns 39 known vulnerabilities with a CVSS score of 7 or higher for them.

What I learned

How a QNX image is laid out on disk, and how different its binaries are from Linux ones in the details that hardening checkers assume.

What's next

  • Record results on images built with QNX SDP 8.0, including LZ4-compressed ones.
  • Read the startup script to report which services start and with what privileges.
  • Compare two images and report what changed between releases.
  • A GitHub Action that fails a build on new high-severity findings.

Built With

Share this project:

Updates

Submission history