Vrystelling van OpenSSH 8.9 met uitskakeling van kwesbaarheid in sshd

Na ses maande se ontwikkeling word die vrystelling van OpenSSH 8.9, 'n oop implementering van 'n kliënt en bediener om oor die SSH 2.0- en SFTP-protokolle te werk, aangebied. Die nuwe weergawe van sshd stel 'n kwesbaarheid reg wat moontlik ongeverifieerde toegang kan toelaat. Die probleem word veroorsaak deur 'n heelgetal-oorloop in die verifikasiekode, maar kan slegs in kombinasie met ander logiese foute in die kode uitgebuit word.

In sy huidige vorm kan die kwesbaarheid nie uitgebuit word wanneer die voorregskeidingsmodus geaktiveer is nie, aangesien die manifestasie daarvan geblokkeer word deur afsonderlike kontroles wat in die voorregskeidingsnasporingskode uitgevoer word. Voorregskeidingsmodus is by verstek geaktiveer sedert 2002 sedert OpenSSH 3.2.2, en is verpligtend sedert die vrystelling van OpenSSH 7.5 wat in 2017 gepubliseer is. Daarbenewens, in draagbare weergawes van OpenSSH wat begin met vrystelling 6.5 (2014), word die kwesbaarheid geblokkeer deur samestelling met die insluiting van heelgetal-oorloopbeskermingsvlae.

Ander veranderinge:

  • Die draagbare weergawe van OpenSSH in sshd het inheemse ondersteuning vir hashing-wagwoorde verwyder deur die MD5-algoritme te gebruik (wat dit moontlik maak om met eksterne biblioteke soos libxcrypt terug te keer).
  • ssh, sshd, ssh-add en ssh-agent implementeer 'n substelsel om die aanstuur en gebruik van sleutels wat by ssh-agent gevoeg is, te beperk. Die substelsel laat jou toe om reëls te stel wat bepaal hoe en waar sleutels in ssh-agent gebruik kan word. Byvoorbeeld, om 'n sleutel by te voeg wat slegs gebruik kan word om enige gebruiker wat aan die gasheer koppel scylla.example.org te staaf, die gebruiker perseus by die gasheer cetus.example.org, en die gebruiker medea by die gasheer charybdis.example.org met herleiding deur 'n tussengasheer scylla.example.org, kan jy die volgende opdrag gebruik: $ ssh-add -h "[e-pos beskerm]" \ -h "scylla.example.org" \ -h "scylla.example.org>[e-pos beskerm]\ ~/.ssh/id_ed25519
  • In ssh en sshd is 'n hibriede algoritme by verstek by die KexAlgorithms-lys gevoeg, wat die volgorde bepaal waarin sleuteluitruilmetodes gekies word.[e-pos beskerm]"(ECDH/x25519 + NTRU Prime), bestand teen seleksie op kwantumrekenaars. In OpenSSH 8.9 is hierdie onderhandelingsmetode tussen die ECDH- en DH-metodes bygevoeg, maar dit word beplan om by verstek in die volgende vrystelling geaktiveer te word.
  • ssh-keygen, ssh en ssh-agent het verbeterde hantering van FIDO-tokensleutels wat vir toestelverifikasie gebruik word, insluitend sleutels vir biometriese verifikasie.
  • Bygevoeg "ssh-keygen -Y match-principals"-opdrag by ssh-keygen om gebruikersname in die allownamelist-lêer na te gaan.
  • ssh-add en ssh-agent bied die vermoë om FIDO-sleutels wat deur 'n PIN-kode beskerm word, by ssh-agent te voeg (die PIN-versoek word vertoon ten tyde van verifikasie).
  • ssh-keygen laat die keuse van hashing-algoritme (sha512 of sha256) toe tydens handtekeninggenerering.
  • In ssh en sshd, om werkverrigting te verbeter, word netwerkdata direk in die buffer van inkomende pakkies gelees, wat intermediêre buffering op die stapel omseil. Direkte plasing van die ontvangde data in 'n kanaalbuffer word op 'n soortgelyke wyse geïmplementeer.
  • In ssh het die PubkeyAuthentication-aanwysing die lys van ondersteunde parameters (ja|nee|ongebonde|gasheergebonde) uitgebrei om die vermoë te bied om die protokoluitbreiding te kies om te gebruik.

In 'n toekomstige vrystelling beplan ons om die verstek van die scp-nutsding te verander om SFTP te gebruik in plaas van die verouderde SCP/RCP-protokol. SFTP gebruik meer voorspelbare naamhanteringsmetodes en gebruik nie dopverwerking van globpatrone in lêername aan die ander gasheer se kant nie, wat sekuriteitsprobleme skep. In die besonder, wanneer SCP en RCP gebruik word, besluit die bediener watter lêers en gidse om na die kliënt te stuur, en die kliënt kontroleer slegs die korrektheid van die teruggekeerde objekname, wat, in die afwesigheid van behoorlike kontrole aan die kliëntkant, die bediener om ander lêername oor te dra wat verskil van dié wat versoek is. Die SFTP-protokol het nie hierdie probleme nie, maar ondersteun nie die uitbreiding van spesiale paaie soos "~/" nie. Om hierdie verskil aan te spreek, het die vorige weergawe van OpenSSH 'n nuwe SFTP-protokol-uitbreiding bekendgestel aan die ~/ en ~gebruiker/-paaie in die SFTP-bedienerimplementering.

Bron: opennet.ru

Voeg 'n opmerking