Hardened OpenSSH Server

The baseline privilege-separated OpenSSH server uses chroot and setuid system calls to restrict unprivileged compartments. As discussed in Section 2.1, the chroot jail restricts file system access, and the setuid jail prevents a process from tampering with user processes. However, more fine-grained

Figure 4.21: Partitioning of the Hardened OpenSSH Server.

control over a process’s privilege is required to restrict dangerous system calls. For example, ptrace system call can be used by an unprivileged process to control and read address space of another unpriv- ileged process that handles a session of a legitimate user. Thus, an attacker may establish a connection with a server and compromise the server’s unprivileged process, Figure 2.1. Then, by ptracing other unprivileged processes that handle concurrent sessions of legitimate users, the attacker may discloses passwords and computed session keys of the users. Apart from this attack, the baseline implementation of the OpenSSH server is vulnerable to the session key disclosure attack and oracle attacks, Section 4.2. In particular, the baseline server exposes the signing oracle, signature verification oracle, and determin- istic session key oracle.

Figure 4.21 shows our hardened OpenSSH server that implements our protocol partitioning rules. We split an unprivileged process in the baseline OpenSSH server, Figure 2.1, into two compartments one to act as an unprivileged compartment in the session key negotiation stage, and another to form the pre-authenticated stage, Principle 2. The session key negotiation stage has no access to a session key or any sensitive information that allows deriving the session key as required by Principle 1.

The monitor process in the baseline OpenSSH server is split into two privileged compartments: a per-connection session monitor that isolates sensitive data crucial for integrity of a current session and exports operations on this data, and a per-connection private key monitor that isolates the server’s private key responsible for integrity of many SSH sessions and performs operations that require root privilege. Principle 10 motivates this division. Note that the session monitor does not require access to file system and root privilege to perform its tasks, it only isolates sensitive data produced at session key negotiation; therefore, it is confined with the same restrictions as the unprivileged processes (setuid jail, chroot jail, SELinux policy). In addition, the session monitor scrubs sensitive session key material, the server’s private DH component, after computing the session key as required by Principle 4.

In our hardened implementations of the OpenSSH server and client, we employ SELinux poli- cies [98] to tighten system call privilege of compartments. Thus, unprivileged processes of the session

Session monitor

1 server DH private key = generate DH private key()

2 server DH public key = compute DH public key(server DH private key) 3 session key = compute session key(server DH private key,

client DH public key)

4 session IDi = compute session ID(session key, server version,

client version, server kexinit, client kexinit, ...)

5 symmetric keys = derive symmetric keys(session IDi, session key)

Private key monitor

1 signature = sign(server private key, session IDi, user name,

service, auth mode, ...)

2 client public keyi = verify public key(client public key, username,

user authorized keys)

3 verify signature(session IDi, client public keyi, signature) 4 verify password(username, password)

Sensitive data appear in bold, and are accessible only by the corresponding monitor. Untrusted parameters provided by unprivileged compartments are not in bold. xidenotes that sensitive data x is exported to an unprivileged compartment read-only.

Figure 4.22: Privileged Operations Implemented by the Session Monitor and Private Key Monitor in the OpenSSH Server.

key negotiation and pre-authentication stages as well as the session monitor are chrooted, setuid-jailed, and confined with a restrictive SELinux policy that only allows system calls implied by Figure 4.21.

Session Key Negotiation Stage

The session monitor implements privileged operations required to safely establish a session key as well as to prevent the signing and the signature verification oracles exposed by the baseline implementation. Figure 4.22 lists the operations implemented by the session monitor. server DH private key is a private DH component which can be used to derive the session key. This component is random and generated for every new session; thus, it plays a role of a server random nonce. The session monitor isolates the private DH component, Principle 1. The session key is produced from the server’s private DH component and a client’s public DH component (nonsensitive data supplied by the session key negotiation compartment). After computing a session key, the session monitor scrubs private DH component from its memory to comply with Principle 4.

