Crossing the Streams: SSH Plaintext Recovery via a Common Compression Context in Multiplexed Channels

1 Introduction

• SSH port forwarding is widely used for cloud services, databases, and VPN-like connections, making its security properties relevant to varied deployments.The prevalence of specific deployments is not publicly measured.Source: §1 · p. 1
• The paper asks whether channel multiplexing creates security-relevant interactions, whether attackers can inject chosen plaintext into secret-bearing channels, and whether compression enables adaptive recovery.It answers affirmatively and develops an attack combining eavesdropping with chosen-plaintext injection under a network- or web-attacker model.Source: §1 · pp. 1–2
• When compression is enabled, data from different channels share a compression context, allowing cross-channel effects on compressed lengths that an eavesdropper can observe with noise.The paper frames this as a security-relevant interaction that existing SSH specifications do not address.Source: §1 · p. 1
• Port forwarding can provide a high-bandwidth, partially chosen-plaintext oracle, while browser-based injection faces port-blocking and CORS restrictions.The paper also evaluates direct injection, browser-based injection, and recovery of an Ansible sudo password, and analyzes SSH client capabilities and defaults.Source: §1 · p. 2
• The attack is positioned at the boundary between SSH protocol layers, unlike prior SSH attacks that have almost exclusively targeted the Transport Layer Protocol.The paper also identifies protocol noise, padding, application behavior, and browser restrictions as factors that can degrade or remove the length oracle.Source: §1 · p. 2

2.1 SSH Key Exchange and User Authentication

• SSH negotiates algorithms and establishes a server-authenticated symmetric session key before using the transport layer for authentication and Connection Protocol services.Compression is optional, and the supported zlib variants differ in whether compression starts before or after user authentication.Source: §2.1 · p. 3

2.2 SSH Binary Packet Protocol

• The BPP optionally compresses each message before padding and authenticated encryption; padding is at least four bytes and usually minimal in practice.SSH message lengths may be encrypted, depending on the cipher mode.Source: §2.2 · p. 3

2.3 Zlib Compression

• LZ77 replaces repeated strings with back-references, while Deflate combines LZ77 with Huffman coding and selects among block types.Dynamic Huffman blocks tailor codes to a segment but incur tree overhead.Source: §2.3 · p. 3
• SSH requires a partial flush between packets, closing the current block and emitting a 10-bit empty static block so compressed data is emitted as complete bytes.The bytes emitted depend on the compressed payload length.Source: §2.3 · p. 4

3.1 SSH Connection Protocol and Channels

• All SSH channel messages share one BPP connection and are processed sequentially; each channel otherwise has its own identifiers, lifecycle, and flow-control window.When compression is enabled, messages are compressed before padding, encryption, and integrity protection.Source: §3.1 · p. 4

3.2 Attacker-Controlled Data and Secret Data

• TCP port forwarding provides a high-bandwidth, low-noise, partially chosen-plaintext injection vector, while attacker access to other channel interfaces depends on their interface and threat-model constraints.The injected TCP payload is carried in channel-data messages with lightweight headers.Source: §3.2 · pp. 4–5
• Five of seven channel types are situationally secret-bearing, X11 is secret-bearing by definition, and SSH agent forwarding is not secret-bearing regarding private keys.Local TCP forwarding, remote TCP forwarding, and X11 forwarding can each be both secret-bearing and injection vectors.Source: §3.2 · pp. 5–6

3.3 Cross-Channel State Sharing in the BPP

• SSH maintains one compression context per direction, and its 32 KiB search buffer retains prior plaintext so later messages can back-reference data from another channel.A partial flush emits pending compressed output but leaves the search buffer intact, so message boundaries do not isolate channel compression history.Source: §3.3 · p. 6
• The shared search buffer lets attacker-controlled and secret-bearing data on different channels affect each other’s compressed lengths within the same compression window.The analysis relies on authenticated encryption without compression to provide the intended confidentiality and integrity guarantees; it derives no attack from shared encryption state.Source: §3.3 · p. 6

4.1 Attacker Model

