Након шест месеци развоја, представљено је издање ОпенССХ 8.9, имплементације отвореног клијента и сервера за рад преко ССХ 2.0 и СФТП протокола. Нова верзија ссхд-а поправља рањивост која би потенцијално могла да дозволи приступ без аутентификације. Проблем је узрокован прекорачењем целог броја у коду за потврду идентитета, али се може искористити само у комбинацији са другим логичким грешкама у коду.
У свом тренутном облику, рањивост се не може искористити када је омогућен режим раздвајања привилегија, пошто је њено испољавање блокирано одвојеним проверама које се врше у коду за праћење раздвајања привилегија. Режим раздвајања привилегија је подразумевано омогућен од 2002. године од ОпенССХ 3.2.2 и обавезан је од објављивања ОпенССХ 7.5 објављеног 2017. године. Поред тога, у преносивим верзијама ОпенССХ-а почевши од издања 6.5 (2014), рањивост је блокирана компилацијом са укључивањем заштитних заставица целобројног преливања.
Остале промене:
- Преносива верзија ОпенССХ-а у ссхд-у је уклонила изворну подршку за хеширање лозинки помоћу МД5 алгоритма (омогућава враћање повезивања са спољним библиотекама као што је либкцрипт).
- ссх, ссхд, ссх-адд и ссх-агент имплементирају подсистем за ограничавање прослеђивања и употребе кључева додатих ссх-агенту. Подсистем вам омогућава да поставите правила која одређују како и где се кључеви могу користити у ссх-агенту. На пример, да бисте додали кључ који се може користити само за аутентификацију било ког корисника који се повезује на хост сцилла.екампле.орг, корисника персеус на хост цетус.екампле.орг и корисника медеа на хост цхарибдис.екампле.орг са преусмеравањем преко средњег хоста сцилла.екампле.орг, можете користити следећу команду: $ ссх-адд -х "[емаил заштићен]" \ -х "сцилла.екампле.орг" \ -х "сцилла.екампле.орг>[емаил заштићен]\ ~/.ссх/ид_ед25519
- У ссх и ссхд, хибридни алгоритам је подразумевано додат на листу КекАлгоритама, који одређује редослед којим се бирају методе размене кључева.[емаил заштићен]"(ЕЦДХ/к25519 + НТРУ Приме), отпоран на селекцију на квантним рачунарима. У ОпенССХ 8.9, овај метод преговарања је додат између ЕЦДХ и ДХ метода, али се планира да буде подразумевано омогућен у следећем издању.
- ссх-кеиген, ссх и ссх-агент имају побољшано руковање кључевима ФИДО токена који се користе за верификацију уређаја, укључујући кључеве за биометријску аутентификацију.
- Додата команда "ссх-кеиген -И матцх-принципалс" у ссх-кеиген да провери корисничка имена у датотеци листе дозвољених имена.
- ссх-адд и ссх-агент пружају могућност додавања ФИДО кључева заштићених ПИН кодом ссх-агенту (захтев за ПИН се приказује у тренутку аутентификације).
- ссх-кеиген омогућава избор алгоритма хеширања (сха512 или сха256) током генерисања потписа.
- У ссх и ссхд, ради побољшања перформанси, мрежни подаци се читају директно у бафер долазних пакета, заобилазећи средње баферовање на стеку. Директно смештање примљених података у бафер канала се реализује на сличан начин.
- У ссх-у, ПубкеиАутхентицатион директива је проширила листу подржаних параметара (да|не|невезано|везано за хост) да би пружила могућност избора проширења протокола за употребу.
У будућем издању планирамо да променимо подразумевану вредност сцп услужног програма да користи СФТП уместо застарелог СЦП/РЦП протокола. СФТП користи предвидљивије методе руковања именима и не користи љуску обраду глоб образаца у именима датотека на страни другог хоста, што ствара безбедносне проблеме. Конкретно, када користи СЦП и РЦП, сервер одлучује које фајлове и директоријуме ће послати клијенту, а клијент само проверава тачност враћених имена објеката, што, у недостатку одговарајућих провера на страни клијента, омогућава сервер за пренос других имена датотека која се разликују од захтеваних. СФТП протокол нема ових проблема, али не подржава проширење посебних путања као што је „~/“. Да би се решила ова разлика, претходно издање ОпенССХ увело је ново проширење СФТП протокола за ~/ и ~усер/ путање у имплементацији СФТП сервера.
Извор: опеннет.ру