OpenSSH 8.3-udgivelse med scp-sårbarhedsrettelse

Efter tre måneders udvikling præsenteret релиз OpenSSH 8.3, en åben klient- og serverimplementering til at arbejde via SSH 2.0- og SFTP-protokollerne.

Den nye udgivelse tilføjer beskyttelse mod scp-angreb, der tillader serveren at videregive andre filnavne end de anmodede (i modsætning til tidligere sårbarhed, gør angrebet det ikke muligt at ændre den brugervalgte mappe eller glob-maske). Husk, at i SCP bestemmer serveren, hvilke filer og mapper der skal sendes til klienten, og klienten kontrollerer kun rigtigheden af ​​de returnerede objektnavne. Essensen af ​​det identificerede problem er, at hvis utimes systemkald mislykkes, så fortolkes indholdet af filen som filmetadata.

Denne funktion, når der oprettes forbindelse til en server styret af en hacker, kan bruges til at gemme andre filnavne og andet indhold i brugerens FS, når der kopieres ved hjælp af scp i konfigurationer, der fører til fejl ved opkald til utimes (f.eks. når utimes er forbudt af SELinux-politikken eller systemopkaldsfilteret). Sandsynligheden for reelle angreb vurderes til at være minimal, da utimes-kaldet i typiske konfigurationer ikke fejler. Derudover går angrebet ikke ubemærket hen - når man kalder scp, vises en dataoverførselsfejl.

Generelle ændringer:

  • I sftp er behandlingen af ​​"-1"-argumentet blevet stoppet, svarende til ssh og scp, som tidligere blev accepteret, men ignoreret;
  • I sshd, når du bruger IgnoreRhosts, er der nu tre valgmuligheder: "yes" - ignorer rhosts/shosts, "no" - respekter rhosts/shosts, og "shosts-only" - tillad ".shosts", men tillad ".rhosts";
  • Ssh understøtter nu %TOKEN-substitution i LocalFoward- og RemoteForward-indstillingerne, der bruges til at omdirigere Unix-sockets;
  • Tillad indlæsning af offentlige nøgler fra en ukrypteret fil med en privat nøgle, hvis der ikke er en separat fil med den offentlige nøgle;
  • Hvis libcrypto er tilgængelig i systemet, bruger ssh og sshd nu implementeringen af ​​chacha20-algoritmen fra dette bibliotek, i stedet for den indbyggede bærbare implementering, som halter bagefter i ydeevne;
  • Implementerede evnen til at dumpe indholdet af en binær liste over tilbagekaldte certifikater, når kommandoen "ssh-keygen -lQf /path" blev udført;
  • Den bærbare version implementerer definitioner af systemer, hvor signaler med SA_RESTART-indstillingen afbryder driften af ​​select;
  • Løste problemer med montering på HP/UX og AIX systemer;
  • Rettede problemer med at bygge seccomp sandbox på nogle Linux-konfigurationer;
  • Forbedret libfido2-biblioteksdetektion og løst byggeproblemer med "--with-security-key-builtin" muligheden.

OpenSSH-udviklerne advarede også endnu engang om den forestående nedbrydning af algoritmer ved hjælp af SHA-1-hashes pga. forfremmelse effektiviteten af ​​kollisionsangreb med et givet præfiks (omkostningerne ved at vælge en kollision anslås til ca. 45 tusind dollars). I en af ​​de kommende udgivelser planlægger de som standard at deaktivere muligheden for at bruge den offentlige nøgle digitale signaturalgoritme "ssh-rsa", som er nævnt i den originale RFC for SSH-protokollen og forbliver udbredt i praksis (for at teste brugen af ssh-rsa i dine systemer, kan du prøve at oprette forbindelse via ssh med muligheden "-oHostKeyAlgorithms=-ssh-rsa").

For at udjævne overgangen til nye algoritmer i OpenSSH vil UpdateHostKeys-indstillingen som standard være aktiveret i en fremtidig udgivelse, hvilket automatisk vil migrere klienter til mere pålidelige algoritmer. Anbefalede algoritmer til migrering inkluderer rsa-sha2-256/512 baseret på RFC8332 RSA SHA-2 (understøttet siden OpenSSH 7.2 og brugt som standard), ssh-ed25519 (understøttet siden OpenSSH 6.5) og ecdsa-sha2-nistp256/384 baseret på RFC521 ECDSA (understøttet siden OpenSSH 5656).

Fra den sidste udgivelse er "ssh-rsa" og "diffie-hellman-group14-sha1" blevet fjernet fra CASignatureAlgorithms-listen, der definerer de algoritmer, der er tilladt til digitalt at signere nye certifikater, da brug af SHA-1 i certifikater udgør en yderligere risiko på grund af, at angriberen har ubegrænset tid til at søge efter en kollision for et eksisterende certifikat, mens tidspunktet for angreb på værtsnøgler er begrænset af forbindelsestimeoutet (LoginGraceTime).

Kilde: opennet.ru

Tilføj en kommentar