• The attacker observes aggregate ciphertext lengths and injects partially chosen plaintext through a forwarded TCP port or a victim’s browser.Success requires compression, secret-bearing and injection channels multiplexed in the same direction, and repeated secret transmissions; known prefixes, alignment knowledge, and triggering the secret reduce cost.Source: §4.1 · p. 6

4.2 Attack Algorithm

• A correct candidate extends an LZ77 match with the secret, while an incorrect candidate adds a literal; alignment makes the resulting length difference observable through SSH padding.A known prefix and recovered bytes anchor each guess; without a known prefix, the leading bytes must first be brute-forced.Source: §4.2 · p. 7
• Each trial flushes prior search-buffer contents with 32 KiB of random data, and repeated measurements accumulate until one candidate clears the commit margin.Committed bytes extend the guess for the next round; recovery ends at a known terminator, explicit length, or password check.Source: §4.2 · p. 7

4.3 Noise Compensation Strategies

• Candidate elimination drops lagging guesses; full alignment sweeps handle unknown alignment at higher measurement and noise cost, while adaptive sweeps prune and later restore unproductive alignments.Adaptive restoration occurs when the remaining alignments show no candidate difference for two consecutive rounds.Source: §4.3 · pp. 7–8

4.4 Differences from TLS Compression Attacks

• SSH requires aggregate byte-length measurements, active 32 KiB buffer flushing, and injection through channel-data framing, unlike the measurement and state-reset assumptions described for TLS attacks.The shared compression context across logically separate SSH channels is the novel cross-channel feature exploited by the attack.Source: §4.4 · p. 8

5 Evaluation

• Across three scenarios, the proof of concept targets a forwarded Redis password through direct injection, browser-based injection, and an Ansible become password on a session channel.The evaluation also tests OpenSSH with ChaCha20-Poly1305, whose encrypted packet-length field prevents reliable observation of individual packet sizes.Source: §5 · p. 8, §5.1 · p. 8, §5.2 · p. 9

5.1 Direct Plaintext Injection

• Direct injection uses a network-reachable forwarded port as a chosen-plaintext oracle, flushing 32 KiB of random data before each secret-and-guess measurement.The OpenSSH setup requires an explicit bind address or GatewayPorts for direct access to the forwarded port.Source: §5.1 · pp. 8–9

5.2 Browser-Based Plaintext Injection

• Browser injection reaches a localhost-bound forward through the victim’s browser; random request-body data isolates the guess in a static Huffman block to restore the per-byte signal.The proof of concept uses Firefox, while the paper also reports a restricted-oracle PNA evaluation with Chromium 149: 67–69% success and 2,867–40,326 guesses per trial.Source: §5.2 · p. 9

5.3 Ansible Password Recovery

• Ansible’s become password travels on a session channel with a predictable prefix; a fresh SSH connection starts with an empty compression context, so no attacker-initiated flush is needed.The proof of concept disables ControlMaster; when it is active, the authors say the attack remains applicable by adding the direct-variant flush.Source: §5.3 · pp. 9–10

5.4 Attack Performance

• Across 100 trials per variant and configuration, the evaluation raises commit margins until all trials succeed, allowing up to two retries; known-alignment configurations are marked n/a for the noisy browser variant.The tested secrets are eight-character lowercase passwords, and reported guess counts include the password length and terminator.Source: §5.4 · p. 10
• At an 8-byte commit margin, direct injection with a full alignment sweep recovered the password in 44 of 100 runs; lower margins reduce guess counts but do not guarantee recovery.The reported guess counts at the tested commit margins guarantee recovery and are upper bounds rather than typical counts.Source: §5.4 · p. 10

5.5 SSH Implementations

• Twenty-nine of 33 surveyed clients can be configured to be vulnerable, but no client both prefers compression and defaults to all-interface port forwarding; 93% of surveyed SSH servers support compression.Four clients lack compression support or port forwarding; default installations are therefore not directly vulnerable to a network attacker.Source: §5.5 · p. 10

6 Server-Side Attacks on X11 Forwarding

• Only the first byte of the MIT magic cookie was recovered in this server-side variant, establishing feasibility rather than a full evaluation.The authors did not fully evaluate this variant.Source: §6 · p. 10

6.1 X11 Authentication and Forwarding

