[SECURITY] CFDP remote metadata dest_filename controls arbitrary receive file path

[freedomfoxvare]

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets.

Describe the bug

The CF receive path accepts remote CFDP metadata and stores the remote dest_filename verbatim in the RX transaction state. When the inbound transfer completes successfully, the receiver moves the temporary file into that same remote-controlled path.

In the reproduced native_std sample deployment, this is not only a static code issue. I reproduced an end-to-end chain where:

1. a remote sender delivered valid inbound CFDP PDUs through the sample deployment's normal UDP -> CI_LAB -> CFDP RX path,
2. a control transaction used metadata destination /cf/v31_control.txt,
3. an exploit transaction changed only metadata destination to /cf/tmp/v31_remote_path.txt, and
4. the receiver retained the two files at exactly those two different on-target paths.

This proves that remote metadata directly controls the final retained receive path.

To Reproduce

1. Run the standard native_std sample deployment and start core-cpu1.
2. Send a valid inbound CFDP transaction whose Metadata PDU specifies destination filename /cf/v31_control.txt.
3. Follow with valid File Data and EOF PDUs.
4. Observe CF events showing metadata accepted and file retained at /cf/v31_control.txt.
5. Send a second valid inbound CFDP transaction through the same ingress path.
6. Change only the Metadata PDU destination filename to /cf/tmp/v31_remote_path.txt.
7. Follow with valid File Data and EOF PDUs.
8. Observe CF events showing metadata accepted and file retained at /cf/tmp/v31_remote_path.txt.

Observed runtime evidence from reproduction:

CF R2(4:12592): md received, source: v31-control.bin, dest: /cf/v31_control.txt
CF R2(4:12592): successfully retained file as /cf/v31_control.txt
CF R2(4:12593): md received, source: v31-exploit.bin, dest: /cf/tmp/v31_remote_path.txt
CF R2(4:12593): successfully retained file as /cf/tmp/v31_remote_path.txt

Observed filesystem evidence from reproduction:

/workspace/src/build-native_std/exe/cpu1/cf/v31_control.txt
/workspace/src/build-native_std/exe/cpu1/cf/tmp/v31_remote_path.txt

Observed file contents:

visa31 control path
visa31 exploit path

Expected behavior

The CF receive path should not accept arbitrary remote output paths. RX destinations should be constrained to a configured allow-listed base directory, and absolute paths, traversal expressions, or path values outside that base should be rejected before they are stored or used.

Code snips

Remote metadata acceptance:

• cf_cfdp.c

lv_ret = CF_CFDP_CopyStringFromLV(txn->history->fnames.dst_filename,
                                  sizeof(txn->history->fnames.dst_filename),
                                  &md->dest_filename);

Final retained-path sink:

• cf_cfdp_r.c

MoveDest = txn->history->fnames.dst_filename;
...
OsStatus = OS_mv(SubjectFile, MoveDest);

System observed on:

• Hardware: containerized native sample deployment
• OS: Linux (containerized native target)
• Versions: cFS sample deployment built from this repository using build-native_std; cFE/OSAL/PSP sample stack as shipped in-tree

Additional context

Important scope note: this reproduction did not depend on manually placing files into the target runtime filesystem. Both files were created by the target itself after receiving normal inbound CFDP traffic through the sample deployment's existing remote ingress path.

Important contrast note: the control and exploit transactions used the same ingress path, same receiver, and same overall transaction shape. The only relevant changed input was the remote Metadata PDU dest_filename value. That isolates the defect to remote metadata path trust.

Suggested fix:

• validate RX dest_filename against a configured base directory before storing it;
• reject absolute paths or any path outside the mission-approved receive root;
• reject .. segments and normalize/canonicalize before use;
• retain only the validated canonical destination path in transaction state.

Proposed severity view:

• This is a real trust-boundary weakness in the file-receive path.
• In the reproduced sample deployment, it results in remote control of the final retained on-target path with visible filesystem side effects.
• A CVSS v3.1 base score around 7.5 to 8.1 is defensible depending on deployment assumptions.
• In my view this is CVE-worthy because a lower-trust remote peer can directly determine where inbound content is retained on the target node.

Reporter Info

Prepared draft based on local reproduction and source review.