Издаване на OpenSSH 8.9 с елиминиране на уязвимостта в sshd

След шест месеца разработка беше представена версията на 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 "[имейл защитен]" \ -h "scylla.example.org" \ -h "scylla.example.org>[имейл защитен]\ ~/.ssh/id_ed25519
• В ssh и sshd хибриден алгоритъм е добавен по подразбиране към списъка KexAlgorithms, който определя реда, в който се избират методите за обмен на ключове.[имейл защитен]"(ECDH/x25519 + NTRU Prime), устойчив на селекция на квантови компютри. В OpenSSH 8.9 този метод на договаряне беше добавен между методите ECDH и DH, но се планира да бъде активиран по подразбиране в следващото издание.
• ssh-keygen, ssh и ssh-agent са подобрили обработката на FIDO токен ключове, използвани за проверка на устройството, включително ключове за биометрично удостоверяване.
• Добавена е команда "ssh-keygen -Y match-principals" към ssh-keygen за проверка на потребителските имена във файла с разрешен списък с имена.
• 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 използва по-предсказуеми методи за обработка на имена и не използва обработка на обвивката на глобални шаблони в имената на файлове от страната на другия хост, което създава проблеми със сигурността. По-специално, когато се използва SCP и RCP, сървърът решава кои файлове и директории да изпрати на клиента, а клиентът проверява само коректността на върнатите имена на обекти, което при липса на подходящи проверки от страна на клиента позволява на сървър за прехвърляне на други имена на файлове, които се различават от заявените. SFTP протоколът няма тези проблеми, но не поддържа разширяването на специални пътеки като „~/“. За да се справи с тази разлика, предишната версия на OpenSSH въведе ново разширение на SFTP протокол към пътищата ~/ и ~user/ в изпълнението на SFTP сървъра.

Източник: opennet.ru