CVE-2022-45639: Disputed Local Command Injection in Sleuth Kit fls -m

A disputed local command-injection flaw tracked as CVE-2022-45639 has been associated with The Sleuth Kit’s fls utility (version 4.11.1): multiple vulnerability databases record a proof‑of‑concept showing that a specially crafted value passed to the fls tool’s -m option can cause shell metacharacters (for example, backticks) to be interpreted as commands, but maintainers and some third‑party analysts have questioned whether the reported behavior actually allows command execution beyond the invoking user’s privileges. (nvd.nist.gov) (security.snyk.io)

Background / Overview​

The Sleuth Kit (TSK) is a long‑standing, widely used collection of command‑line forensic utilities. The fls tool lists file and directory entries from disk images and includes a -m flag that preprends a user-supplied mount point string to paths so output can be consumed by timeline tools such as mactime. The documented usage and purpose of -m is to let examiners produce bodyfiles that carry the original mount-point context.
On 24 January 2023 a CVE entry (CVE-2022-45639) began circulating which claimed an OS command injection vulnerability in fls 4.11.1 where a maliciously crafted -m value containing backticks (or other shell metacharacters) could be abused to execute arbitrary commands. The record has been enriched and mirrored across standard vulnerability databases (NVD, OSV, Snyk, Vulners and others), and the vulnerability has been given a high CVSS3 base score in aggregated feeds (7.8) with an Attack Vector: Local assessment. (nvd.nist.gov)
That representation—high severity, local vector, working PoC—was widely echoed by security aggregators, and a short PoC (for example: fls -m id) has been published and repeated by vulnerability trackers. (security.snyk.io)
However, an important qualification appears in multiple authoritative records: the entry is marked DISPUTED by third parties because there is no published analysis showing that the backtick expression executes outside the context of the user account that invoked fls. In plain terms: the known demonstration proves shell metacharacter interpretation can occur, but it does not prove privilege escalation or remote command execution beyond the local user’s authority. NVD and several mirrors emphasize that the exploitation path is local and that the actual impact depends on the context in which fls runs. (nvd.nist.gov)

---

How fls’s -m option is intended to work​

What the -m option does​

• The -m option takes a string that is prepended to output paths; it exists so investigators can label the image’s root path (for example, "/" or "C:/") in fls output used to create mactime timelines.
• fls is a command‑line program; typical use-cases are interactive forensic work, scripting in examiner’s workflows, and automated pipelines run by forensic appliances or CI scripts.

Why a string parameter can become dangerous​

• Any utility that accepts freeform text from an untrusted source and eventually passes that text to a shell (for example via system(), popen(), backticks in interpreted glue code, or by executing /bin/sh -c) is at risk for shell metacharacter injection.
• If a program builds a string that contains user input and hands that string to the shell, then characters like backticks (...), dollar‑paren $(...), semicolons, pipes, and others can be used to cause execution of arbitrary commands as the same user running the program.
• Whether that is exploitable in practice depends on whether the program executes a shell command containing the unfiltered input, and crucially, on the privileges and environment of the process running fls. (security.snyk.io)

---

The proof‑of‑concept reported and the grounds for dispute​

The published PoC​

• Public trackers and vulnerability pages reproduce a short PoC showing the behaviour:
• Example: fls -m id
• Multiple databases flagged a working PoC and classified the issue as command injection (CWE‑78). (security.snyk.io)

What the PoC does — and what it does not show​

• The PoC demonstrates that if a user supplies a meta‑character string to -m and fls passes that string to a shell without sufficient sanitization, the shell may interpret the metacharacters and run the embedded commands in the invoking user's context.
• The critical limitation: the published PoC and many mirrored entries do not demonstrate that fls runs as a privileged service or as another user (e.g., root, SYSTEM, or an elevated forensic appliance account). They do not show remote exploitation of a running service or privilege escalation from an unprivileged to a privileged account.
• Because of that distinction, several maintainers and independent analysts labeled the CVE as disputed—not suggesting the PoC is impossible, but correctly arguing the technical impact is context‑dependent and that the claim of “arbitrary command execution” must be scoped to the user context that runs fls. (nvd.nist.gov)

---

Realistic attack scenarios and threat modelling​

When the vulnerability is dangerous​

