StreamSec Home  Forum Home 
 
Welcome, Guest.
Your IP: 216.73.217.138
2026-10-07 01:16:49 
 Announcements
 SECURITY ADVISORY - StreamSec Tools 4.1.1.349 to 4.1.4.360, patch P02 An SSH peer's advertised maximum packet size of 2^31 or more hangs or crashes the other end (denial of service).
Bottom
 
Total posts: 1
 Author SECURITY ADVISORY - StreamSec Tools 4.1.1.349 to 4.1.4.360, patch P02 An SSH peer's advertised maximum packet size of 2^31 or more hangs or crashes the other end (denial of service).
Henrick Wibell Hellström

2026-10-06 19:40:49
Registered user
AFFECTED RELEASES
StreamSec Tools 4.1.1.349 through 4.1.4.360, in the dotted StreamSec.SSH.*
channel units (StreamSec.SSH.ClientChannel, StreamSec.SSH.ServerChannel),
the SSH stack installed since 4.1.1.349. The legacy st-prefixed channel
units are a separate branch, not installed since 4.1.1.349 and not covered
here. The release after 4.1.4.360 carries the fix; until it is published,
patch P02 (StreamSec_Tools_4.1.4.360_P02_SshChannelPacketSize.txt) carries
the same fix as a manual source edit.

THE VULNERABILITY
An SSH channel's maximum packet size is a uint32 chosen by the peer. Both
ends held it in a signed Integer, so a value of 2^31 or more became a
negative size, with no upper bound on the client's end and a signed - and
so bypassed - bound on the server's end. A channel's Send sizes each
SSH_MSG_CHANNEL_DATA message from that value: a peer advertising 2^32 - 1
makes the size -1, the message buffer 8 octets, and the 9-octet header
write runs one octet past the heap buffer; a larger value makes the buffer
length negative and the allocation faults. Send then loops without
progress. Measured at both ends: on Win32 the first send never returns (a
busy loop); on Win64 the process faults (EInvalidPointer, then an access
violation).

IMPACT
Denial of service. On a client, a hostile or compromised SSH server hangs
or crashes the client process as soon as the client sends on a channel it
has opened (the client need only connect, log in - which a malicious server
grants freely - and use the channel). On a server, an authenticated user
hangs the connection thread, or on Win64 crashes the whole server process,
denying every connection. The one-octet heap write is a fixed octet at a
fixed offset and the faulting thread does not use the corrupted memory;
no impact beyond denial of service has been traced.

SEVERITY
A denial of service: availability only, no loss of confidentiality or
integrity.
  CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
The attack is over the network (AV:N) against an end that opens or accepts
a channel; on the client no privileges are needed (the attacker is the
server), on a server the attacker is an authenticated user. Read the
band and decimal off the official FIRST.org CVSS v4.0 calculator for this
vector at publication, rather than computing them by hand.

WHAT TO DO
Do ONE of the following.
1. Upgrade to the first release after 4.1.4.360 when it is published, and
   rebuild your application.
2. Apply patch P02 to your release's source and rebuild the packages and
   your application. There is no configuration or usage work-around: an
   application cannot refuse a peer's packet size without this code change,
   so unlike patch P01 this one must be applied (or the upgrade taken) - it
   cannot be stood in for by a change in how the components are used.
3. Reduce exposure meanwhile: a client that pins its server's host key
   (patch P01) reaches only its intended server; a server has no such
   measure against an authenticated user.

CREDIT
Found in an internal review of the SSH channel layer. There is no evidence
of exploitation.

IDENTIFIER
This advisory is identified by the releases it applies to and the patch
number P02 (counted per release, at 4.1.4.360). CVE identifiers are not
used (SECURITY.txt, section 4).

Attachments:
Top

:: Written with and Powered by StreamSec Tools 4.1 ::
Copyright © 2000-2026 StreamSec Handelsbolag
Forum data layer and page templates derived from the RealThinClient SDK web-forum example, Copyright © 2004-2022 Teppi Technology (MIT)