Устранена проблема с безопасностью в 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 будет молчать.
