Hat hónapos fejlesztés után bemutatták az OpenSSH 8.9 kiadását, amely egy nyílt kliens és szerver implementáció az SSH 2.0 és SFTP protokollokon keresztül történő munkavégzéshez. Az sshd új verziója javít egy biztonsági rést, amely potenciálisan hitelesítetlen hozzáférést tesz lehetővé. A problémát a hitelesítési kód egész szám túlcsordulása okozza, de csak a kód egyéb logikai hibáival kombinálva lehet kihasználni.
A sérülékenység jelenlegi formájában nem aknázható ki, ha a jogosultság-elválasztási mód engedélyezve van, mivel a megnyilvánulást a jogosultság-elválasztási követőkódban végrehajtott külön ellenőrzések blokkolják. A privilégium-elválasztási mód alapértelmezés szerint 2002 óta engedélyezve van az OpenSSH 3.2.2 óta, és az OpenSSH 7.5 2017-es kiadása óta kötelező. Ezenkívül az OpenSSH 6.5-ös (2014) kiadással kezdődő hordozható verzióiban a biztonsági rést az egész számok túlcsordulás elleni védelmi jelzőivel történő fordítása blokkolja.
Egyéb változások:
- Az OpenSSH hordozható verziója az sshd-ben eltávolította a jelszavak MD5 algoritmussal történő kivonatolásának natív támogatását (lehetővé teszi a külső könyvtárakhoz, például a libxcrypthez való hivatkozás visszatérését).
- Az ssh, sshd, ssh-add és ssh-agent alrendszert valósít meg az ssh-agenthez hozzáadott kulcsok továbbításának és használatának korlátozására. Az alrendszer lehetővé teszi olyan szabályok beállítását, amelyek meghatározzák, hogyan és hol használhatók a kulcsok az ssh-agentben. Például egy olyan kulcs hozzáadásához, amely csak a scylla.example.org gazdagéphez csatlakozó felhasználók hitelesítésére használható, a felhasználó perseus a cetus.example.org gazdagéphez, a medea felhasználó pedig a charybdis.example.org gazdagéphez a scylla.example.org köztes gazdagépen keresztül történő átirányítással a következő parancsot használhatja: $ ssh-add -h "[e-mail védett]" \ -h "scylla.example.org" \ -h "scylla.example.org>[e-mail védett]\ ~/.ssh/id_ed25519
- Az ssh-ban és az sshd-ben alapértelmezés szerint egy hibrid algoritmus került a KexAlgorithms listába, amely meghatározza a kulcscsere-módszerek kiválasztásának sorrendjét.[e-mail védett]"(ECDH/x25519 + NTRU Prime), ellenáll a kvantumszámítógépek kiválasztásának. Az OpenSSH 8.9-ben ez az egyeztetési módszer bekerült az ECDH és a DH metódusok közé, de a tervek szerint a következő kiadásban alapértelmezés szerint engedélyezni fogják.
- Az ssh-keygen, az ssh és az ssh-agent javította az eszközellenőrzéshez használt FIDO token kulcsok kezelését, beleértve a biometrikus hitelesítéshez használt kulcsokat is.
- Hozzáadtuk az "ssh-keygen -Y match-principals" parancsot az ssh-keygenhez, hogy a felhasználóneveket összevethessük az engedélyezettnév listafájllal.
- Az ssh-add és az ssh-agent lehetővé teszik PIN-kóddal védett FIDO-kulcsok hozzáadását az ssh-agenthez (a PIN-kérés a hitelesítéskor jelenik meg).
- Az ssh-keygen lehetővé teszi a kivonatolási algoritmus (sha512 vagy sha256) kiválasztását az aláírás generálása során.
- Az ssh-ben és az sshd-ben a teljesítmény javítása érdekében a hálózati adatok közvetlenül a bejövő csomagok pufferébe kerülnek beolvasásra, megkerülve a verem közbenső puffereit. Hasonló módon valósul meg a vett adatok közvetlen elhelyezése a csatornapufferben.
- Az ssh-ban a PubkeyAuthentication direktíva kibővítette a támogatott paraméterek listáját (yes|no|unbound|host-bound), hogy lehetővé tegye a használni kívánt protokollbővítmény kiválasztását.
Egy jövőbeli kiadásban az scp segédprogram alapértelmezett beállítását úgy tervezzük, hogy az SFTP-t használjon a régi SCP/RCP protokoll helyett. Az SFTP kiszámíthatóbb névkezelési módszereket használ, és nem használja a glob-minták shell-feldolgozását a fájlnevekben a másik gazdagép oldalán, ami biztonsági problémákat okoz. Különösen az SCP és RCP használatakor a szerver dönti el, hogy mely fájlokat és könyvtárakat küldje el a kliensnek, a kliens pedig csak a visszaadott objektumnevek helyességét ellenőrzi, ami megfelelő kliensoldali ellenőrzések hiányában lehetővé teszi a szerverre a kértektől eltérő fájlnevek átviteléhez. Az SFTP protokoll nem rendelkezik ilyen problémákkal, de nem támogatja a speciális útvonalak, például a „~/” kiterjesztését. Ennek a különbségnek a megoldására az SFTP protokoll új kiterjesztését javasolták az OpenSSH előző kiadásában az SFTP-kiszolgáló megvalósításában a ~/ és ~user/ elérési utak kiterjesztésére.
Forrás: opennet.ru