[SECURITY] HS EventMon uses forged event payload identity to trigger processor reset

[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

HS EventMon trusts the AppName and EventID fields embedded in incoming CFE_EVS_LONG_EVENT_MSG_MID packets, but it does not verify that the software-bus message actually originated from that named application. When a matching EventMon rule is configured, HS will execute privileged actions such as processor reset, app restart, or app deletion based only on spoofable payload identity.

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

1. attacker-controlled data was delivered through the normal UDP command-ingest path,
2. CF/CFDP retained an attacker-controlled HS.EventMon_Tbl file on the target runtime filesystem,
3. the normal CFE_TBL management path loaded and activated that table, and
4. a forged CFE_EVS_LONG_EVENT_MSG_MID packet caused HS to execute CFE_ES_ResetCFE() and reset the processor.

To Reproduce

1. Run the standard native_std sample deployment and start core-cpu1.
2. Deliver a crafted hs_emt_visa22.tbl over the normal UDP -> CI_LAB -> CF/CFDP path so that CF retains it as /cf/hs_emt_visa22.tbl.
3. Send normal CFE_TBL commands to:
   • abort any stale load state,
   • load /cf/hs_emt_visa22.tbl,
   • validate the inactive buffer, and
   • activate HS.EventMon_Tbl.
4. Send the normal HS EnableEventMon command.
5. Inject a forged CFE_EVS_LONG_EVENT_MSG_MID packet whose payload sets:
   • AppName = CFE_TIME
   • EventID = 0x2222
6. Observe that HS matches the spoofed payload fields and performs a processor reset.

Observed runtime evidence from reproduction:

CF R2(4:8756): successfully retained file as /cf/hs_emt_visa22.tbl
HS 52: EventMon verify results: good = 1, bad = 0, unused = 15
CFE_TBL 36: HS validation successful for inactive 'HS.EventMon_Tbl'
CFE_TBL 37: HS Successfully Updated 'HS.EventMon_Tbl'
HS 27: Event Monitoring Enabled
HS 45: Event Monitor: APP:(CFE_TIME) EID:(8738): Action: Processor Reset
CFE_ES_ResetCFE: POWER ON RESET due to max proc resets (Commanded).
CFE_PSP: Exiting cFE with POWERON Reset status.

Expected behavior

HS should not make EventMon authorization decisions based solely on payload-declared identity. Before executing privileged actions, it should verify a trusted sender identity provided by the framework or reject externally supplied event traffic that lacks authenticated origin metadata.

Code snips

Primary decision point:

• hs_monitors.c
• hs_monitors.c

Event ingress path:

• hs_app.c
• hs_cmds.c

Relevant matching logic:

if ((ActionType != HS_EMTActType_NOACT)
    && (HS_AppData.EMTablePtr[TableIndex].EventID == EventPtr->Payload.PacketID.EventID))
{
    if (strncmp(HS_AppData.EMTablePtr[TableIndex].AppName,
                EventPtr->Payload.PacketID.AppName,
                OS_MAX_API_NAME) == 0)
    {
        switch (ActionType)
        {
            case HS_EMTActType_PROC_RESET:
                CFE_ES_ResetCFE(CFE_PSP_RST_TYPE_PROCESSOR);

Normal remote file-ingress prerequisite used in reproduction:

• ci_lab_app.c
• ci_lab_passthru_decode.c
• cf_cfdp_r.c

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 reproduced exploitability depends on deployment-specific reachability. In my reproduction, the sample deployment exposed a normal UDP ingest path through CI_LAB, and CF/CFDP could retain a remotely supplied table file to writable storage. If a mission removes or protects those paths, the attack surface changes.

This reproduction did not rely on manually placing files inside the target runtime filesystem and did not call internal APIs directly. The malicious EMT file was delivered through the system's normal ingress path, activated through the normal CFE_TBL management path, and the forged event was injected through the same sample deployment's normal message-ingest surface.

Another scope note: in the reproduced setup, the packet sender and core-cpu1 were run within the same container/network namespace and traffic was sent to 127.0.0.1:1234. Therefore, this demonstrates that the shipped sample deployment's normal network-ingest surface can be abused to trigger privileged HS actions, but it should not be overstated as proof that every real mission exposes the same surface directly to an external network.

Suggested fix:

• bind HS EventMon decisions to authenticated sender identity, not payload-declared app name;
• reject or quarantine externally supplied event packets that are not emitted by trusted EVS-originated paths;
• if EVS-origin metadata exists or can be added, require HS to compare against that trusted sender identity before executing privileged actions.

Proposed severity view:

• This is best described as a real authorization/trust-boundary failure with deployment-conditional network reachability.
• In the reproduced sample deployment, it results in a visible processor reset with no need to compromise the named victim app whose identity is spoofed.
• A CVSS v3.1 base score around 8.8 is defensible for the reproduced sample deployment (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H) if the report text keeps the deployment-prerequisite caveat.
• In my view this is CVE-worthy because the vulnerable behavior is not simply “HS can reset on events”; the issue is that HS authorizes those privileged actions using spoofable payload identity instead of trusted sender identity, and that weakness is dynamically exploitable in the shipped sample deployment.

Reporter Info

Prepared draft based on local reproduction and source review.