Skip to content

audit F5 [security]: HLC::receive accepts unbounded remote ts → clock-poisoning DoS #516

@intendednull

Description

@intendednull

File: crates/messaging/src/hlc.rs:172-188
Severity: security — availability + integrity (HIGH)
Obvious? yes

HLC::receive(remote) computes millis = wall.max(self.latest.millis).max(remote.millis) with no upper bound on remote.millis.

Attack: malicious or buggy peer broadcasts one message with remote.millis = u64::MAX - k. Every receiving peer's HLC permanently jumps to that value. Subsequent local events saturate in bump_counter, breaking message ordering forever, breaking "now"-based UIs and ephemeral-channel idle timers.

Spec section "Hybrid Logical Clocks" calls out this exact scenario; the clamp the prompt mentions is absent.

Fix: MAX_FORWARD_DRIFT_MS constant (e.g. 24h). Reject (or clamp) remote timestamps farther than that ahead of local wall clock. See bounded-skew variant (Kulkarni et al.).

(also flagged by separate auth audit as F11)


Filed by /general-audit @ b901575 (2026-05-02). master: #513.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions