Command-Line Analysis of .deb Packages: Unpacking Without Installing

Installing .deb files from untrusted or opaque sources can introduce instability or vulnerabilities—blind installs are a recipe for surprises. Transparent inspection of package contents is a key practice for production security, especially in hardened environments or CI/CD pipelines.

For a package like example-package.deb, inspection boils down to identifying the files and scripts it deploys, reviewing declared dependencies, and confirming expected ownership and permissions.

Anatomy of a .deb Package

A .deb file is a standard ar archive encapsulating three components:

• debian-binary: always contains a single line, e.g., 2.0
• control.tar.{gz|xz|bz2}: metadata, control scripts, and checksums
• data.tar.{gz|xz|bz2}: the package payload as it would appear on your filesystem

Visually:

example-package.deb
├── debian-binary
├── control.tar.gz
└── data.tar.xz

Extraction proceeds in layers—the control section describes the data section.

Real-World: Reviewing a Downloaded Package

Consider a scenario: new example-package_1.2.3_amd64.deb arrives from a vendor. The vendor isn’t on your internal allowlist.

Goal: Inspect for unknown binaries or suspect scripts before any install.

1. Summarize Metadata

The dpkg-deb --info command reveals declared metadata directly:

dpkg-deb --info example-package.deb

Key fields:

• Architecture
• Declared dependencies
• Maintainer
• Description

Sample output:

 new Debian package, version 2.0.
 Package: example-package
 Version: 1.2.3
 Architecture: amd64
 Depends: libc6 (>= 2.14), libssl1.1 (>= 1.1.0)
 ...

Note: Declared dependencies are not always enforced—manual installs (e.g., with dpkg -i) skip dependency resolution, raising the risk of silent breakage.

2. Extract and Inspect Control Scripts

Debian control scripts (postinst, prerm, etc.) often trigger side effects; some invoke user creation, systemd hooks, or even system-wide changes.

dpkg-deb -e example-package.deb ./_ctrl

Yields files like:

_ctrl/control
_ctrl/postinst
_ctrl/prerm
_ctrl/md5sums

Search for dodgy system calls or file writes:

grep -E 'useradd|systemctl|rm -rf' ./_ctrl/*

If control scripts are shell scripts (common), it's worth reading them fully for unadvertised logic. For production systems, copy/paste into a linter or restricted shell for closer review.

3. Map and Audit Data Payload

To see exactly what would be deployed:

dpkg-deb -x example-package.deb ./_data

The ./_data directory will recreate package file hierarchy root (e.g., ./_data/usr/bin/example-binary).

find ./_data -type f

Practical checks:

• Are SUID bits set on binaries?
• Do any files land outside /usr or /etc?
• Occasional packages misplace artifacts in /tmp or /var/tmp—a classic anti-pattern.

Validate file types:

file ./_data/usr/bin/*

4. List Installed Paths & Ownership

Prefer not to extract? dpkg-deb --contents (alias: -c) details archive layout, permissions, and owners:

dpkg-deb --contents example-package.deb

Output:

drwxr-xr-x root/root         0 2024-04-25 10:00 ./usr/
-rwxr-xr-x root/root     12345 2024-04-25 10:00 ./usr/bin/example-binary
-rw-r--r-- root/root      2345 2024-04-25 10:00 ./etc/example.conf

Look for discrepancies: non-root owners, world-write bits, or unexpected directories.

5. Forensic/Low-Level Unpacking: ar and tar

When standard tools fail (damaged header, partial package), break out ar:

ar t example-package.deb
ar x example-package.deb # unpacks all three core files

Decompress control.* and data.* as needed:

tar -xf control.tar.gz -C ./_ctrl_ar
tar -xf data.tar.xz -C ./_data_ar

Corrupted .deb? Sometimes only ar can partially salvage contents for manual patching.

6. Integrity: MD5 Checksums

Extract md5sums from the control archive:

dpkg-deb -e example-package.deb ./_ctrl_md5
cat ./_ctrl_md5/md5sums

Compare with hashes of the files in ./_data.
Note: Not all packages ship md5sums, and hashes can be outdated on unofficial builds.

Gotchas & Non-Obvious Checks

• Binary Inspection: Sometimes “innocent” binaries bundle ad-hoc network utilities. Use strings or objdump -x for reconnaissance.
• No Source? Upstream often publishes source .dsc alongside .deb in compliant repos. If missing, traceability is limited.
• Postinst Side Effects: Watch for scripts calling curl or wget; these can pull remote payloads during install—not ideal in a production environment.

Summary Table

Practical Note

CI/CD integration: In secure pipelines, run all pre-install inspections in a throwaway container (e.g., docker run --rm -it ubuntu). Mistakes or malicious files are contained, and you maintain your build host’s integrity.

Not every tool flags intent. Ultimate security demands human review.

Leave further automation or deeper forensics for another day—routine manual inspection as shown here will catch 90% of real-world issues.

If you spot unique patterns or have recommendations for scrutinizing large-scale package updates, document them and share with your team. Experience trumps checklists.