GHSA-m65r-rprj-r5rg Russh: Channel-scoped server callbacks can be reached without an open channel
There is a server-side channel state issue in `russh`.After a client is authenticated, `russh` can dispatch channel-scoped handler callbacks for recipient channel IDs that were never opened or confirmed. In the strongest reproduced case, the client does not send `SSH_MSG_CHANNEL_OPEN` at all. It authenticates normally, then sends `SSH_MSG_CHANNEL_REQUEST` packets with request type `exec` for a range of recipient channel IDs. `russh` still calls the server application's `exec_request` handler.This is not an authentication bypass. A valid login is required. The issue is that the SSH channel lifecycle is not enforced before channel-scoped callbacks are delivered to the application.ImpactAn authenticated client can bypass the server application's channel-open policy.A server may deny session channels by returning `false` from `Handler::channel_open_session`. A server may also assume that callbacks such as `exec_request`, `shell_request`, `subsystem_request`, `data`, `channel_eof`, or `channel_close` are only delivered for channels that were opened and confirmed by the SSH transport layer.That assumption does not hold in the vulnerable path. A malicious authenticated peer can send channel-scoped messages for arbitrary recipient channel IDs and cause handler callbacks to run even though no channel exists.The exact impact depends on the downstream application. For many SSH server use cases, `exec_request`, `shell_request`, or `subsystem_request` start commands, jobs, shells, SFTP-like subsystems, internal workflows, or other state-changing operations. In the PoC, the protected `exec_request` action runs even though no channel was opened.Why this is not intended behaviorSSH channel requests are not global post-authentication requests. They are operations on an existing channel.RFC 4254 describes channel-specific messages as carrying a recipient channel number. The `exec` request is a `SSH_MSG_CHANNEL_REQUEST` for a session channel. That means the recipient channel should refer to a channel that exists in the local open-channel state.The relevant boundary is therefore not password authentication. The boundary is the channel-open decision. If no channel has been opened, or if the application denied the open request, `russh` should not deliver session-specific callbacks for that recipient ID.This is also not just a handler bug. The handler does not own the transport channel table. `russh` does. The application gets a `channel_open_*` callback and returns whether the channel is allowed. If that decision is denied, or if the client never requested a channel at all, channel-scoped callbacks should not be reachable.Documentation and API boundaryThe public API documentation supports this boundary.`channel_open_session` is the application hook for creating a new session channel, and its boolean return value is the application's decision on whether that channel open should be granted. Separately, `exec_request` is the application hook for deciding what to do with a command request received on a channel.Those are different responsibilities. The application can decide whether a command is allowed. The library must first decide whether the recipient channel exists and was actually opened.Delivering `exec_request` for a recipient `ChannelId` that is absent from the established channel table bypasses the channel-open decision before the application can safely rely on it.Root causeIn `server_read_authenticated` in `russh/src/server/encrypted.rs`, channel-scoped messages are decoded and then dispatched to handler callbacks without a mandatory check that the recipient channel is established in the encrypted session's channel table.The problematic pattern is visible in the `CHANNEL_REQUEST` handling. The code reads the recipient channel ID and request fields. It may look up the channel to send an internal `ChannelMsg` into the stream API, but the handler callback is outside that guard.For example, the `exec` branch has this shape:If `channel_num` is not open, the internal send is skipped, but `handler.exec_request(...)` is still called.The same issue applies to other channel-scoped callbacks such as `shell_request`, `subsystem_request`, `env_request`, `pty_request`, `data`, `extended_data`, `channel_eof`, and `channel_close`.There is a second related problem in `server_handle_channel_open`. The application-side channel reference can be inserted into `self.channels` even when the handler returns `Ok(false)`. The protocol table `enc.channels` is only populated when the open is actually allowed. This means the two maps can diverge after a denied open.The authoritative source for whether a channel is established should be `enc.channels`, not `self.channels`.Evidence from the PoCThe PoC uses a real `russh` server over localhost TCP. It uses real authentication with username `alice` and password `correct`. Paramiko is used only as an authenticated SSH peer that can send crafted packets over the real encrypted SSH transport.POC Code :The crafted packet form is:The PoC runs normal controls and exploit cases in one execution.Allowed controlThis proves the protected action works normally when a session channel is opened.Denied controlThis proves the application policy denies session channels and a normal client cannot reach the protected action.Main exploit: no channel openThis is the main issue.The authenticated client does not send `SSH_MSG_CHANNEL_OPEN`. It sends crafted `SSH_MSG_CHANNEL_REQUEST` packets for recipient IDs `0..31`.This removes the "guessed channel ID" concern. Every scanned recipient ID reached the protected action in the vulnerable run.Additional variant: denied openThe client asks for a session channel, the handler denies it, and the client then sends the same crafted requests.The denied-open variant is not required for exploitability, but it shows the same state validation gap after an explicit application denial.Affected code pathVerified at:The affected logic is in:The vulnerable area is:Channel request dispatch decodes a recipient channel ID and calls request-specific handler callbacks without first requiring that the recipient ID exists as a confirmed channel in `enc.channels`.The affected request callbacks include:The same missing established-channel guard affects:A related issue exists in:Application channel references should not be retained for denied opens.Why this belongs in russhThe application cannot reliably enforce the SSH transport channel lifecycle from inside individual callbacks. By the time `exec_request` is called, the application is already being told that a channel-scoped request exists. The library should not call that handler for a channel ID that does not exist in the confirmed channel table.This is the same kind of invariant `russh` already applies for some channel state updates. The missing part is to apply the established-channel check consistently before all channel-scoped callbacks are dispatched.The safe expectation is simple:Suggested fixBefore dispatching any channel-scoped callback, require the recipient `ChannelId` to exist in the encrypted session's established channel table and to be confirmed.The authoritative check should use `enc.channels`, not `self.channels`.A minimal approach is to add a helper like:Then call it before dispatching channel-scoped callbacks for:For unknown or unconfirmed channels, `russh` should not call application callbacks. The exact wire response can be request failure, ignore, or disconnect depending on the existing protocol-error handling for that message type.The channel-open path should also retain application-side channel references only when the open is approved:Regression coverageA regression test should authenticate normally, then verify that callbacks are not reached in these cases:The test should fail if any channel-scoped callback such as `exec_request`, `shell_request`, `subsystem_request`, `data`, `channel_eof`, or `channel_close` is invoked for a non-established channel.A positive control should confirm that a normally opened session channel still reaches the expected callbacks.In the local validation, the targeted regression passed after the patch:The full workspace also passed:Duplicate checkI checked existing `Eugeny/russh` advisories and issue searches for terms related to:Existing advisories cover unrelated authentication, parser, allocation, window-adjust, Terrapin, and cryptographic issues. I did not find an existing advisory or issue for channel-scoped callbacks being dispatched for unopened or denied recipient channel IDs.
CVSS v3.1 score: 6.5