OpenSSH 8.3 release mei scp kwetsberens fix

Nei trije moannen fan ûntwikkeling presintearre frijlitte OpenSSH 8.3, in iepen client- en server-ymplemintaasje foar wurkjen fia de SSH 2.0- en SFTP-protokollen.

De nije útjefte foeget beskerming ta tsjin scp-oanfallen wêrtroch de tsjinner oare bestânsnammen trochjaan kin as de oanfrege (yn tsjinstelling ta ferline kwetsberens, de oanfal makket it net mooglik om de troch de brûker selektearre map of globmasker te feroarjen). Tink derom dat yn SCP de tsjinner beslút hokker bestannen en mappen nei de kliïnt te stjoeren, en de kliïnt kontrolearret allinich de krektens fan 'e weromjûn objektnammen. De essinsje fan it identifisearre probleem is dat as de utimes-systeemoprop mislearret, dan wurdt de ynhâld fan it bestân ynterpretearre as triemmetadata.

Dizze funksje, by it ferbinen mei in tsjinner kontrolearre troch in oanfaller, kin brûkt wurde om oare bestânsnammen en oare ynhâld op te slaan yn 'e FS fan 'e brûker by it kopiearjen mei scp yn konfiguraasjes dy't liede ta mislearring by it oproppen fan utimes (bygelyks as utimes ferbean is troch it SELinux-belied of systeemopropfilter). De kâns op echte oanfallen wurdt rûsd minimaal te wêzen, om't yn typyske konfiguraasjes de utim-oprop net mislearret. Derneist giet de oanfal net ûngemurken - by it roppen fan scp wurdt in flater foar gegevensferfier werjûn.

Algemiene feroarings:

  • Yn sftp is it ferwurkjen fan it "-1" argumint stoppe, fergelykber mei ssh en scp, dy't earder akseptearre, mar negearre;
  • Yn sshd, by it brûken fan IgnoreRhosts, binne d'r no trije karren: "yes" - negearje rhosts/shosts, "nee" - respektearje rhosts/shosts, en "shosts-allinnich" - tastean ".shosts" mar ".rhosts" net tastean;
  • Ssh stipet no %TOKEN-ferfanging yn 'e LocalFoward- en RemoteForward-ynstellingen dy't brûkt wurde om Unix-sockets troch te lieden;
  • Tastean it laden fan iepenbiere kaaien út in net-fersifere triem mei in privee kaai as der gjin aparte triem mei de iepenbiere kaai;
  • As libcrypto yn it systeem oanwêzich is, brûke ssh en sshd no de ymplemintaasje fan it chacha20-algoritme fan dizze bibleteek, ynstee fan de ynboude draachbere ymplemintaasje, dy't efterbliuwt yn prestaasjes;
  • Implementearre de mooglikheid om de ynhâld fan in binêre list mei ynlutsen sertifikaten te dumpen by it útfieren fan it kommando "ssh-keygen -lQf /path";
  • De draachbere ferzje ymplemintearret definysjes fan systemen wêryn sinjalen mei de SA_RESTART-opsje de operaasje fan selektearje ûnderbrekke;
  • Oplost problemen mei gearkomste op HP / UX en AIX systemen;
  • Fêste problemen mei it bouwen fan seccomp sandbox op guon Linux-konfiguraasjes;
  • Ferbettere libfido2-bibleteekdeteksje en bouproblemen oplost mei de opsje "--mei-feiligens-kaai-ynboud".

De OpenSSH-ûntwikkelders warskôge ek nochris oer de drege ûntbining fan algoritmen mei SHA-1-hashes fanwegen promoasje de effektiviteit fan botsingsoanfallen mei in opjûn foarheaksel (de kosten foar it selektearjen fan in botsing wurde rûsd op likernôch 45 tûzen dollar). Yn ien fan 'e kommende releases binne se fan plan om standert de mooglikheid út te skeakeljen om it digitale hantekeningalgoritme fan iepenbiere kaai "ssh-rsa" te brûken, dat wurdt neamd yn 'e orizjinele RFC foar it SSH-protokol en bliuwt wiidferspraat yn 'e praktyk (om it gebrûk te testen fan ssh-rsa yn jo systemen, kinne jo besykje te ferbinen fia ssh mei de opsje "-oHostKeyAlgorithms=-ssh-rsa").

Om de oergong nei nije algoritmen yn OpenSSH glêd te meitsjen, sil yn in takomstige release de UpdateHostKeys-ynstelling standert ynskeakele wurde, dy't kliïnten automatysk migrearje nei betrouberere algoritmen. Oanrikkemandearre algoritmen foar migraasje omfetsje rsa-sha2-256/512 basearre op RFC8332 RSA SHA-2 (stipe sûnt OpenSSH 7.2 en standert brûkt), ssh-ed25519 (stipe sûnt OpenSSH 6.5) en ecdsa-sha2-nistp256/384 basearre op RFC521 ECDSA (stipe sûnt OpenSSH 5656).

Fanôf de lêste release binne "ssh-rsa" en "diffie-hellman-group14-sha1" fuortsmiten fan 'e CASignatureAlgorithms list dy't de algoritmen definiearret dy't tastien binne om nije sertifikaten digitaal te ûndertekenjen, om't it brûken fan SHA-1 yn sertifikaten in ekstra risiko foarmet. troch dat de oanfaller hat ûnbeheinde tiid om te sykjen nei in botsing foar in besteande sertifikaat, wylst de tiid fan oanfal op host kaaien wurdt beheind troch de ferbining timeout (LoginGraceTime).

Boarne: opennet.ru

Add a comment