Uitgave van OpenSSH 8.8 met uitgeschakelde ondersteuning voor digitale handtekeningen in rsa-sha

De release van OpenSSH 8.8 is gepubliceerd, een open implementatie van een client en server voor het werken met de SSH 2.0- en SFTP-protocollen. De release is opmerkelijk omdat het standaard de mogelijkheid uitschakelt om digitale handtekeningen te gebruiken op basis van RSA-sleutels met een SHA-1-hash (“ssh-rsa”).

Het stopzetten van de ondersteuning voor ‘ssh-rsa’-handtekeningen is te wijten aan de toegenomen efficiëntie van botsingsaanvallen met een bepaald voorvoegsel (de kosten voor het selecteren van een botsing worden geschat op ongeveer $ 50). Om het gebruik van ssh-rsa op uw systemen te testen, kunt u proberen verbinding te maken via ssh met de optie “-oHostKeyAlgorithms=-ssh-rsa”. Ondersteuning voor RSA-handtekeningen met SHA-256- en SHA-512-hashes (rsa-sha2-256/512), die worden ondersteund sinds OpenSSH 7.2, blijft ongewijzigd.

In de meeste gevallen zal het stopzetten van de ondersteuning voor “ssh-rsa” geen handmatige acties van gebruikers vereisen, omdat OpenSSH voorheen de UpdateHostKeys-instelling standaard had ingeschakeld, waardoor clients automatisch naar betrouwbaardere algoritmen worden gemigreerd. Voor migratie is de protocolextensie “[e-mail beveiligd]", waardoor de server, na authenticatie, de client kan informeren over alle beschikbare hostsleutels. In het geval dat u verbinding maakt met hosts met zeer oude versies van OpenSSH aan de clientzijde, kunt u selectief de mogelijkheid retourneren om “ssh-rsa”-handtekeningen te gebruiken door aan ~/.ssh/config toe te voegen: Host old_hostname HostkeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms + ssh-rsa

De nieuwe versie lost ook een beveiligingsprobleem op dat wordt veroorzaakt door sshd, te beginnen met OpenSSH 6.2, waarbij de gebruikersgroep niet correct wordt geïnitialiseerd bij het uitvoeren van opdrachten die zijn gespecificeerd in de AuthorizedKeysCommand- en AuthorizedPrincipalsCommand-richtlijnen. Deze richtlijnen moesten het mogelijk maken dat opdrachten onder een andere gebruiker konden worden uitgevoerd, maar in feite erfden ze de lijst met groepen die werden gebruikt bij het uitvoeren van sshd. Mogelijk zorgde dit gedrag er, in aanwezigheid van bepaalde systeeminstellingen, voor dat de gelanceerde handler extra rechten op het systeem kreeg.

De nieuwe release-opmerking bevat ook een waarschuwing dat scp standaard SFTP zal gebruiken in plaats van het oude SCP/RCP-protocol. SFTP gebruikt meer voorspelbare naamverwerkingsmethoden en maakt geen gebruik van shell-verwerking van glob-patronen in bestandsnamen aan de kant van de andere host, wat beveiligingsproblemen veroorzaakt. Met name bij het gebruik van SCP en RCP beslist de server welke bestanden en mappen naar de client worden verzonden, en controleert de client alleen de juistheid van de geretourneerde objectnamen, waardoor, bij gebrek aan goede controles aan de clientzijde, de server om andere bestandsnamen over te dragen die verschillen van de gevraagde. Het SFTP-protocol kent deze problemen niet, maar ondersteunt de uitbreiding van speciale paden zoals “~/” niet. Om dit verschil aan te pakken, introduceerde de vorige release van OpenSSH een nieuwe SFTP-protocolextensie voor de ~/ en ~user/-paden in de SFTP-serverimplementatie.

Bron: opennet.ru

Voeg een reactie