• Table 3 compares guess counts across three attack scenarios and five compensation configurations; browser injection requires alignment sweeps because of its high noise floor.Counts were recorded after commit margins were increased in 8-byte steps until all 100 trials succeeded, with up to two retries.Source: Table 3 · p. 11
• Table 4’s selected SSH clients are classified by platform, compression defaults, and local, remote, and dynamic port-forwarding support.It marks clients configurable to be vulnerable and distinguishes public-by-default binds from other supported forwarding.Source: Table 4 · p. 11
• X11 authentication uses a 16-byte MIT magic cookie sent after a fixed 32-byte header, while SSH forwarding installs the cookie on the remote server.Implementations such as OpenSSH may instead install a fake cookie, validate it on the client, and substitute the original there.Source: §6.1 · p. 11

6.2 Security Analysis of SSH X11 Forwarding

• X11 forwarding can provide both a secret-bearing channel and an injection channel when its listener is exposed through a TCP port.In OpenSSH, unauthenticated attacker data is compressed and transmitted before client-side cookie validation rejects it; the attacker also needs traffic-volume observation and enough honest X11 connections while the cookie remains valid.Source: §6.2 · pp. 11–12

6.3 Attack Scenario

• The scenario assumes a victim uses ssh -C -X on a multi-user server and a co-resident attacker can reach the server-side X11 listener.The attacker lacks an on-path vantage point and instead may use host-level transmitted-byte counters as a length signal to recover the fake cookie.Source: §6.3 · p. 12
• Recovering the cookie may let attacker-controlled X11 clients open windows or access clipboard, input, and window contents, depending on settings and extensions.The attacker might also target the X11 server implementation directly; access to the original cookie could enable direct local-network access to the X11 server.Source: §6.3 · p. 12
• Unlike the client-side scenarios, this attack targets a Connection Protocol cookie flowing server-to-client, with client-side validation admitting unauthenticated data into compression.Source: §6.3 · p. 12

• Prior SSH security research largely targets key exchange, user authentication, the transport layer, and keystroke timing leakage in interactive sessions.Source: §7 · p. 12
• Compression side channels have been demonstrated across TLS, SPDY, HTTP, XMPP, VoIP, video, VPNs, databases, and cloud storage; SSH was discussed earlier without channel multiplexing.Browser timing attacks such as HEIST and TIME replaced the MitM eavesdropper in CRIME-style attacks.Source: §7 · p. 12
• HTTP/2 and HTTP/3 restrict compression to headers, and HPACK and QPACK support excluding secret values; separate work exploited multiplexing through timing attacks.Source: §7 · p. 12

8 Discussion

• The attack surface arises because SSH multiplexes channels whose bytes share one compression context, a behavior not addressed by either protocol specification in isolation.The BPP compresses bytes without channel awareness, while the Connection Protocol presents channels as independent streams.Source: §8 · p. 12

8.1 Feasibility and Limitations

• The authors establish feasibility under specific configurations but do not quantify how often all required conditions occur together in deployed systems.Those conditions include negotiated compression, multiplexed channels in the same direction, secret-bearing and partially chosen-plaintext channels, and repeated secret transmission.Source: §8.1 · p. 13
• Without active triggering, naturally occurring secret transmissions constrain attack timing and can increase the guesses needed when guesses miss the secret’s compression context.The authors note synchronization can occur when the secret is sent at connection start.Source: §8.1 · p. 13
• For AES-based modes, the attack still applies, but 16-byte padding makes the alignment sweep grow with block length and increases required guesses linearly.The evaluation is tuned to ChaCha20-Poly1305 through its padding-granularity alignment sweep.Source: §8.1 · p. 13

8.2 Impact of Noise

• Noise requires multiple measurements per candidate byte and can erase the length difference, while compensation strategies enabled recovery in the evaluated noisy browser scenario.Because channels share a compression context, noise on an unrelated channel has the same effect as similar noise on the guess or secret channel.Source: §8.2 · p. 13
• Recovery fails when throughput prevents reliable injection of guesses close to the secret.This is the stated hard limit on tolerable noise.Source: §8.2 · p. 13

8.3 Countermeasures

