[Bug 4034] 10.6: malformed SOCKS5 request terminates the ssh client
bugzilla-daemon at mindrot.org
bugzilla-daemon at mindrot.org
Tue Oct 27 06:15:32 AEDT 2026
https://bugzilla.mindrot.org/show_bug.cgi?id=4034
hello at tatryfab.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hello at tatryfab.com
Assignee|unassigned-bugs at mindrot.org |hello at tatryfab.com
Status|NEW |ASSIGNED
--- Comment #1 from hello at tatryfab.com ---
Created attachment 4014
--> https://bugzilla.mindrot.org/attachment.cgi?id=4014&action=edit
buf 4034 diff
had a look at this and can reproduce it on current master.
One thing worth adding to the original report: it isn't only -D. Remote
dynamic forwarding (ssh -R with no destination) runs through the same
decoder, so if you have a -R forward up, another user on the server
side
who can reach the listener can crash your client the same way. The same
four bytes do it:
printf '\005\001\000\377' | nc 127.0.0.1 <port>
channel_decode_socks5: channel 1: internal error: not socks5:
success
What's going on is that once auth is done the code keeps parsing in
case
the client coalesced the request into the same read, but the request
version byte never gets the sanity check the callers do on the first
byte. So a non-5 there trips the fatal() that was meant to be
unreachable.
The patch I've attached just treats that like any other malformed
request: log it at debug2 and close that one channel, instead of taking
the whole process down. I also added a case to
regress/dynamic-forward.sh
that sends the greeting and a bad request in a single write over both
-D
and -R and checks the mux master is still alive afterwards. It fails
before the change and passes after, and a normal greeting + CONNECT in
one write still works in both directions.
Happy to redo it if you'd rather handle it a different way.
--
You are receiving this mail because:
You are watching the assignee of the bug.
More information about the openssh-bugs
mailing list