След шест месеца разработка беше представена версия OpenSSH 8.9, отворена реализация на клиент и сървър за работа с протоколите SSH 2.0 и SFTP. В новата версия е отстранена уязвимост в sshd, която потенциално позволява достъп без автентикация. Проблемът е причинен от препълване на цяло число в кода за автентикация, но експлоатацията е възможна само в комбинация с други логически грешки в кода.
В текущия си вид уязвимостта не е експлоатирана при включен режим на разделяне на привилегиите, тъй като проявлението й е блокирано от отделни проверки, извършвани в кода за проследяване на разделяне на привилегиите. Режимът на разделяне на привилегиите е активиран по подразбиране през 2002 година, от OpenSSH 3.2.2, и е задължителен от версия OpenSSH 7.5, публикувана през 2017 година. Освен това, в преносимите версии на OpenSSH от версия 6.5 (2014 година) уязвимостта е блокирана при компилиране с включване на флаговете за защита от препълване на цели числа.
Други промени:
- В преносимата версия на OpenSSH в sshd е премахната вградената поддръжка за хеширане на пароли с алгоритъма MD5 (за възстановяване е разрешено свързването с външни библиотеки, като libxcrypt).
- В ssh, sshd, ssh-add и ssh-agent е реализирана подсистема за ограничаване на преносимостта и използването на ключове, добавени в ssh-agent. Подсистемата позволява задаване на правила, определящи как и къде могат да се използват ключове в ssh-agent. Например, за добавяне на ключ, който може да се използва само за провеждане на автентикация при свързване на всеки потребител към хост scylla.example.org, на потребителя perseus към хост cetus.example.org и на потребителя medea към хост charybdis.example.org с пренасочване през междинния хост scylla.example.org, може да се използва следната команда: $ ssh-add -h "perseus@cetus.example.org" \ -h "scylla.example.org" \ -h "scylla.example.org>medea@charybdis.example.org" \ ~\/ .ssh\/id_ed25519
- В ssh и sshd в списъка KexAlgorithms, който определя реда на избор на методи за обмен на ключове, по подразбиране е добавен хибриден алгоритъм "sntrup761x25519-sha512@openssh.com" (ECDH/x25519 + NTRU Prime), устойчив на факултативно подбиране на квантови компютри. В версия OpenSSH 8.9 този метод на съгласуване е добавен между методите ECDH и DH, но в следващата версия се планира да бъде включен по подразбиране.
- В ssh-keygen, ssh и ssh-agent е подобрена обработката на ключове за FIDO токени, използвани за верификация на устройството, включително ключове за биометрична аутентификация.
- В ssh-keygen е добавена команда „ssh-keygen -Y match-principals“ за проверка на имената на потребители в файл със списък на разрешените имена.
- В ssh-add и ssh-agent е предоставена възможност за добавяне на FIDO ключове, защитени с PIN код, в ssh-agent (заявката за PIN се показва по време на аутентикация).
- В ssh-keygen е разрешен избор на алгоритъм за хеширане (sha512 или sha256) по време на създаване на подпис.
- В ssh и sshd за повишаване на производителността е осигурено четене на мрежови данни директно в буфера на входящите пакети, заобикаляйки междинната буферизация в стека. Аналогично е реализирано директното поставяне на получените данни в канален буфер.
- В ssh в директивата PubkeyAuthentication е разширен списъка на поддържаните параметри (yes|no|unbound|host-bound) за предоставяне на възможност за избор на варианта на използваното разширение на протокола.
В едно от следващите издания е планирано по подразбиране да се прехвърли утилитата scp на използването на SFTP вместо остарелия протокол SCP/RCP. В SFTP се прилагат по-предсказуеми методи за обработка на имената и не се използва обработка на glob шаблони в имена на файлове чрез shell от друг хост, което създава проблеми със сигурността. В частност, при прилагане на SCP и RCP, сървърът решава какви файлове и директории да изпрати на клиента, а клиентът само проверява коректността на върнатите имена на обектите, което в случая на липса на адекватни проверки от страната на клиента позволява сървъра да бъдат предадени други имена на файлове, различни от заявените. Протоколът SFTP е лишен от посочените проблеми, но не поддържа разкриването на специални пътища, като „~/“. За да се отстрани това различие, в предишното издание на OpenSSH беше предложено ново разширение на протокола SFTP за разкриване на пътища ~ / и ~user /.
Източник: opennet.ru
