Na drie maande van ontwikkeling vrylating , 'n oop implementering van die kliënt en bediener om oor die SSH 2.0- en SFTP-protokolle te werk.
Die nuwe vrystelling voeg beskerming by teen scp-aanvalle wat die bediener toelaat om ander lêername deur te gee as wat versoek is (in teenstelling met , maak die aanval dit nie moontlik om die gebruikergeselekteerde gids of glob-masker te verander nie). Onthou dat in SCP, die bediener besluit watter lêers en gidse om na die kliënt te stuur, en die kliënt kontroleer slegs die korrektheid van die teruggekeerde objekname. Die kern van die geïdentifiseerde probleem is dat as die utimes-stelseloproep misluk, die inhoud van die lêer as lêermetadata geïnterpreteer word.
Hierdie kenmerk, wanneer u aan 'n bediener koppel wat deur 'n aanvaller beheer word, kan gebruik word om ander lêername en ander inhoud in die gebruiker se FS te stoor wanneer u kopieer met behulp van scp in konfigurasies wat lei tot mislukking wanneer utimes oproepe (byvoorbeeld wanneer utimes verbied word deur die SELinux-beleid of stelseloproepfilter) . Die waarskynlikheid van werklike aanvalle word as minimaal geskat, aangesien die utime-oproep in tipiese konfigurasies nie misluk nie. Boonop gaan die aanval nie ongemerk verby nie - wanneer scp gebel word, word 'n data-oordragfout gewys.
Algemene veranderinge:
- In sftp is die verwerking van die "-1" argument gestaak, soortgelyk aan ssh en scp, wat voorheen aanvaar is, maar geïgnoreer is;
- In sshd, wanneer IgnoreRhosts gebruik word, is daar nou drie keuses: "yes" - ignoreer rhosts/shosts, "nee" - respekteer rhosts/shosts, en "shosts-only" - laat ".shosts" toe, maar deaktiveer ".rhosts";
- Ssh ondersteun nou %TOKEN-vervanging in die LocalFoward- en RemoteForward-instellings wat gebruik word om Unix-voetstukke te herlei;
- Laat die laai van publieke sleutels van 'n ongeënkripteerde lêer met 'n private sleutel toe as daar geen aparte lêer met die publieke sleutel is nie;
- As libcrypto in die stelsel beskikbaar is, gebruik ssh en sshd nou die implementering van die chacha20-algoritme vanaf hierdie biblioteek, in plaas van die ingeboude draagbare implementering, wat agterbly in prestasie;
- Implementeer die vermoë om die inhoud van 'n binêre lys van herroepe sertifikate te stort wanneer die opdrag "ssh-keygen -lQf /path" uitgevoer word;
- Die draagbare weergawe implementeer definisies van stelsels waarin seine met die SA_RESTART opsie die werking van kies onderbreek;
- Probleme opgelos met samestelling op HP/UX- en AIX-stelsels;
- Probleme opgelos met die bou van seccomp sandbox op sommige Linux-konfigurasies;
- Verbeterde libfido2-biblioteekopsporing en bouprobleme opgelos met die "--met-sekuriteitsleutel-ingeboude" opsie.
Die OpenSSH ontwikkelaars het ook weereens gewaarsku oor die naderende ontbinding van algoritmes wat SHA-1 hashes gebruik a.g.v. die doeltreffendheid van botsingsaanvalle met 'n gegewe voorvoegsel (die koste van die keuse van 'n botsing word op ongeveer 45 duisend dollar geraam). In een van die komende vrystellings beplan hulle om by verstek die vermoë om die ssh-rsa publieke sleutel digitale handtekeningalgoritme te gebruik, wat in die oorspronklike RFC vir die SSH-protokol genoem word en wydverspreid in die praktyk bly (om die gebruik van ssh na te gaan) deaktiveer -rsa in jou stelsels, kan jy probeer om via ssh te koppel met "-oHostKeyAlgorithms=-ssh-rsa" opsie).
Om die oorgang na nuwe algoritmes in OpenSSH glad te maak, in een van die volgende vrystellings, sal die UpdateHostKeys-instelling by verstek geaktiveer word, wat kliënte outomaties na meer betroubare algoritmes sal migreer. Aanbevole algoritmes vir migrasie sluit in rsa-sha2-256/512 gebaseer op RFC8332 RSA SHA-2 (ondersteun sedert OpenSSH 7.2 en word by verstek gebruik), ssh-ed25519 (ondersteun sedert OpenSSH 6.5) en ecdsa-sha2-nistp256/384 gebaseer op RFC521 ECDSA (ondersteun sedert OpenSSH 5656).
Vanaf die laaste vrystelling is "ssh-rsa" en "diffie-hellman-group14-sha1" verwyder van die CASignatureAlgorithms-lys wat die algoritmes definieer wat toegelaat word om nuwe sertifikate digitaal te onderteken, aangesien die gebruik van SHA-1 in sertifikate 'n bykomende risiko inhou as gevolg daarvan het die aanvaller onbeperkte tyd om te soek na 'n botsing vir 'n bestaande sertifikaat, terwyl die tyd van aanval op gasheersleutels beperk word deur die verbinding-time-out (LoginGraceTime).
Bron: opennet.ru