• Local interactive abuse: a local non‑privileged user can escalate impact if fls is run by a higher‑privilege user (e.g., as a forensic appliance account) and accepts untrusted -m input from that user’s environment or from automated workflows.
• Scripting and automation: if fls is embedded in scripts that accept external input (for example, a web UI that delegates to fls using user-supplied mounting points), an attacker who can control that input may trigger shell evaluation.
• Multi‑user systems: on multi‑user forensic hosts where several analysts or automated jobs run with elevated privileges, an attacker who can influence job parameters may use metacharacter injection to run commands as the job owner.

When it is less dangerous​

• If fls is only executed by a single trusted user in controlled analysis sessions and there is no mechanism for untrusted input to reach the -m parameter, exploitation requires local access and cannot be performed remotely.
• The vulnerability is not a remote code execution of network services by itself; the consensus from multiple inventories is that the attack vector is local. Databases therefore classify Attack Vector = Local and Privileges Required = Low (i.e., attacker needs ability to run fls as a user), but not Remote. (nvd.nist.gov)

---

Technical analysis — possibilities for where fls might invoke shell processing​

Typical implementation pitfalls that lead to this class of bug​

• Calling system() / popen() with strings that concatenate unvalidated input.
• Using backtick expansions in wrapper scripts or in code that hands data to /bin/sh -c.
• Building command lines for downstream tools (for example, composing a pipeline that includes an invocation of mactime or other utilities) where parts are filled by user input.

TSK’s codebase and tools are varied: while the fls tool itself may not call a shell for normal -m output, surrounding scripts or packaging wrappers that call fls could. Published reports and PoCs point to the fact that somewhere in typical usage chains the -m value can be interpreted in a way that triggers shell evaluation. This is consistent with the short PoC posted to vulnerability trackers. (security.snyk.io)

Why the vendor/maintainers might dispute high severity claims​

• If fls itself does not invoke a system shell with the -m parameter, but the PoC leverages a shell wrapper or a packaging artifact, the correct remediation may be to sanitize wrapper scripts or packaging rather than declare the fls binary itself intrinsically exploitable.
• If the attack requires the attacker to already have the ability to run fls as the victim user, the net increase in attacker capability is smaller (the attacker already controls an account that can launch arbitrary locally executed commands), and the issue is primarily one of unsafe scripting rather than a privilege escalation in the binary.

NVD explicitly records that the assertion is disputed for precisely this reason: the backtick demonstration has not been shown to execute outside the context of the account that invoked the command. That nuance matters for incident triage. (nvd.nist.gov)

---

Impact assessment and CVSS context​

• Most aggregators assigned a high base score (CVSS 3.1 = 7.8) driven by high impact on confidentiality/integrity/availability and low attack complexity. Those scores reflect a conservative posture: if commands run as the user running fls, they can leak, modify or delete files available to that user, and repeated exploitation could disrupt forensic workflows. (nvd.nist.gov)
• The technical reality is more nuanced:
• Confidentiality/Integrity/Availability impact is limited to the security context of the fls process. If fls runs as root or SYSTEM (for example, within an automated appliance service), the consequences are severe; if it runs as an unprivileged analyst account, the damage is limited to that account’s resources.
• The attack is local: an attacker needs the ability to invoke fls and supply the -m argument; it is not a remote network service exploit by itself. (nvd.nist.gov)

---

Detection, forensic indicators, and incident response​

What to look for in logs and processes​

• Because the reported proof of concept uses shell metacharacters, look for unexpected subcommands appearing in process trees and shell logs. Systems that log user shells (for example, bash.log or sh.log) and command‑recording facilities can show suspicious invocations such as invocation of fls with unusual -m values or downstream commands executed in the same session.
• The uploaded files in this analysis illustrate the kind of evidence first responders should hunt for: bash logs containing "nobody on /dev/pts/X shell_command=\"hostname\"" and sh logs with recorded shell commands are cited examples of how attackers leave traces when they execute commands via an injected shell. These artifacts are exactly the sort of data to review when investigating suspicious fls usage on multi‑user or appliance hosts.

Practical detection checklist​

