Na zes maanden ontwikkeling is de release van OpenSSH 8.9 gepresenteerd, een open implementatie van de client en server voor gebruik via de SSH 2.0- en SFTP-protocollen. In de nieuwe versie is een kwetsbaarheid in sshd verholpen, die mogelijk toegang zonder authenticatie kan verlenen. Dit probleem wordt veroorzaakt door een integer overflow in de authenticatiecode, maar misbruik is alleen mogelijk in combinatie met andere logische fouten in de code.
In de huidige situatie is de kwetsbaarheid niet uit te buiten wanneer de privilege-scheiding is ingeschakeld, omdat de manifestatie ervan wordt geblokkeerd door afzonderlijke controles die in de code van de privilege-scheiding worden uitgevoerd. De privilege-scheiding is sinds 2002 standaard ingeschakeld, beginnend met OpenSSH 3.2.2, en is verplicht sinds de release van OpenSSH 7.5, die in 2017 is gepubliceerd. Bovendien wordt in draagbare versies van OpenSSH, beginnend met release 6.5 (2014), de kwetsbaarheid geblokkeerd door te compileren met inschakeling van flags ter bescherming tegen integer overflows.
Andere wijzigingen:
- In de draagbare versie van OpenSSH is de ingebouwde ondersteuning voor het hash-algoritme MD5 voor wachtwoorden uit sshd verwijderd (het gebruik van externe bibliotheken, zoals libxcrypt, is toegestaan).
- In ssh, sshd, ssh-add en ssh-agent is er een subsysteem geïmplementeerd voor het beperken van de overdracht en het gebruik van sleutels die aan ssh-agent zijn toegevoegd. Dit subsysteem stelt regels in om te bepalen hoe en waar sleutels in ssh-agent kunnen worden gebruikt. Bijvoorbeeld, om een sleutel toe te voegen die alleen kan worden gebruikt voor authenticatie wanneer elke gebruiker verbinding maakt met de host scylla.example.org, gebruiker perseus met host cetus.example.org en gebruiker medea met host charybdis.example.org met omleiding via tussenhost scylla.example.org, kan de volgende opdracht worden gebruikt: $ ssh-add -h "perseus@cetus.example.org" \ -h "scylla.example.org" \ -h "scylla.example.org>medea@charybdis.example.org" \ ~\/.ssh\id_ed25519
- In ssh en sshd is aan de lijst KexAlgorithms, die de volgorde van keuze voor sleuteldistributiemethoden bepaalt, standaard de hybride algorithm "sntrup761x25519-sha512@openssh.com" (ECDH/x25519 + NTRU Prime) toegevoegd, die bestand is tegen brute-force aanvallen met kwantumcomputers. In versie OpenSSH 8.9 is deze onderhandelingsmethode toegevoegd tussen de methodes ECDH en DH, maar in de volgende release is het de bedoeling om deze standaard in te schakelen.
- In ssh-keygen, ssh, and ssh-agent, the handling of keys from FIDO tokens used for device verification has been improved, including keys for biometric authentication.
- The command 'ssh-keygen -Y match-principals' has been added to ssh-keygen for checking user names in the allowed names list file.
- In ssh-add and ssh-agent, it is now possible to add FIDO keys protected by a PIN code to the ssh-agent (the PIN request prompts during authentication).
- In ssh-keygen, the choice of hash algorithm (sha512 or sha256) is allowed during signature generation.
- In ssh and sshd, to enhance performance, network data is now read directly into the incoming packet buffer, bypassing intermediate buffering in the stack. Similarly, direct placement of received data into the channel buffer has been implemented.
- In ssh, the PubkeyAuthentication directive has been expanded to support additional parameters (yes|no|unbound|host-bound) to provide options for the used protocol extension.
In one of the upcoming releases, it is planned to default the scp utility to use SFTP instead of the outdated SCP/RCP protocol. SFTP employs more predictable methods for handling names and does not use shell-based glob pattern processing in file names on the other host, which creates security issues. Specifically, when using SCP and RCP, the server decides which files and directories to send to the client, and the client only verifies the correctness of the returned object names, which allows, in the absence of proper checks on the client side, to transfer other file names that differ from those requested. server The SFTP protocol is free from these issues but does not support revealing special paths, such as '~/'. To address this difference, a new SFTP protocol extension for revealing paths ~/ and ~user/ has been proposed in the SFTP server implementation in the previous release of OpenSSH.
Bron: opennet.ru