• Disabling compression removes the compression side-channel risk; otherwise, sensitive sessions can use fresh connections and implementations can encourage isolation by default.The authors also recommend warning when compression and port forwarding are enabled together and leaving ControlMaster off by default.Source: §8.3 · p. 13
• Selective, per-channel compression would allocate separate states, but the original BPP specification cannot implement per-channel contexts because the channel ID is itself compressed.The proposal compresses channel data after the channel-open handshake while excluding message and channel IDs; it costs more memory, and bandwidth effects may vary. The authors also identify deprecating compression, stronger defaults, or new algorithms as options for discussion.Source: §8.3 · pp. 13–14

9 Conclusion

• All SSH channels share one BPP compression context, coupling compressed lengths of secret-bearing and attacker-controlled packets and enabling secret recovery with partially chosen plaintext.The attack requires its conditions to hold; TCP port forwarding is identified as an injection vector.Source: §9 · p. 14
• X11 forwarding is secret-bearing because it carries an authentication token, while SSH agent forwarding is not secret-bearing by design.Other channel types are application-defined and potentially secret-bearing; TCP port forwarding offers a high-bandwidth, low-noise injection channel for a network attacker.Source: §9 · p. 14
• Unlike CRIME and BREACH, the SSH attack can use separate secret-bearing and injection channels when both share the same connection.The paper identifies this cross-channel attack as a composition risk.Source: §9 · p. 14
• An 8-character secret over a 26-letter alphabet required 276 guesses in Ansible, 1 260 with direct injection, and 27 619.5 in the browser-based scenario.These are medians over 100 trials with candidate elimination, plus an adaptive alignment sweep for the browser variant.Source: §9 · p. 14
• The work identifies channel multiplexing as a security-relevant boundary and aims to guide safer SSH configurations, implementations, and standards.The authors identify users, vendors, and standardization committees as audiences for that guidance.Source: §9 · p. 14

Generative AI Usage

• ChatGPT, Gemini, and Claude responses were used to reflect on text structure and revise paragraphs for readability and coherence.LanguageTool was used continuously for editorial changes.Source: Generative AI Usage · p. 14
• Claude Code was used to implement proof-of-concept attack scenarios from the generic attack description, attacker model, and scenario descriptions.The authors specified that implementation shortcuts should be avoided.Source: Generative AI Usage · p. 14
• The authors manually reviewed the generated code and used integration tests to verify end-to-end password recovery.They state that these checks ensure the figures in Table 3 are accurate.Source: Generative AI Usage · p. 14

A Ethical Considerations

• SSH users' passwords or other secrets can be recovered when the attack preconditions hold, including secrets of services reached through tunnels even if those services are otherwise secure.The authors identify vendors and maintainers as stakeholders because feature choices and defaults influence exploitability.Source: A Ethical Considerations · p. 16
• The authors say the findings show that the SSH Connection Protocol and Binary Packet Protocol cannot be reasoned about separately.They identify this as a potential starting point for standards-level discussion.Source: A Ethical Considerations · p. 16
• The authors contacted maintainers of vulnerable-by-default implementations before planned public disclosure to the IETF sshm mailing list.They state that users can immediately mitigate the attack by disabling SSH compression on either end of the connection.Source: A Ethical Considerations · p. 16
• The authors report that experiments used infrastructure under their control and involved no production systems, third-party servers, non-consenting users, or collected user data.They also acknowledge that the published artifacts carry some misuse risk.Source: A Ethical Considerations · p. 16
• The authors judge publication alongside their mitigations ethically justified, reasoning that non-publication would leave users at risk.They cite the root cause's presence in SSH since channel multiplexing and compression were first specified.Source: A Ethical Considerations · p. 16

B Open Science

• The authors release their artifacts under the Apache-2.0 license to allow independent reproduction and foster further research.They describe this as part of their commitment to open science.Source: B Open Science · p. 16
• The release includes a Python attack engine, adapters for three scenarios, Docker images, compose files, helper scripts, tests, and documentation.The integration tests recover a single password to verify algorithmic correctness.Source: B Open Science · p. 16
• The authors provide raw evaluation statistics used to compile Table 3.The artifacts are made available at the DOI stated in the paper.Source: B Open Science · p. 16