Udgivelsen af OpenSSH 8.3 med en fejlrettelse i scp

Efter tre måneders udvikling præsenteret udgivelse OpenSSH 8.3, en open source-implementering af klient og server til arbejde med SSH 2.0- og SFTP-protokoller.

Den nye version tilføjer beskyttelse mod et angreb på scp, der giver serveren mulighed for at overføre andre filnavne, som adskiller sig fra de anmodede (i modsætning til den tidligere sårbarhed, angrebet giver ikke mulighed for at ændre den valgte brugerkatalog eller glob-maske). Lad os minde om, at i SCP beslutter serveren, hvilke filer og mapper der skal sendes til klienten, mens klienten blot kontrollerer gyldigheden af de returnerede objektnavne. Problemet ligger i det faktum, at hvis systemopkaldet utimes fejler, så fortolkes indholdet af filen som filens metadata.

Denne funktion kan, når der oprettes forbindelse til en server kontrolleret af en angriber, bruges til at gemme andre filnavne og indhold i brugerens FS, når der kopieres ved hjælp af scp i konfigurationer, der kan fejle ved opkaldet af utimes (f.eks. ved forbud mod utimes gennem SELinux-politik eller systemopkaldsfilter). Sandsynligheden for at udføre reelle angreb vurderes som minimal, da opkaldet til utimes i typiske konfigurationer ikke fejler. Derudover går angrebet ikke ubemærket hen — når scp kaldes, vises en overførselsfejl.

Generelle ændringer:

• I sftp stoppede behandlingen af argumentet «-1» ligesom med ssh og scp, som tidligere blev accepteret, men ignoreret;
• I sshd, når der anvendes IgnoreRhosts, tilbydes nu tre valg: «yes» — ignorere rhosts/shosts, «no» — tage hensyn til rhosts/shosts og «shosts-only» — tillade «.shosts», men forbyde «.rhosts»;
• I ssh sikres håndtering af substitutionen %TOKEN i indstillingerne LocalForward og RemoteForward, der anvendes til omdirigering af Unix-sokler;
• Tilladt at indlæse åbne nøgler fra en ukrypteret fil med privatnøglen, hvis der ikke er en separat fil med den åbne nøgle;
• Hvis systemet har libcrypto, bruger ssh og sshd nu implementeringen af algoritmen chacha20 fra dette bibliotek i stedet for den indbyggede bærbare implementering, som halter bagud i ydeevne;
• Mulighed for dump af indholdet af det binære tilbagekaldte certifikatlisten ved at udføre kommandoen «ssh-keygen -lQf /path».
• I den bærbare version er der implementeret identifikation af systemer, hvor signaler med SA_RESTART-optionen afbryder arbejdet med select;
• Problemerne med at bygge i HP/UX og AIX-systemer er løst;
• Problemerne med at bygge seccomp-sandbox i nogle Linux-konfigurationer er løst;
• Definitionen af biblioteket libfido2 er forbedret, og der er løst problemer med bygningen med ‘—with-security-key-builtin’ optionen.

Udviklerne af OpenSSH har endnu en gang advaret om den kommende overgang af algoritmer, der bruger SHA-1 hash, til status som forældede; forøgelsen effektiviteten af kollisionsangreb med et givet præfiks (omkostningerne ved at finde en kollisionsvurdering er cirka 45.000 dollars). I en af de kommende udgivelser planlægges det at deaktivere algoritmen for digitale signaturer baseret på den offentlige nøgle "ssh-rsa" som standard, hvilket nævnes i den oprindelige RFC for SSH-protokollen og forbliver udbredt i praksis (for at tjekke anvendelsen af ssh-rsa i dine systemer kan du prøve at tilslutte via ssh med indstillingen "-oHostKeyAlgorithms=-ssh-rsa").

For at lette overgangen til de nye algoritmer i OpenSSH vil der i en af de kommende udgaver blive inkluderet indstillingen UpdateHostKeys som standard, der automatisk vil overføre klienter til mere pålidelige algoritmer. Blandt de anbefalede algoritmer til migration nævnes rsa-sha2-256/512 baseret på RFC8332 RSA SHA-2 (understøttet siden OpenSSH 7.2 og bruges som standard), ssh-ed25519 (understøttet siden OpenSSH 6.5) og ecdsa-sha2-nistp256/384/521 baseret på RFC5656 ECDSA (understøttet siden OpenSSH 5.7).

Fra den forrige udgave er ‘ssh-rsa’ og ‘diffie-hellman-group14-sha1’ fjernet fra listen over CASignatureAlgorithms, der definerer algoritmerne, der er tilladt for digital signatur af nye certifikater, da brugen af SHA-1 i certifikater indebærer en ekstra risiko, fordi en angriber har ubegrænset tid til at finde en kollisions for et eksisterende certifikat, mens tiden for angreb på værtens nøgler er begrænset af forbindelsestimering (LoginGraceTime).

Kilde: opennet.ru