nasa / nasa/CF

CF_CFDP_R_ProcessFd does not bound received FD PDU offset against the declared transaction file size

Open
#520 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
120
Forks
77
Avg merge
7d 18h
Merged PRs (30d)
3

Description

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

CF_CFDP_R_ProcessFd() never compares fd->offset against txn->fsize. A CFDP file arrives as data, not as a command, so its offsets are attacker-controlled regardless of who is authorized to send commands.

Four FD PDUs totalling 82 bytes, 12 of them crafted, cause the receiver to write and retain a 4 GiB file for a transfer declared as 4 bytes. The transaction is reported as successful: files_recv increments, file_size_mismatch stays at 0, and the file is recorded as successfully retained.

The impact is storage exhaustion plus loss of file-length integrity, and a success report for a transfer that did not succeed. This is not a memory-safety defect; there is no sanitizer report because there is nothing for a sanitizer to catch.

The same application already enforces this bound on the sending side (cf_cfdp_s.c:302), and the file_size_mismatch counter exists for exactly this condition, but it is never reached on the receive path.

To Reproduce

  1. Start a CFDP receive transaction declaring a 4-byte file size.
  2. Send four FD PDUs, 82 bytes total. The crafted 12 bytes place a later PDU's offset beyond the declared size.
  3. Observe the resulting file on the receiving filesystem: 4 GiB.
  4. Observe the HK counters: files_recv=+1, file_size_mismatch=+0, transaction closed as successfully retained.

A/B isolation: the identical transfer without the crafted PDU produces a 4-byte file.

PoC, crafted PDUs and captured counter output: https://gist.github.com/iiviel/019284efadec361200a7902416f88108

Expected behavior

An FD PDU whose offset + data length exceeds txn->fsize is rejected and file_size_mismatch is incremented, applying the same bound the sender already uses at cf_cfdp_s.c:302.

Code snips

fsw/src/cf_cfdp_r.c, CF_CFDP_R_ProcessFd(): no comparison of fd->offset against txn->fsize on any path.

Sender-side bound for contrast: fsw/src/cf_cfdp_s.c:302.

System observed on:

  • Hardware: x86-64 and 32-bit builds
  • OS: Linux
  • Versions: CF v7.0.1, v7.0.0, v3.0.0, 2.2.1, reproduced on all four, on every CF branch, under CFDP class 1 and class 2, at both word sizes

Additional context

CF#499 finding 1 is in the same function but concerns a different defect with a different proposed remedy. This report is independent of it.

Reporter Info

Eva Crystal (0xiviel), XSource Security

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in fsw/src/cf_cfdp_r.c at CF_CFDP_R_ProcessFd(), then compare the sender-side bound at fsw/src/cf_cfdp_s.c:302. Reproduce the four-PDU transfer described in the issue and inspect the resulting file and HK counters. Done means an out-of-bounds FD PDU is rejected, file_size_mismatch is incremented, and the transfer is not reported as successfully retained.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
networking, security
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
74/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.