Advisoriesby IbisUnauthenticated out-of-bounds stack write via oversized ECDSA signature in swift-nio-ssh
Summary
SwiftNIO SSH has a security vulnerability where an unauthenticated attacker can write data out of bounds on the stack. This happens because the system does not check the length of incoming ECDSA signature integers before copying them, allowing oversized values to overwrite memory prior to cryptographic verification.
Impact
A single crafted SSH message gives an unauthenticated network attacker an out-of-bounds stack write of attacker-controlled length and content against any application built on swift-nio-ssh:
- Server side: any peer that completes the SSH version/KEXINIT handshake (no credentials) can send a publickey SSH_MSG_USERAUTH_REQUEST with crafted signature blob. The signature is decoded while parsing the message — before the public key or signature is ever verified — triggering the write.
- Client side: a malicious or man-in-the-middle server triggers the same path via the ECDSA signature in its key-exchange reply.
Fix
Fixed in https://github.com/apple/swift-nio-ssh/commit/31cdc3c3391a10460dedf1170530cf651d2ca496
Mitigation
- Upgrade to 0.14.1 as soon as possible for the only complete fix.
- Partial mitigation: Restrict network exposure to only allow-listed trusted peers.
- Partial mitigation: Client side, only connect to trusted servers.
- Partial mitigation: Run services as a supervised/sandboxed process with auto-restart,...
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| swift-nio-ssh Product | < 0.14.1 | 0.14.1 |
Details and references
## Summary SwiftNIO SSH has a security vulnerability where an unauthenticated attacker can write data out of bounds on the stack. This happens because the system does not check the length of incoming ECDSA signature integers before copying them, allowing oversized values to overwrite memory prior to cryptographic verification. ## Impact A single crafted SSH message gives an unauthenticated network attacker an out-of-bounds stack write of attacker-controlled length and content against any application built on swift-nio-ssh: - **Server side:** any peer that completes the SSH version/KEXINIT handshake (no credentials) can send a publickey SSH_MSG_USERAUTH_REQUEST with crafted signature blob. The signature is decoded while parsing the message — before the public key or signature is ever verified — triggering the write. - **Client side:** a malicious or man-in-the-middle server triggers the same path via the ECDSA signature in its key-exchange reply. ## Fix Fixed in https://github.com/apple/swift-nio-ssh/commit/31cdc3c3391a10460dedf1170530cf651d2ca496 ## Mitigation - Upgrade to 0.14.1 as soon as possible for the only complete fix. - Partial mitigation: Restrict network exposure to only allow-listed trusted peers. - Partial mitigation: Client side, only connect to trusted servers. - Partial mitigation: Run services as a supervised/sandboxed process with auto-restart, reducing crashes to a contained denial of service. This attack is based on the signature type in an attacker's message, not on the configuration of any specific accepted algorithm. Algorithm restrictions do **not** help. Found by @Yanchon918s