След пет месеца разработка бе представена версия OpenSSH 8.5, отворената реализация на клиент и сървър за работа по протоколите SSH 2.0 и SFTP.
Разработчиците на OpenSSH напомниха за предстоящото прехвърляне в категорията на остарелите алгоритми, които използват хешове SHA-1, поради повишаване на ефективността на атаките с колизии с зададен префикс (разходите за генериране на колизия се оценяват на около 50 хиляди долара). В едно от близките издания планират по подразбиране да се деактивира възможността за използване на алгоритма за цифрови подписи с отворен ключ „ssh-rsa“, който се споменава в оригиналния RFC за протокола SSH и остава широко разпространен на практика.
За проверка на прилагането на ssh-rsa в своите системи можете да опитате да се свържете по ssh с опцията „-oHostKeyAlgorithms=-ssh-rsa“. При това изключването на цифровите подписи „ssh-rsa“ по подразбиране не означава пълен отказ от използването на RSA ключове, тъй като освен SHA-1 протоколът SSH допуска използването на други алгоритми за хеширане. В частност, освен „ssh-rsa“ остава възможността за използване на двойки „rsa-sha2-256“ (RSA/SHA256) и „rsa-sha2-512“ (RSA/SHA512).
За плавен преход към новите алгоритми в OpenSSH 8.5 по подразбиране е активирана настройката UpdateHostKeys, която позволява автоматичен преход на клиентите към по-надеждни алгоритми. С активирането на тази настройка се включва специално разширение на протокола „hostkeys@openssh.com“, което позволява на сървъра след успешна аутентификация да информира клиента за всички налични ключове на хоста. Клиентът може да отрази тези ключове в своя файл ~/.ssh/known_hosts, което позволява организиране на обновление на ключовете на хоста и улеснява смяната на ключовете на сървър.
Използването на UpdateHostKeys е ограничено до няколко условия, които в бъдеще могат да бъдат отменени: ключът трябва да фигурира в UserKnownHostsFile и не трябва да се използва в GlobalKnownHostsFile; ключът трябва да е наличен само под едно име; не може да се използва сертификат на хостовия ключ; в known_hosts не трябва да се използват маски по името на хоста; настройката VerifyHostKeyDNS трябва да е изключена; параметърът UserKnownHostsFile трябва да е активен.
Сред препоръчаните алгоритми за миграция са rsa-sha2-256/512 на базата на RFC8332 RSA SHA-2 (поддържа се от OpenSSH 7.2 и се използва по подразбиране), ssh-ed25519 (поддържа се от OpenSSH 6.5) и ecdsa-sha2-nistp256/384/521 на базата на RFC5656 ECDSA (поддържа се от OpenSSH 5.7).
Други промени:
- Промени, свързани с безопасността:
- В ssh-agent е отстранена уязвимост, предизвикана от повторно освобождаване на вече освободена памет (double-free). Проблемът се проявява от версия OpenSSH 8.2 и потенциално може да бъде експлоатиран при наличие на достъп на нападателя до сокета ssh-agent на локалната система. Експлоатацията е затруднена от факта, че достъп до сокета имат само root и оригиналният потребител. Най-вероятният сценарий на атака е пренасочване на агента към акаунт, който е под контрола на злоумышленика, или към хост, на който злоумышленикът има root-достъп.
- В sshd е добавена защита срещу предаване на много големи параметри с име на потребител в подсистемата PAM, което позволява блокиране на уязвимости в системните модули PAM (Pluggable Authentication Module). Например, промяната позволява да се предотврати използването на sshd като вектор за експлоатация на наскоро откритата уязвимост с root в Solaris (CVE-2020-14871).
- Промени, които потенциално нарушават съвместимостта:
- В ssh и sshd е въведен експериментален метод за обмен на ключове, устойчив на атаки от квантови компютри. Квантовите компютри решават задачата за разлагане на натурално число на прости множители, която е основата на съвременните асиметрични алгоритми за криптиране и е трудна за решаване на класически процесори. Използваният метод се основава на алгоритъма NTRU Prime, разработен за постквантови криптосистеми, и метод за обмен на ключове на база на елиптични криви X25519. Вместо sntrup4591761x25519-sha512@tinyssh.org, методът вече се идентифицира като sntrup761x25519-sha512@openssh.com (алгоритъмът sntrup4591761 е заменен с sntrup761).
- В ssh и sshd е променен редът на анонсиране на поддържаните алгоритми за цифрови подписи. Сега първият предложен е ED25519 вместо ECDSA.
- В ssh и sshd задаването на параметрите за качество на услугата TOS/DSCP за интерактивни сесии вече се извършва преди установяването на TCP връзка.
- В ssh и sshd е спряна поддръжката на шифъра rijndael-cbc@lysator.liu.se, който е идентичен на aes256-cbc и е използван до одобрението на RFC-4253.
- По подразбиране параметърът CheckHostIP е деактивиран, ползата от който е незначителна, но използването му значително усложнява ротацията на ключовете за хостове зад балансировачи на натоварването.
- В sshd са добавени настройките PerSourceMaxStartups и PerSourceNetBlockSize за ограничаване на интензивността на стартиране на обработвачи, привързани към адреса на клиента. Тези параметри позволяват по-фин контрол на ограниченията за стартиране на процеси, в сравнение с общата настройка MaxStartups.
- В ssh и sshd е добавена нова настройка LogVerbose, позволяваща принудително увеличаване на нивото на дебъг информация в логовете, с възможност за филтриране по шаблони, функции и файлове.
- В ssh, при приемане на нов хостов ключ, се показват всички имена на хостове и IP адреси, асоциирани с ключа.
- В ssh е разрешено задаването на опцията UserKnownHostsFile=none за деактивиране на използването на файла known_hosts при идентифициране на хостовите ключове.
- В ssh_config за ssh е добавена настройка KnownHostsCommand, позволяваща получаването на данни от known_hosts от изхода на указаната команда.
- В ssh_config за ssh е добавена опция PermitRemoteOpen, позволяваща ограничаване на целта при използване на опцията RemoteForward с SOCKS.
- В ssh за ключове FIDO е осигурено повторно изискване на PIN код в случай на неуспех на операцията с цифровия подпис поради неправилен PIN и липса на запитване за PIN от потребителя (например, когато не са получени коректни биометрични данни и устройството е преминало на ръчно въвеждане на PIN).
- В sshd е добавена поддръжка на допълнителни системни повиквания в механизма за изолация на процеси, основаващ се на seccomp-bpf на платформата Linux.
- Актуализирана е утилитата contrib/ssh-copy-id.
Източник: opennet.ru
