Efter seks måneders udvikling præsenteres OpenSSH 8.9, den åbne implementering af klient og server til brug med SSH 2.0 og SFTP protokoller. I den nye version af sshd er en sårbarhed blevet lukkede, som potentielt kunne give adgang uden autentificering. Problemet skyldes et heltals-overløb i autentificeringskoden, men udnyttelse er kun mulig i kombination med andre logiske fejl i koden.
I sin nuværende form kan sårbarheden ikke udnyttes, når privilegieadskillelsestilstand er aktiveret, da dens manifestation blokeres af individuelle kontroller udført i koden for privilegieadskillelse. Privilegieadskillelsestilstand blev aktiveret som standard i 2002 med OpenSSH 3.2.2, og er obligatorisk siden udgivelsen af OpenSSH 7.5, der blev offentliggjort i 2017. Desuden i de bærbare versioner af OpenSSH fra og med udgivelsen 6.5 (2014) blokeres sårbarheden ved kompilering med aktivering af flags til beskyttelse mod heltals-overløb.
Andre ændringer:
- I den bærbare version af OpenSSH er den indbygget støtte til hashing af adgangskoder ved hjælp af MD5-algoritmen fjernet (for at genoprette adgang er det tilladt at linke til eksterne biblioteker som libxcrypt).
- I ssh, sshd, ssh-add og ssh-agent er der implementeret et subsystem til at begrænse forwarding og brug af nøgler, der er tilføjet til ssh-agent. Subsystemet gør det muligt at definere regler, der angiver hvordan og hvor nøgler kan bruges i ssh-agent. For eksempel kan følgende kommando bruges til at tilføje en nøgle, der kun må bruges til autentificering, når enhver bruger opretter forbindelse til værten scylla.example.org, bruger perseus til værten cetus.example.org og bruger medea til værten charybdis.example.org med omdirigering gennem den mellemliggende vært 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
- I ssh og sshd er den hybride algoritme „sntrup761x25519-sha512@openssh.com“ (ECDH/x25519 + NTRU Prime), beskyttet mod bruteforce-angreb på kvantecomputere, som standard tilføjet til listen KexAlgorithms, der bestemmer rækkefølgen for valg af nøgleudvekslingsmetoder. I version 8.9 af OpenSSH er denne forhandlingsmetode blevet tilføjet mellem metoderne ECDH og DH, men i den næste udgivelse planlægges det at blive brugt som standard.
- I ssh-keygen, ssh og ssh-agent er håndteringen af FIDO-token nøgler, der bruges til enhedsverifikation, forbedret, herunder nøgler til biometrisk autentificering.
- I ssh-keygen er kommandoen «ssh-keygen -Y match-principals» tilføjet for at kontrollere brugernavne i filen med tilladte navne.
- I ssh-add og ssh-agent er det nu muligt at tilføje PIN-beskyttede FIDO-nøgler til ssh-agent (PIN-anmodningen vises ved autentificering).
- I ssh-keygen er det tilladt at vælge hash-algoritme (sha512 eller sha256) under dannelsen af signaturen.
- I ssh og sshd er netværksdata blevet læst direkte ind i bufferne for modtagne pakker for at forbedre ydeevnen, hvilket omgår den mellemliggende buffering i stakken. Tilsvarende er det implementeret, at de modtagne data direkte placeres i kanalbufferen.
- I ssh er listen over understøttede parametre (yes|no|unbound|host-bound) i direktivet PubkeyAuthentication blevet udvidet for at give mulighed for at vælge den version af den anvendte protokoludvidelse.
I en af de kommende udgivelser planlægges det at ændre standardindstillingen for scp-værktøjet til at bruge SFTP i stedet for det forældede SCP/RCP-protokol. SFTP anvender mere forudsigelige metoder til behandlingen af navne og undgår glob-mønstre i filnavne via shell på den anden vært, hvilket skaber sikkerhedsproblemer. Specifikt, når SCP og RCP anvendes, træffer serveren beslutninger om, hvilke filer og kataloger der skal sendes til klienten, og klienten tjekker kun gyldigheden af de returnerede objektnavne, hvilket i tilfælde af manglende tilstrækkelig kontrol på klientsiden tillader server andre filnavne, der adskiller sig fra de anmodede. SFTP-protokollen har ikke disse problemer, men understøtter ikke expandering af specielle stier som «~/.». For at løse denne forskel har OpenSSH i den tidligere udgave foreslået en ny SFTP-protokoludvidelse til at expandere stierne ~/. og ~user/.
Kilde: opennet.ru
