the_sut.tex 8.08 KB
Newer Older
1
2
\section{The Secure Shell Protocol} \label{sec:ssh}

3
The Secure Shell Protocol (or SSH) is a protocol used for secure remote login and other secure network services over an insecure network. It is an application layer protocol running on top of TCP, which provides reliable data transfer, but does not provide any form of connection security. The initial version of SSH was superseded by a second version (SSHv2), as the former was found to contain design flaws~\cite{FutoranskyAttack} which could not be fixed without losing backwards compatibility. This work focuses on SSHv2.  
4
5
6

SSHv2 follows a client-server paradigm consisting of three components (Figure~\ref{fig:sshcomponents}):
\begin{itemize}
7
\item The \textit{transport layer protocol} (RFC 4253~\cite{rfc4253}) forms the basis for any communication between a client and a server. It provides confidentiality, integrity and server authentication as well as optional compression. 
8
9
10
11
\item The \textit{user authentication protocol} (RFC 4252~\cite{rfc4252}) is used to authenticate the client to the server.
\item The \textit{connection protocol} (RFC 4254~\cite{rfc4254}) allows the encrypted channel to be multiplexed in different channels. These channels enable a user to run multiple processes, such as terminal emulation or file transfer, over a single SSH connection. 
\end{itemize}

Paul Fiterau Brostean's avatar
Paul Fiterau Brostean committed
12
Each layer has its own specific messages.  The SSH protocol is interesting in that outer layers do not encapsulate inner layers. This means that different layers can interact. Hence, it makes sense to analyze SSH as a whole, instead of analyzing its constituent layers independently. We review each layer, outlining the relevant messages which are later used in learning. We refer to as \textit{happy flow},
13
14
the common case of a successful operation. 

Paul Fiterau Brostean's avatar
Paul Fiterau Brostean committed
15
The SSH protocol happy flow at a high level consists of the following steps: (1) the client first establishes a TCP connection with the server, (2) the two sides negotiate encryption algorithms, and subsequently establish one-time session keys via a negotiated key exchange method, further communication is secured using these keys,  (3) the client authenticates to the server by providing valid credentials and finally, (4) the client accesses services on the server like for example the terminal service. Leaving out the first step, each step that follows is an integral part of each SSH layer.
16
17
18

%perhaps room for figure

19
20
21
22
%Different layers are identified by their message numbers. These message numbers will form the basis of the state fuzzing. The SSH protocol is especially interesting because outer layers do not encapsulate inner layers. This means that different layers can interact. One could argue that this is a less systematic approach, in which a programmer is more likely to make state machine-related errors.

\begin{figure}[!hb]
\centering
Paul Fiterau Brostean's avatar
Paul Fiterau Brostean committed
23
  \includegraphics[scale=0.35]{SSH_protocols.png}
24
25
26
27
28
  \caption{SSH protocol components running on a TCP/IP stack.}
  \label{fig:sshcomponents}
\end{figure}

\subsection{Transport layer}\label{ssh-run-trans} 
29
SSH runs over TCP, and provides end-to-end encryption based on pseudo-random keys. Once a TCP connection has been established with the server, these keys are securely negotiated as part of a \textsl{key exchange} method, the first step of the protocol.  Key exchange begins by the two sides exchanging their preferences for negotiable parameters relating to the actual key exchange algorithm used, as well as encryption, compression and hashing algorithms preferred and supported by either side. Preferences are sent via the \textsc{kexinit} message. Subsequently, key exchange using the negotiated algorithm takes place. Following this algorithm, one-time session keys for encryption and hashing are generated by each side, together with an identifier for the session. Diffie-Hellman is the main key exchange algorithm, and the only one required for support by the RFC. Under the Diffie-Hellman scheme, \textsc{kex30} and \textsc{kex31} are exchanged and new session keys are produced. These keys are used from the moment the \textsc{newkeys} command has been issued by both parties. A subsequent \textsc{sr\_auth} requests the authentication service. The happy flow thus consists of the succession of the three steps comprising key exchange, followed up by a successful authentication service request. The sequence is shown in Figure~\ref{fig:hf-trans}.
30
31

