По шест месеци развој, беше претставено објавувањето на 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, хибридниот алгоритам „sntrup761x25519-sha512@openssh.com“ (ECDH/x25519 + NTRU Prime), отпорен на брутална сила на квантните компјутери, е додаден по дифолт на листата KexAlgorithms, која го одредува редоследот на избор на методи за размена на клучеви. Во 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 го прошири списокот со поддржани параметри (да|не|неврзан|врзан за домаќинот) за да обезбеди можност за избор на наставката на протоколот што ќе се користи.
Во идно издание, се планира алатката scp да се префрли на SFTP по дифолт, заменувајќи го застарениот протокол SCP/RCP. SFTP користи попредвидливи методи за ракување со имиња и го избегнува безбедносното ракување со glob шеми во имињата на датотеките преку школката на другиот хост. Поточно, кога се користат SCP и RCP, серверот одлучува кои датотеки и директориуми да ги испрати до клиентот, додека клиентот ги проверува само вратените имиња на објекти за точност. Ова овозможува нарушувања на безбедноста ако не се извршат соодветни проверки од страната на клиентот. сервер Пренесувајте имиња на датотеки различни од бараните. SFTP протоколот е ослободен од овие проблеми, но не поддржува проширување на специјални патеки како што е „~/“. За да се реши оваа разлика, во претходното издание на OpenSSH на имплементацијата на SFTP серверот беше предложено ново проширување на SFTP протоколот за проширување на патеките ~/ и ~user/.
Извор: opennet.ru