In the session key negotiation stage, a server must authenticate itself to the client by signing a ses- sion ID. We prevent a signing oracle by ensuring that the data signed by the server incorporates a server random nonce, Principle 7, which is the private DH component. Operations 1, 3, and 4 in Figure 4.22 performed by the privileged session monitor guarantee that the session ID is entangled with per-session randomness, and the session monitor supplies a trusted copy of the session ID to the private key mon- itor for signing, Operation 1 in Figure 4.22. Thus, an attacker cannot exploit the signing operation as whatever she signs contains a fresh private DH component and cannot be used within any other session but her own. derive symmetric keys produces two pairs of symmetric keys: one for outbound encryption and MAC, and the other for inbound decryption and MAC.

After computing a session key and server authentication, we enable the session key barrier, Prin- ciple 2, by enforcing MAC on the channel and killing the unprivileged compartment of the session key

negotiation stage, Figure 4.21.

Pre-authentication and Post-authentication Stages

The pre-authentication stage performs user authentication; depending on an authentication method, it may involve privileged operations such as password checking, verification of a user’s public key, and verification of a signature on a session ID, Figure 4.22. The baseline OpenSSH server isolates these op- erations within its monitor process running as root because the operations require access to sensitive data or root privilege. Our hardened implementation inherits this model; however, we eliminate the signature verification oracle exposed by the baseline OpenSSH server. The signature verification operation ver- ify signature, Figure 4.22, is used to verify a client’s signature when the client authenticates to the server. There are three arguments to this operation where the signature is supplied by an untrusted source. If an attacker controls one of the other arguments, session ID or client public key, then she can bypass the signature verification procedure. Controlling the client private key allows an attacker to supply her own public key and a signature produced with her key over a benign session ID. If the session ID is under attackers control, which is the case in the baseline OpenSSH server, the attacker can replay a session ID and the corresponding signature from a previous user session. However, this pair of data is transfered within an encrypted channel, and it is unlikely that the user will wish to grant it to the attacker. Because the baseline OpenSSH server does not provide protection against the SKD attack, one can use this attack to penetrate the encrypted channel and disclose the session ID and the corresponding signature. Our implementation of the OpenSSH server thwarts SKD attacks, thus it is not possible to obtain required pair of authentication data. Moreover, it prevents an SKD attacker from disclosing user passwords if the password authentication is used where the baseline OpenSSH lacks this guarantee.

Despite the SKD defenses, we also eliminate the signature verification oracle. First, an attacker does not control the client’s public key. It is initially supplied by an unprivileged compartment, but after public key validation against the user’s authorized keys file, verify client public key in Figure 4.22, the monitor keeps its own copy of the public key which is used in signature verification. The baseline OpenSSH server implements this mechanism. Unlike the baseline OpenSSH server, we apply our Principle 7 and make sure that the data used in signature verification is entangled with the server per-session randomness. The sequence of privileged operations in the session monitor ensures the presence of the server’s private DH component (per-session randomness) in the session ID. The private DH component prevents both the signing oracle and the signature verification oracle. The session monitor provides trusted, entangled session ID for the signature verification operation. Thus, an attacker has no means to replay signature as the session ID is generated afresh for every session.

Discussion: Privileged Code Base

Figure 4.23 presents comparison between Privileged Code Bases (PCB) of the baseline OpenSSH server and our hardened implementation of the OpenSSH server. The latter extends the partitioning of the base- line implementation with an additional unprivileged compartment for the session key negotiation stage motivated by Principle 1 and Principle 2, and with the privileged session key monitor, Principle 10. The session monitor implements operations that provide oracle and SKD defenses, Principle 2 and Princi-

Privileged code is shaded; unprivileged code is unshaded.

Figure 4.23: Relationship Between Privileged and Unprivileged Code in the Baseline and Hardened OpenSSH Servers.

ple 7. In the baseline OpenSSH server, these operations are performed in the unprivileged process. At first glans, one might notice that we increased the PCB with our session monitor, but this as- sumption is flawed. Rather the session key data, which integrity and confidentiality are crucial for the SKD and oracle defenses, was mislabeled as nonsensitive and allowed to be manipulated by unprivileged code in the baseline OpenSSH server. Thus, the unprivileged process of the baseline implementation be- comes privileged code with respect to the session key data, and we relabel it as privileged, shaded. It is clear that our hardened implementation reduces the PCB by correctly identifying the sensitive data and factoring out the code that truly requires no access to the sensitive data.