• Search for runs of fls that include backticks, $(), semicolons, or other shell metacharacters in the -m parameter.
• Review shell history and system logs of the user account that runs fls. Correlate timestamps with process trees and syscall traces.
• On forensic appliances or automated runners, check wrapper scripts, cron jobs, and web UIs that accept or inject mount points or path prefixes into fls commands—those are high‑value places for an adversary to inject an argument.

---

Mitigation and hardening recommendations​

Immediate operational steps (triage)​

• If you run fls as part of an automated service, audit the invocations—identify any wrappers, web UIs, or automation scripts that pass user input to fls. Treat any untrusted input as dangerous.
• Add input validation and escaping for the -m parameter—ensure that the mount point string cannot contain shell metacharacters before it is interpolated into any shell command.
• Where practical, run fls under a least‑privilege account and avoid running forensic toolchains as root or SYSTEM unless strictly necessary for analysis. Restrict who can invoke the analysis environment. (security.snyk.io)

Medium‑term technical fixes​

• If your deployment uses wrapper scripts that call a shell with interpolated arguments, rewrite them to use execv/execve or direct binary invocation with argument arrays rather than invoking /bin/sh -c with concatenated strings. This eliminates shell interpretation entirely.
• Sanitize the -m value in calling code: remove or escape backticks, $(), semicolons, and other metacharacters, or verify the value against a strict mountpoint grammar (for example, accept only /, /[a‑z0‑9/._-]+, or drive letters followed by :/).
• Consider containerizing or sandboxing automated fls executions so any exploitation is constrained by containment policies (e.g., AppArmor, SELinux, chroot, unprivileged containers). These controls help contain potential damage even if shell evaluation occurs.

Long‑term: development best practices​

• Tool maintainers should avoid shelling out when building program output. When a tool must produce formatted text for other utilities, it should construct output directly, not via shell commands that concatenate user input into a command string.
• Security triage for open‑source toolchains calls for explicit threat models: document which inputs can be considered untrusted in automation contexts and include unit tests that attempt common injection payloads. This prevents regressions when tools are consumed by third parties in unexpected ways.

---

What maintainers and downstream packagers should do​

• Sleuth Kit maintainers and package maintainers should review fls, wrapper scripts, packaging, and examples to ensure no unintended shell evaluation occurs when processing -m. If any packaging examples include code that builds commands with unescaped mountpoint strings, those examples need remediation.
• Downstream distributions and forensic appliance vendors should audit their integration points. Many users run fls inside automated pipelines or web UIs; these are precisely the places where an originally “local-only” risk becomes an escalation vector if user input can be supplied indirectly. Public tooling and published examples should be updated to demonstrate safe invocation patterns. (nvd.nist.gov)

---

Risk summary and guidance for practitioners​

• CVE-2022-45639 is properly flagged as a command‑injection class issue in multiple canonical databases, and a short PoC demonstrates how shell metacharacters in -m can cause commands to run. Databases and triage services therefore treat it seriously and assign a high impact if fls is used in contexts where it can be coerced into executing shell commands. (nvd.nist.gov)
• However, the key operational fact—who runs fls and under what privileges—is the decisive factor. If fls is only run interactively by a trusted analyst, the vulnerability is an abuse of local capability rather than a remote compromise vector. If fls runs under an elevated service account that can be influenced by untrusted actors, the vulnerability becomes a high‑risk operational hole.
• Remediate by eliminating shell evaluation in calling code, sanitizing inputs, running tools under least privilege, and auditing deployment wrappers. Monitor shells and process logs for signs of unusual invocations, and prioritize remediation for environments that accept external or untrusted input into fls invocations.

---

Conclusion​

CVE-2022-45639 is an instructive example of how a simple convenience parameter designed to help forensic workflows (the -m mountpoint string) can create risk when code or wrapper scripts hand untrusted strings to a shell. Multiple vulnerability trackers reproduce a minimal PoC (using backtick evaluation) and classify the issue as a command‑injection problem, while authoritative records also correctly flag the limitation that there is no proof the behavior leads to privilege escalation beyond the invoking account. Practitioners should therefore treat the issue seriously in any environment where fls is called by automated systems, appliances, or services that accept external input—but they should also evaluate impact in the concrete context of who runs fls and with what privileges. Immediate steps—sanitize inputs, avoid shell concatenation, and run under least privilege—are practical, effective mitigations that reduce the attack surface without waiting for vendor action. (nvd.nist.gov)

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center