\begin{figure}[!hb]
32
  \includegraphics[scale=0.285]{hf-trans.pdf}
33
  \caption{The happy flow for the transport layer.}
34
  \label{fig:hf-trans}
35
36
\end{figure}

Paul Fiterau Brostean's avatar
Paul Fiterau Brostean committed
37
\textsl{Key re-exchange}~\cite[p. 23]{rfc4253}, or \textsl{rekey}, is a near identical process, with the difference being that instead of taking place at the beginning, it takes place once session keys are already in place. The purpose is to renew session keys so as to foil potential replay attacks~\cite[p. 17]{rfc4251}. It follows the same steps as key exchange. Messages exchanged as part of it are encrypted using the old set of keys, messages exchanged afterward are encrypted using the new keys. A key property of rekey is that it should preserve the state. That is, the state of the protocol before a rekey should be the same as afterward, with the difference that new keys are now in use. %Some implementations are known not support rekey in certain states of the protocol.
38
39
40
41
42

%We consider an transport layer state machine secure if there is no path from the initial state to the point where the authentication service is invoked without exchanging and employing cryptographic keys.


\subsection{Authentication layer}\label{ssh-run-auth} 
Paul Fiterau Brostean's avatar
Paul Fiterau Brostean committed
43
Once the authentication service has been summoned, authentication can commence. To this end, RFC 4252~\cite{rfc4252} defines four authentication methods (password, public-key, host-based and none). The authentication request includes a user name, service name and authentication data, which consists of both the authentication method as well as the data needed to perform the actual authentication, such the password or public key. The happy flow for this layer, as shown in Figure~\ref{fig:hf-auth}, is defined as the sequence that results in a successful authentication. The messages \textsc{ua\_pw\_ok} and \textsc{ua\_pk\_ok} achieve this for respectively password or public key authentication. Figure~\ref{fig:hf-auth} presents the case involving password authentication.
44
45
46
%We consider a user authentication layer state machine secure if there is no path from the unauthenticated state to the authenticated state without providing correct credentials.

\begin{figure}[!ht]
47
  \includegraphics[scale=0.45]{hf-auth.pdf}
48
  \caption{The happy flow for the user authentication layer.}
49
  \label{fig:hf-auth}
50
51
\end{figure}

Paul Fiterau Brostean's avatar
updates    
Paul Fiterau Brostean committed
52
53


54
\subsection{Connection layer}\label{ssh-run-conn} 
Paul Fiterau Brostean's avatar
Paul Fiterau Brostean committed
55
Successful authentication makes services of the Connection layer available. The Connection layer enables the user to open and close channels of different types, with each type providing access to specific services. From the various services available, we focus on the remote terminal over a session channel, a standout feature of SSH. The happy flow involves opening a session channel, \textsc{ch\_open}, requesting a ``pseudo terminal'' \textsc{ch\_request\_pty}, sending and managing data via the messages \textsc{ch\_send\_data}, \textsc{ch\_window\_adjust}, \textsc{ch\_send\_eof}, and eventually closing the channel via \textsc{ch\_close}. Figure~\ref{fig:hf-conn} depicts the common scenario.
56
57
58
59
60
61
62

%Because the connection protocol offers a wide range of functionalities, we it is hard to define a single happy flow. Requesting a terminal is one of the main features of SSH and has therefore been selected as the happy flow. This behaviour is typically triggered by the trace \textsc{ch\_open}; \textsc{ch\_request\_pty}. Other 

%Its hard to define which behaviour would result in a state machine security flaw in this layer. We will therefore take a more general approach and look at unexpected state machine transitions that can point towards potential implementation flaws.

%TODO Perhaps change this figure so to reflect text
\begin{figure}[!ht]
63
  \includegraphics[scale=0.35]{hf-conn.pdf}
64
  \caption{The happy flow for the connection layer.}
65
  \label{fig:hf-conn}
66
\end{figure}