В начале апреля релизнулся OpenSSH 10.3 и одно из исправлений таково

Устранена проблема с безопасностью в sshd, вызванная некорректным сопоставлением опции authorized_keys principals="" со списком имён (principal) в сертификате в ситуации, когда в именах указан символ ",". Для эксплуатации уязвимости необходимо, чтобы в опции authorized_keys principals="" было указано несколько имён и чтобы удостоверяющий центр выписал сертификат с несколькими именами, разделёнными запятой (обычно такое не допускается). Изменено поведение в отношении сертификатов с пустым именем - ранее пустое имя подпадало под все опции authorized_keys principals="", а теперь не подпадает.

https://www.opennet.ru/opennews/art.shtml?num=65126

Оригинал

https://undeadly.org/cgi?action=article;sid=20260407084719

Но это, как оказалось, не всё и проблема шире.

Вот подробный пост про эту багу (жила с версии OpenSSH 5.6 от 2010 года)

SplitSSHell - When a Comma Becomes Root How a Single Character Broke OpenSSH Certificate Authentication
https://www.cyera.com/research/splitsshell-when-a-comma-becomes-root-how-a-single-character-broke-openssh-certificate-authentication

Уязвимая функция

static int
match_principals_option(const char *principal_list, struct sshkey_cert *cert)
{
...
for (i = 0; i < cert->nprincipals; i++) {
if ((result = match_list(cert->principals[i], ← The Problem
principal_list, NULL)) != NULL) {
debug3("matched principal from key options \"%.100s\"",
result);
...
}

match_list использовался для согласования алгоритмов SSH и туда передаётся список значений разделённый запятыми.

Для обработки principals (разрешённые объекты) вместо strcmp для сравнения строк использовали match_list, что и привело к проблеме.

Если взять строку вида deploy,root, то она должна восприниматься в контексте principals, как единое имя, а запятая просто символ в имени, но из-за использования match_list строка разбивалась на две части и root проходил дальше при первом сравнении, а на следующем шаге валидация просто не происходила

if (sshkey_cert_check_authority_now(key, 0, 0,
keyopts->cert_principals == NULL ? pw->pw_name : NULL,
&reason) != 0)
goto cert_fail_reason;

проверка схлопвалась до sshkey_cert_check_authority_now(key, 0, 0, NULL, &reason), при условии, что установлен параметр principals, а дальше сопоставление пропускается

if (name == NULL)
return 0; /* principal matching not requested */
https://github.com/openssh/openssh-portable-selfhosted/blob/master/sshkey.c#L2436

Почему не подходит ssh-kegen для атаки написано в посте, тут у меня буковы закончились 🌝

PoC
https://github.com/VladimirEliTokarev/SplitSSHell/

Бонусом идёт то, что так как вход валидный получается, то ваш SIEM будет молчать.