Password authentication leaves plaintext password copies in managed memory

[tkopeee96]

Description

SSH.NET password authentication appears to leave plaintext password data
in managed memory after authentication has completed.

This was discovered during a penetration test by inspecting a process memory
dump after establishing an SSH connection using password authentication.

There appear to be at least two sources of password residue.

---

PasswordAuthenticationMethod retains the password

PasswordAuthenticationMethod stores the supplied password internally as a
byte array.

When the string-based API is used, the password must additionally exist as a
System.String. Since System.String is immutable, that copy cannot be
explicitly cleared.

The internal byte[] containing the encoded password also appears to remain
allocated after authentication instead of being zeroed when it is no longer
required.

As a result, the plaintext password can remain recoverable from a process
memory dump after authentication.

---

Serialized SSH_MSG_USERAUTH_REQUEST remains in memory

Using the byte[] password overload reduces the problem because the caller can
clear its own password buffer.

However, this does not eliminate all plaintext copies.

During password authentication the password is serialized into the
SSH_MSG_USERAUTH_REQUEST message.

The relevant flow appears to be approximately:

PasswordAuthenticationMethod.Authenticate
-> Session.SendMessage(RequestMessagePassword)
-> message serialization
-> Session.SendPacket(...)

The serialized packet contains the password in plaintext before SSH transport
encryption is applied.

After the packet has been encrypted/sent, buffers containing the plaintext
packet do not appear to be explicitly zeroed.

In a process memory dump taken after authentication, we were able to locate a
complete plaintext SSH user authentication request containing the password.

---

Expected behavior

Sensitive authentication data should have the shortest practical lifetime in
memory.

After password authentication has completed, SSH.NET should explicitly clear
buffers that contain:

• the password stored by PasswordAuthenticationMethod;
• temporary encoded password representations;
• serialized SSH_MSG_USERAUTH_REQUEST payloads containing a password;
• temporary packet/plaintext buffers used before encryption.

For byte arrays/spans this could potentially use Array.Clear,
CryptographicOperations.ZeroMemory, or an equivalent mechanism appropriate
for the supported target frameworks.

The goal is not to guarantee that a password can never exist in plaintext
memory. Password authentication necessarily requires SSH.NET to process the
plaintext password.

The goal is to avoid leaving unnecessary plaintext copies recoverable from a
memory dump after those buffers are no longer required.

---

Why the byte[] overload alone does not solve this

Applications can avoid keeping a managed System.String by obtaining the
credential through a protected representation and creating a temporary byte[]
for SSH.NET.

The application can zero its own byte[] immediately afterwards.

However, once SSH.NET serializes SSH_MSG_USERAUTH_REQUEST, additional
plaintext copies are created internally. Those copies are outside the
caller's control and therefore cannot be cleared by the application.

Consequently this cannot be fully mitigated by callers of SSH.NET.

---

Security impact

An attacker or diagnostic process capable of obtaining a process memory dump
after SSH authentication may be able to recover the SSH password even though
authentication has already completed.

This is particularly relevant for long-running applications where SSH
connections are created periodically and credentials should not remain
recoverable for the lifetime of the process.

---

Environment

Observed with password authentication using Renci.SshNet / SSH.NET.

The same behavior should be reproducible by:

1. Connect to an SSH server using password authentication.
2. Allow authentication to complete.
3. Disconnect and dispose the SSH client.
4. Force GC if desired.
5. Capture a process memory dump.
6. Inspect the dump for the known test password.

A unique test password can be used to make identification unambiguous.

---

Possible direction

A complete fix probably requires handling this at more than one level.

1. Avoid unnecessary conversion of password credentials to System.String.
2. Clear PasswordAuthenticationMethod password storage when it is no longer
   required.
3. Clear credential-containing RequestMessagePassword storage when
   authentication completes.
4. Clear plaintext serialization/packet buffers after they have been
   encrypted or are otherwise no longer needed.
5. Add regression tests verifying that sensitive buffers are zeroed after
   use where practical.