I'm not sure what the proper channels are for comments on the ssh-2
protocol. I hope this message reaches the right persons, and that they
are not all occupied with the sshd exploit rumours. This comment does
*not* have any immediate security implications.
Two of the messages in the ssh connection protocol deals with unix
signals:
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "exit-signal"
boolean FALSE
uint32 signal number
boolean core dumped
string error message (ISO-10646 UTF-8 [RFC-2044])
string language tag (as defined in [RFC-1766])
and
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "signal"
boolean FALSE
uint32 signal number
The problem is the signal number field... Signal numbers are not the
same on all systems, not even for signals that exist on both systems.
Therefore, it is an error to send a signal number from one system to
another without some sort of translation. (I think some distributed
file systems have a similar bug regarding errno; they send raw error
numbers from the file server to the client, assuming that the same
error condition have the same number on all systems).
I think that the Right Way is to define some kind of canonical
"network signal numbers". ssh clients and servers should translate
their local signal numbers to this representation before transmitting
them. One also have to consider how one should handle peculiar or new
signals that doesn't have a canonical number assigned; the goal of
such a mechanism should at least make sure that all signals can be
transmitted properly between identical systems, while making it
possible to ignore them on other systems. One may also consider using
strings rather than numbers to identify signals, in order to make it
easier to add special system specific signals.
It is preferable if the "canonical" signal numbers agree with actual
signal numbers on most systems.
Now, I'm not aware of any standard defining a preferred numbering for
signals. I'm not very familiar with posix, but I'm afraid it only
defines signal names and leaves the corresponding numbers to the
implementation. If this is wrong, please point me to the relevant
standard document.
I think that the ssh2 specification needs to address this issue in one
way or the other.
I'd also like to know how DataFellow's ssh2 implementation addresses
this issue (as I'm working on my own free implementation of the
protocol, I prefer not to read DataFellow's source code).
Unless I get any better suggestions, my lsh program will do as
follows:
� Consider the following list (valid for sparc-linux) "canonical", and
translate local signal numbers to these numbers when sending them
between hosts:
/*
* Linux/SPARC has different signal numbers that Linux/i386: I'm trying
* to make it OSF/1 binary compatible, at least for normal binaries.
*/
#define _NSIG 32 /* Biggest signal number + 1. */
#define SIGHUP 1
#define SIGINT 2
#define SIGQUIT 3
#define SIGILL 4
#define SIGTRAP 5
#define SIGABRT 6
#define SIGIOT 6
#define SIGEMT 7
#define SIGFPE 8
#define SIGKILL 9
#define SIGBUS 10
#define SIGSEGV 11
#define SIGSYS 12
#define SIGPIPE 13
#define SIGALRM 14
#define SIGTERM 15
#define SIGURG 16
/* SunOS values which deviate from the Linux/i386 ones */
#define SIGSTOP 17
#define SIGTSTP 18
#define SIGCONT 19
#define SIGCHLD 20
#define SIGTTIN 21
#define SIGTTOU 22
#define SIGIO 23
#define SIGPOLL SIGIO /* SysV name for SIGIO */
#define SIGXCPU 24
#define SIGXFSZ 25
#define SIGVTALRM 26
#define SIGPROF 27
#define SIGWINCH 28
#define SIGLOST 29
#define SIGUSR1 30
#define SIGUSR2 31
� Support only the signals in this lists, leaving numbers beyond and
above free to be defined later. I think it is better to leave all
other numbers for use by some well-designed mechanism for sending
"non-standard" signals, than to invent some ad-hoc method for
supporting more signals.
Best regards,
/Niels M�ller
