Release av OpenSSH 8.9 med åtgärd för sårbarhet i sshd

Efter sex månaders utveckling har OpenSSH 8.9, en öppen implementation av klient och server för att arbeta med SSH 2.0 och SFTP-protokollen, släppts. I den nya versionen har en sårbarhet i sshd åtgärdats, vilket potentiellt skulle kunna ge access utan autentisering. Problemet orsakas av ett heltalsoverflows i autentiseringskoden, men utnyttjande är endast möjligt i kombination med andra logiska fel i koden.

I sin nuvarande form är sårbarheten inte utnyttjbar när privilegiedelning är aktiverat, eftersom dess manifestation blockeras av separata kontroller som utförs i koden för privilegiedelning. Privilegiedelningsläget aktiverades som standard 2002, med OpenSSH 3.2.2, och har varit obligatoriskt sedan lanseringen av OpenSSH 7.5, som publicerades 2017. Dessutom blockeras sårbarheten i bärbara versioner av OpenSSH som börjar med version 6.5 (2014) genom kompilering med inkluderade flaggor för skydd mot heltalsoverflows.

Andra förändringar:

• I den bärbara versionen av OpenSSH har inbyggt stöd för hashning av lösenord med hjälp av MD5-algoritmen tagits bort (koppling till externa bibliotek, såsom libxcrypt, är tillåten för åtkomst).
• I ssh, sshd, ssh-add och ssh-agent har ett subsystem implementerats för att begränsa vidarebefordran och användning av nycklar som har lagts till i ssh-agent. Subsystemet möjliggör att ange regler som definierar hur och var nycklarna kan användas i ssh-agent. Till exempel, för att lägga till en nyckel som endast kan användas för autentisering när vilken användare som helst kopplar upp sig mot värden scylla.example.org, användaren perseus mot värden cetus.example.org och användaren medea mot värden charybdis.example.org med omdirigering via den mellanliggande värden scylla.example.org, kan följande kommando användas: $ ssh-add -h "perseus@cetus.example.org" \ -h "scylla.example.org" \ -h "scylla.example.org>medea@charybdis.example.org" \ ~\/ .ssh\/id_ed25519
• I ssh och sshd har den hybridalgoritmen "sntrup761x25519-sha512@openssh.com" (ECDH/x25519 + NTRU Prime), som är motståndskraftig mot brute-force-attacker på kvantdatorer, lagts till som standard i KexAlgorithms-listan, vilken definierar metoderna för val av nyckelbytesalgoritmer. I version 8.9 av OpenSSH har denna samordningsmetod lagts till mellan ECDH och DH-metoderna, men i nästa version planeras den att användas som standard.
• I ssh-keygen, ssh och ssh-agent har hanteringen av FIDO-tokennycklar förbättrats, vilket används för enhetsverifikation, inklusive nycklar för biometrisk autentisering.
• I ssh-keygen har kommandot «ssh-keygen -Y match-principals» lagts till för att verifiera användarnamn i filen med godkända namn.
• I ssh-add och ssh-agent har möjligheten att lägga till PIN-skyddade FIDO-nycklar i ssh-agenten införts (PIN-begäran visas vid autentisering).
• I ssh-keygen tillåts valet av hash-algoritm (sha512 eller sha256) under signering.
• I ssh och sshd läses nätverksdata direkt till bufferten för inkommande paket för att öka prestandan, vilket omgår mellanliggande buffring i stacken. På liknande sätt implementerades direkt insättning av mottagna data i kanalbufferten.
• I ssh har direktivet PubkeyAuthentication utvidgats med en lista över stödda parametrar (yes|no|unbound|host-bound) för att ge möjlighet att välja vilken variant av det använda protokollet som ska användas.

I en av kommande versioner planeras det att som standard överföra verktyget scp till användning av SFTP istället för det föråldrade protokollet SCP/RCP. SFTP använder mer förutsägbara metoder för hantering av namn och gör inte användning av glob-mönsterbehandling i filnamn genom shell på den andra värden, vilket skapar säkerhetsproblem. Specifikt, vid användning av SCP och RCP beslutar servern vilka filer och kataloger som ska skickas till klienten, och klienten kontrollerar endast om de returnerade objektnamnen är korrekta, vilket i avsaknad av tillräckliga kontroller på klientsidan kan leda till att servern andra filnamn skickas än de som begurits. SFTP-protokollet saknar de nämnda problemen, men stöder inte exponerade speciella sökvägar, såsom «~/». För att övervinna denna skillnad föreslogs ett nytt SFTP-protokollutvidgning i den senaste versionen av OpenSSH för att avslöja sökvägar ~/{user}/.

Källa: opennet.ru