summaryrefslogtreecommitdiff
path: root/PROTOCOL
diff options
context:
space:
mode:
authorDarren Tucker <dtucker@zip.com.au>2008-06-11 09:34:01 +1000
committerDarren Tucker <dtucker@zip.com.au>2008-06-11 09:34:01 +1000
commit8901fa9c88d52ac1f099e7a3ce5bd75089e7e731 (patch)
treeb8d241457d1c0abc2cbfb901f861864bd6940764 /PROTOCOL
parentc9807e825a83df6d95ae7e0390c34ab71321f30b (diff)
- djm@cvs.openbsd.org 2008/06/10 22:15:23
[PROTOCOL ssh.c serverloop.c] Add a no-more-sessions@openssh.com global request extension that the client sends when it knows that it will never request another session (i.e. when session multiplexing is disabled). This allows a server to disallow further session requests and terminate the session. Why would a non-multiplexing client ever issue additional session requests? It could have been attacked with something like SSH'jack: http://www.storm.net.nz/projects/7 feedback & ok markus
Diffstat (limited to 'PROTOCOL')
-rw-r--r--PROTOCOL33
1 files changed, 28 insertions, 5 deletions
diff --git a/PROTOCOL b/PROTOCOL
index 4d7a447b..76e6adb4 100644
--- a/PROTOCOL
+++ b/PROTOCOL
@@ -61,7 +61,30 @@ remain open after a "eow@openssh.com" has been sent and more data may
still be sent in the other direction. This message does not consume
window space and may be sent even if no window space is available.
-4. sftp: Reversal of arguments to SSH_FXP_SYMLINK
+4. connection: disallow additional sessions extension
+ "no-more-sessions@openssh.com"
+
+Most SSH connections will only ever request a single session, but a
+attacker may abuse a running ssh client to surreptitiously open
+additional sessions under their control. OpenSSH provides a global
+request "no-more-sessions@openssh.com" to mitigate this attack.
+
+When an OpenSSH client expects that it will never open another session
+(i.e. it has been started with connection multiplexing disabled), it
+will send the following global request:
+
+ byte SSH_MSG_GLOBAL_REQUEST
+ string "no-more-sessions@openssh.com"
+ char want-reply
+
+On receipt of such a message, an OpenSSH server will refuse to open
+future channels of type "session" and instead immediately abort the
+connection.
+
+Note that this is not a general defence against compromised clients
+(that is impossible), but it thwarts a simple attack.
+
+5. sftp: Reversal of arguments to SSH_FXP_SYMLINK
When OpenSSH's sftp-server was implemented, the order of the arguments
to the SSH_FXP_SYMLINK method was inadvertendly reversed. Unfortunately,
@@ -74,7 +97,7 @@ SSH_FXP_SYMLINK as follows:
string targetpath
string linkpath
-5. sftp: Server extension announcement in SSH_FXP_VERSION
+6. sftp: Server extension announcement in SSH_FXP_VERSION
OpenSSH's sftp-server lists the extensions it supports using the
standard extension announcement mechanism in the SSH_FXP_VERSION server
@@ -95,7 +118,7 @@ ever changed in an incompatible way. The server MAY advertise the same
extension with multiple versions (though this is unlikely). Clients MUST
check the version number before attemping to use the extension.
-6. sftp: Extension request "posix-rename@openssh.com"
+7. sftp: Extension request "posix-rename@openssh.com"
This operation provides a rename operation with POSIX semantics, which
are different to those provided by the standard SSH_FXP_RENAME in
@@ -112,7 +135,7 @@ rename(oldpath, newpath) and will respond with a SSH_FXP_STATUS message.
This extension is advertised in the SSH_FXP_VERSION hello with version
"1".
-7. sftp: Extension requests "statvfs@openssh.com" and
+8. sftp: Extension requests "statvfs@openssh.com" and
"fstatvfs@openssh.com"
These requests correspond to the statvfs and fstatvfs POSIX system
@@ -153,5 +176,5 @@ The values of the f_flag bitmask are as follows:
This extension is advertised in the SSH_FXP_VERSION hello with version
"2".
-$OpenBSD: PROTOCOL,v 1.5 2008/06/09 13:38:46 dtucker Exp $
+$OpenBSD: PROTOCOL,v 1.6 2008/06/10 22:15:23 djm Exp $