>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3592563. --> Reported by: [colan](https://www.drupal.org/user/58704) >>> <h3>Problem/Motivation</h3> <p>Both <code>value</code> and <code>name</code> accept internal control characters (notably <code>\n</code>, <code>\r</code>, <code>\t</code>) at storage time. Any consumer that materializes multiple SSH keys into a single <code>\n</code>-delimited blob (e.g. to build an <code>authorized_keys</code> file) then sees the embedded newline split a single field's content across two lines &mdash; the second of which can be attacker-controlled.</p> <p>Two related paths get to the same vulnerability:</p> <h4>1. <code>name</code> is treated as a free text label, but has no content constraint.</h4> <p><code>SshKeyItem::getConstraints()</code> enforces <code>Length::max = 128</code> on <code>name</code> but nothing about what characters it may contain. The default <code>sshkey_textarea</code> widget renders <code>name</code> as an <code>&amp;lt;input type="textfield"&amp;gt;</code>, so a browser user can't easily enter a newline &mdash; but JSON:API, REST, migration, and programmatic <code>setValue()</code> all bypass that. A <code>name</code> of <code>"laptop\nssh-ed25519 AAA&hellip; backdoor@host"</code> stored via any of those paths flows through a downstream consumer's <code>"&amp;lt;alg&amp;gt; &amp;lt;key&amp;gt; &amp;lt;name&amp;gt;"</code>-style rebuild and becomes two lines in <code>authorized_keys</code>, the second of which is a fully attacker-supplied SSH entry.</p> <h4>2. <code>value</code>'s comment portion accepts internal control chars even when the key portion doesn't.</h4> <p>The constraint validator does <code>base64_decode($key, TRUE)</code> in strict mode, which rejects <code>\n</code> / <code>\r</code> / <code>\t</code> inside the base64-encoded key bytes. But <code>Utils::initialize()</code> parses with <code>explode(' ', $value, 3)</code>, so everything after the second space is the comment &mdash; including any embedded newline. Validation passes (algorithm OK, key OK, structure OK, phpseclib loads it), and then <code>onChange()</code> derives <code>name</code> from the dirty comment via <code>Utils::getComment()</code>. The result is the same injection vector as path (1), now via a single field on the value side.</p> <p>Issue <a href="https://www.drupal.org/project/sshkey/issues/3592555">#3592555</a> (already in 4.x) trims leading/trailing whitespace from <code>value</code>; this issue is about <em>internal</em> control characters in both <code>value</code> and <code>name</code>.</p> <h3>Steps to reproduce</h3> <ol> <li>Apply a sshkey field to a fieldable entity.</li> <li>Via JSON:API (or any programmatic save path), set the field with: <ul> <li><code>value</code>: a valid SSH key &mdash; e.g. <code>"ssh-ed25519 AAAA&hellip; legit@host"</code>.</li> <li><code>name</code>: <code>"laptop\nssh-ed25519 BBBB&hellip; attacker@host"</code> (containing a literal newline).</li> </ul> </li> <li>Save. The entity validates and persists because the only <code>name</code> constraint is length.</li> <li>Build an <code>authorized_keys</code> blob from this and any other sshkey entries with <code>implode("\n", &hellip;)</code> (or hand the multi-key string to <code>ansible.posix.authorized_key</code>): the attacker line lands in the file as a separate authorized entry.</li> </ol> <p>Alternative reproduction via the value path: store <code>value = "ssh-ed25519 AAAA&hellip; legit-comment\nssh-ed25519 BBBB&hellip; attacker"</code> and leave <code>name</code> unset. Validation passes (the key portion is clean base64), and <code>onChange()</code> derives <code>name</code> from <code>Utils::getComment()</code>, which contains the embedded newline.</p> <h3>Proposed resolution</h3> <p>Normalize on write in <code>SshKeyItem::onChange()</code>:</p> <ul> <li><strong><code>value</code> branch:</strong> after the existing trim, replace any internal <code>\r</code> / <code>\n</code> / <code>\t</code> with a single space. Regular spaces are preserved so legitimate comments survive (e.g. <code>"Colan's mobile laptop"</code>). Write the normalized value back via <code>writePropertyValue()</code> before fingerprint/name derivation, so derived properties see the clean string.</li> <li><strong><code>name</code> branch (new):</strong> when <code>name</code> is set (explicitly or via the value-derived path), collapse any whitespace run to a single space and trim. <code>name</code> is a short single-line label; internal newlines or tabs are never meaningful here.</li> </ul> <p>This is defense-in-depth alongside the existing constraint validator &mdash; validation still runs and still rejects malformed keys; normalization just guarantees that whatever gets stored is downstream-safe regardless of entry point (widget, JSON:API, REST, migration, programmatic <code>setValue</code>).</p> <h3>Remaining tasks</h3> <ul> <li>Normalize internal control chars in <code>value</code> in <code>onChange()</code>.</li> <li>Normalize <code>name</code> in <code>onChange()</code> (both the explicitly-set and value-derived paths).</li> <li>Kernel-test coverage for both paths, plus a regression test using the injection payload from the reproduction.</li> <li>Maintainer review.</li> <li>Tag a release (the same release that ships <a href="https://www.drupal.org/project/sshkey/issues/3592555">#3592555</a>).</li> </ul> <h3>API changes</h3> <p>None. <code>value</code> and <code>name</code> are still strings; they just no longer carry internal control characters.</p> <h3>Data model changes</h3> <p>None at the schema level. Existing rows with bad internal whitespace will normalize on their next save. A <code>hook_update_N()</code> sweep is possible but probably not warranted &mdash; the bug only manifests when a downstream consumer is doing newline-joining, and any such consumer should be doing its own defensive sanitization too.</p>