v0.62.5
GHSA-m65r-rprj-r5rg - Handler channel callbacks called for non-existing channel - 7c5659f
Russh server did not validate channel IDs passed by a client, so if a client constructed a channel message with an invalid ID, the server-side Handler callback would still get called with that non-existing ID. The consequence of this depend on the specific user implementation.
- de96ad1: fixed #725 - add backpressure to Channel::data() (Eugene)
Full Changelog: https://github.com/Eugeny/russh/compare/v0.62.4...v0.62.5
v0.62.4
Three independent bugs have allowed a client to trigger a panic in the session handler task, thereby crashing their own session.
- GHSA-cqjc-rmpq-xprq: sending a malformed PTY request packet - 8912512
- GHSA-g9hv-x236-4qp3: sending a malformed Curve25519 KEX packet - a7fc1eb
- GHSA-5xvq-cp9x-6p6r: sending a zero Curve25519 key - a7fc1eb
v0.62.0
This changes the signature of the Handler::channel_open_* functions to allow you to make the channel accept/reject decision outside of the main event loop. Instead of immediately returning a bool, they take an additional reply: ChannelOpenHandle argument, which you can move into another async task to confirm or reject the channel later. After the handler function returns, the event loop is immediately unblocked.
This also lets you specify the protocol-level rejection reason.
Migrating your existing code:
async fn channel_open_session(
&mut self,
channel: Channel<Msg>,
+ reply: server::ChannelOpenHandle,
session: &mut Session,
- ) -> Result<bool, Self::Error> {
+ ) -> Result<(), Self::Error> {
if (...) {
- Ok(false)
+ reply.reject(ChannelOpenFailure::AdministrativelyProhibited).await;
} else {
- Ok(true)
+ reply.accept().await;
}
+ Ok(())
}
- redo of #729 - handle high flow messages better by @Eugeny in https://github.com/Eugeny/russh/pull/731
- @wilsonglasser made their first contribution in https://github.com/Eugeny/russh/pull/724
Full Changelog: https://github.com/Eugeny/russh/compare/v0.61.2...v0.62.0
v0.61.2
- f1a0f18: fixed #716 - ensure dynamic AgentClient refs are generally Send (#717) (Eugene) #717
- 6dc4919: expose channel number from ChannelId (Eugene)
- support SEC1 EC keys with full domain parameters (#719) #719 (Moder Steven)
- aa48fa7: make DhGroup fields public (Eugene)
- ca8ae67: update auth_publickey_offered doc (Eugene)
- 761483a: fixed #720 - bump deps (#721) (Eugene) #721
v0.61.1
When compression is negotiated, an attacker can craft a "ZIP bomb" style packet that would bypass the maximum packet size checks. This could allow the attacker to hit the OOM limit and either get the server process killed by the OS, or, prior to russh@0.58.0, aborted. A similar issue existed in the AgentClient as well, which could be triggered by a malformed SSH agent response.
- keys/agent: forward full agent signature blob for sk-ecdsa/sk-ed25519 keys (#701) #701 (ztbh)
- accept empty name-list in KEXINIT (RFC 4251 §5) (#710) #710 (Bernardo Meurer)
v0.61.0
-
32fd46f: Reduce russh write-path copies with direct Bytes sends (#695) (Mika Cohen) #695
- New APIs allow zero-copy writes into channels:
Channel::data_bytesChannel::extended_data_bytesChannelWriteHalf::data_bytesChannelWriteHalf::extended_data_bytes
- New APIs allow zero-copy writes into channels:
-
deps: migrate to stable versions pkcs5 / pkcs8 / ed25519 and loosen prerelease pins (extends #697) (#702) #702 (escapecode)
-
72b250a: migrate to upstream
ssh-keycrate and update RustCrypto crates (#709) (Eugene) #709
Part of the hardening efforts by @mjc
- When a client changed their username between authentication requests,
russhserver implementation would not correctly reset its internal state (allowed methods and "partial success" state), which could lead to incorrect responses to the client.- Note that you still need to handle the case where the client sends a subsequent authentication request with a different username and reset any accumulated authentication state your application might have
- When a client sent a
keyboard-interactiveauthentication request, the prompt counter was used to directly allocate memory without verifying it, which can lead to denial of service.
russhserver did not enfore the SSH protocol header validation strictly enough, allowing a client to hold the connection open indefinitely, wasting resources.
- "Name list" fields such as algorithm lists were only bounded by the packet size. While the SSH protocol does not impose a limit, in practice it could allow a client to waste resources by spamming huge KEXINIT messages via multiple connections.
- 4186cf2: Refactor block-cipher packet-length probing to avoid unsafe state duplication (#706) (Mika Cohen) #706
- reject trailing KEX and channel-open payloads (Mika Cohen)
- reject trailing encrypted message payloads (Mika Cohen)
v0.60.3
- a2d48a7 (Mika Cohen)
When compression is negotiated, an attacker can craft a "ZIP bomb" style packet that would bypass the maximum packet size checks. This could allow the attacker to hit the OOM limit and either get the server process killed by the OS, or, prior to russh@0.58.0, aborted. A similar issue existed in the AgentClient as well, which could be triggered by a malformed SSH agent response.