Három hónap fejlesztés után kiadás , nyílt forrású ügyfél- és szervermegoldás az SSH 2.0 és SFTP protokollok használatához.
Az új kiadásban védelmet kaptunk az SCP-támadások ellen, amely lehetővé teszi a szerver számára, hogy más fájlneveket adjon át, mint amit kértek (ellentétben a , amely lehetetlenné tette a kiválasztott könyvtár vagy glob-minta megváltoztatását). Emlékeztetünk arra, hogy az SCP-nél a szerver dönt a fájlok és könyvtárak ügyfélhez való elküldéséről, míg az ügyfél csak ellenőrzi a visszaadott objektumnevek helyességét. Azonosított probléma lényege, hogy ha a utimes rendszerhívás hibát jelez, akkor a fájl tartalmát fájlmetainformációként értelmezik.
Ez a tulajdonság, ha egy támadó által kontrollált szerverhez csatlakozunk, felhasználható arra, hogy a felhasználó fájlrendszerében más fájlneveket és tartalmakat tároljunk SCP átviteli konfigurációk során, amelyek a utimes hívás során hibát generálnak (például, ha a SELinux politika vagy a rendszerhívás szűrők megakadályozzák a utimes hívást). A valós támadások valószínűsége minimálisra becsülhető, mivel tipikus konfigurációkban a utimes hívás nem ér véget hibával. Ezen kívül a támadás nem észlelhetően zajlik — SCP hívásakor adatátviteli hibát jelez.
Általános változások:
- Az sftp-ben megszűnt a «-1» argumentum kezelése, hasonlóan az ssh-hoz és az scp-hez, amely korábban elfogadott volt, de figyelmen kívül hagyott;
- A sshd-ben az IgnoreRhosts használatával most három választási lehetőség biztosított: «yes» — figyelmen kívül hagyjuk a rhosts/shosts-et, «no» — figyelembe vesszük a rhosts/shosts-et, és «shosts-only» — engedélyezzük a «.shosts»-et, de megtiltjuk a «.rhosts»-ot;
- Az ssh biztosítja a %TOKEN helyettesítés kezelését a LocalForward és RemoteForward beállításokban, amelyeket Unix-socketek átkonfigurálására használnak;
- Engedélyezett a nyitott kulcsok betöltése a titkosítatlan fájlokból, ha nincs külön nyitott kulcs fájl;
- Amennyiben a rendszer rendelkezik a libcrypto-val, az ssh és a sshd most az adott könyvtárban található chacha20 algoritmus implementációját használja, nem pedig a beágyazott hordozható implementációt, amely teljesítményben elmarad;
- Megvalósították a visszavont tanúsítványok bináris listájának tartalmának kiírásának lehetőségét az «ssh-keygen -lQf /path» parancs futtatásakor;
- A hordozható verzióban megvalósították azoknak a rendszereknek a meghatározását, ahol az SA_RESTART opcióval rendelkező jelek megszakítják a select működését;
- Megoldották az összeállítási problémákat HP/UX és AIX rendszereken.
- A seccomp sandbox build issue has been resolved in certain Linux configurations;
- Improved detection of the libfido2 library and addressed build issues with the ‘--with-security-key-builtin’ option.
OpenSSH developers have once again warned about the upcoming deprecation of algorithms using SHA-1 hashes due to a megadott prefixumú ütközési támadások hatékonyságának (a kollekció költsége körülbelül 45 ezer dollárra becsülhető). Az egyik következő kiadásban tervezik letiltani az ssh-rsa nyilvános aláírás algoritmus alapértelmezett engedélyezésének lehetőségét, amely a SSH protokoll eredeti RFC-jében szerepel, és széles körben elterjedt a gyakorlatban (az ssh-rsa alkalmazásának ellenőrzésére a rendszereikben megpróbálhatnak csatlakozni ssh-val a „-oHostKeyAlgorithms=-ssh-rsa” opcióval).
A zökkenőmentes átállás érdekében az OpenSSH következő verzióiban alapértelmezés szerint aktiválva lesz az UpdateHostKeys beállítás, amely lehetővé teszi a kliensek automatikus áttérését megbízhatóbb algoritmusokra. A migrációra javasolt algoritmusok között említve van az rsa-sha2-256/512 az RFC8332 RSA SHA-2 alapján (amelyet az OpenSSH 7.2 óta támogatnak és alapértelmezésként használnak), az ssh-ed25519 (amelyet az OpenSSH 6.5 óta támogatnak) és az ecdsa-sha2-nistp256/384/521 az RFC5656 ECDSA alapján (amelyet az OpenSSH 5.7 óta támogatnak).
Starting from the previous release, ‘ssh-rsa’ and ‘diffie-hellman-group14-sha1’ have been removed from the list of CASignatureAlgorithms, which defines the algorithms permissible for digital signatures of new certificates. This is due to the additional risk associated with using SHA-1 in certificates, as an attacker has unlimited time to find a collision for an existing certificate, while the time to attack host keys is restricted by the connection timeout (LoginGraceTime).
Forrás: opennet.ru
