Segfault (not graceful error) when a command is executed against a connected device at enable=0

[UWillC]

Routing note: SECURITY.md lists "Denial of service against the O-Node (single-process architecture)" as a known out-of-scope limitation, so I'm filing this as a public robustness issue rather than a private security report. It's a crash, not a crypto/trust/auth bypass. If you'd rather track it elsewhere, happy to move it.

Observed. With an ASA connected but at enable=0 (no enable credential configured), both the watchdog health-check and a client execute were attempted without enable:

[ASA] Warning: not in enable mode on ASA, command may fail: show clock
[ASA] Warning: not in enable mode on ASA, command may fail: show version
[Watchdog] Health check failed: ASA — dropping
[ASA] Disconnected: ASA

A client {"action":"execute","device":"ASA","command":"show version"} then segfaulted virp-onode-prod (client got socket closed prematurely; shell reported Segmentation fault).

Repro (minimal): a device whose SSH account is not priv-15, with no enable credential configured → connect → issue any exec command (or let the watchdog health-check run). Seen on ASA 9.1(7)23, but the trigger is the enable=0 + command-issued state, which looks driver-generic in the cisco/asa exec path.

Why it's worth fixing despite the known single-process-DoS limitation: this isn't resource exhaustion — it's a reproducible memory-safety crash on a specific, partly device-influenced input (mode/prompt detection), and the fix looks small and local: the exec path should return an error (e.g. VIRP_ERR_ENABLE_REQUIRED) when a command is requested on a not-enabled session, rather than proceeding into the crash. A negative test / libFuzzer case for "connected, enable=0, command issued" would lock it down.

PR_SET_DUMPABLE=0 means no key disclosure via core dump (good). I can run the daemon under gdb in an isolated VM to capture a backtrace if useful.

---

Environment: O-Node @ 604edca, make … (+prod); Ubuntu Server 26.04, gcc 15.2, Go 1.26, libssh2 1.11.1; target = physical Cisco ASA5505, ASA 9.1(7)23.

[UWillC]

Update after reading the VIRP RFC (draft-howard-virp-03) + /docs: this looks like a conformance violation, not only a robustness/DoS bug.

The RFC makes "signed error on failure" a MUST:

• §11.5 (Error Observation Generation): "When a command execution fails (device unreachable, timeout, authentication failure), the O-Node MUST still generate a signed OBSERVATION message with (a) Observation type 0x05 (Error response), (b) payload containing the error description, (c) valid HMAC signature."
• §22.2(g): a conformant implementation MUST "generate signed error observations for failed commands."
• §21.2 Property 7 (Error Authenticity): "the absence of data is itself a verified fact, preventing the R-Node from filling gaps with fabricated output."

A device stuck at enable=0 when a command is issued is exactly an authentication/privilege failure during collection — so per the above the daemon should emit a signed type-0x05 error observation, not SIGSEGV. As-is it fails the §22.2 MUST and defeats the error-observation primitive (the gap the AI is supposed to be unable to fabricate over).

Original repro stands (isolated lab: a Cisco ASA landing at priv-1 / no enable cred in devices.json, then a collect). Happy to provide a minimal test vector if useful.