FUSE mount-option injection in `casync mount`

[Brubbish]

Summary

casync mount appears vulnerable to FUSE mount-option injection because attacker-controlled input is propagated into the FUSE -o option string without escaping.

The issue is that the user-controlled archive/index path or URL is forwarded into ca_fuse_run() and then concatenated directly into the mount option list as the value of fsname=. Since FUSE parses -o as a comma-separated option list, an input containing a comma can terminate the intended fsname= value and append additional mount options.

This makes the issue reachable through a normal execution path whenever attacker-controlled input can influence the casync mount source argument.

Project / Version

• Project: casync
• Version / commit: b4b7e5606f785572b78a43626a27a45fe3df2fbd

Vulnerability Type

• Mount option injection
• Improper neutralization of special elements in a comma-separated option context

Affected Components

• src/casync-tool.c
• src/cafuse.c

Relevant path:

return ca_fuse_run(s, input, mount_path, arg_mkdir);

and:

opts = strjoina(opts, ",fsname=", what); /* FIXME: needs escaping */

Trigger Conditions

The issue is reachable when:

• casync mount is used
• the archive path, index path, or URL-like source string is attacker-controlled or attacker-influenced
• that input reaches the FUSE mounting path unchanged
• the supplied value contains option-separating characters meaningful to FUSE parsing, especially ,

No unusual runtime condition is required beyond the normal mount workflow.

Root Cause

The root cause is that attacker-controlled data crosses into a comma-separated FUSE mount-option context without escaping.

The propagation path is:

user-controlled input
  -> input
  -> ca_fuse_run(..., input, ...)
  -> ”what“ variable
  -> ",fsname=" + what
  -> FUSE -o option list

At that point, the input is no longer treated purely as archive/index identity data. Instead, it becomes part of raw option-list text interpreted by libfuse.

Because commas delimit FUSE options, an attacker-controlled comma can break out of the fsname= value and cause subsequent content to be interpreted as additional mount options.

Reachability

This is not a purely theoretical sink. The propagation path from CLI-controlled input to FUSE option construction is short, direct, and occurs in the normal casync mount flow.

Even if the input is semantically expected to represent a path or locator, the final sink treats it as raw mount-option text. That mismatch is what makes the issue security-relevant.

Due to limitations of the validation environment, I did not include a live PoC demonstrating the final mount behavior. However, the vulnerable propagation path, option construction logic, and downstream FUSE parsing semantics are sufficient to establish the issue.

Impact

In affected integration scenarios, this issue may allow attacker-controlled input to modify the effective FUSE mount options used by casync mount.

Depending on system policy and execution context, the consequences may include:

• changing mount behavior unexpectedly
• weakening intended access restrictions on the mounted filesystem
• exposing mount contents to principals beyond the original security expectation

Expected Behavior

User-controlled archive/index identifiers should be treated as data only and should not be able to alter the structure of the FUSE mount-option list.

Actual Behavior

Attacker-controlled input is concatenated directly into the fsname= portion of the FUSE -o string without escaping, allowing option-list structure to be influenced by crafted input.

Suggested Fix

Recommended remediation options include:

1. Do not concatenate attacker-controlled values directly into a comma-separated FUSE option string.
2. Use an escaping helper such as fuse_opt_add_opt_escaped() when constructing FUSE options.
3. Reject or escape at least option-separating characters such as , and escaping-sensitive characters such as \\.
4. Add regression tests ensuring that archive/index values cannot inject additional mount options.

[ssieb]

It would of course be a good idea to escape the input, but I don't see a security issue here. In order to do this, the attacker must already have the access of the user or root, so what's the benefit of injecting parameters in a fuse mount when they could directly run the mount themselves anyway with whatever options they want?

[Brubbish]

@ssieb I agree that a local CLI scenario is less critical. My concern is when casync is used by an online service or within a higher-level workflow. In that setting, an attacker may be able to control the source string without having equivalent control over the final FUSE mount options.