Vlákno názorů k článku OpenSSH obsahuje chybu umožňující ukrást klientské klíče od Milan - Používám HESLA ne klíče. Takže co bylo výrazně...
-
mngnt (neregistrovaný)
Nie je najlepsi kluc s passphrasom? Kluc je sifrovany (alebo je v tom buffri uz desifrovany? Nevyznam sa az tak), ku passphrasu by sa musel utocnik dostat nejak inak (nie ze by sa nedalo), takze by to malo byt sicher, nie? Pripadne pouzivat ssh-agent, aby som ten passphrase nemusel vzdy pisat.
-
To máte odkud? V tom vyjádření od Qualysu se píše:
Finally, for these three reasons, passphrase-encrypted SSH keys are
leaked in their encrypted form, but an attacker may attempt to crack the
passphrase offline. On the other hand, SSH keys that are available only
through an authentication agent are never leaked, in any form.
Takže klíče čtené z disku ssh klientem jsou v paměti zašifrované, a klíče z agenta tímto způsobem uniknout nemohou.
-
Podle toho dokumentu https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-0778/openssh-cve-2016-0777-cve-2016-0778.txt
je problém v bufferech při použití fopen, fgets apod. ze standardní céčkovské knihovny.
1. If a private SSH key is loaded from disk into memory by fopen() (or
fdopen()), fgets(), and fclose(), a partial or complete copy of this
private key may remain uncleansed in memory. Indeed, these functions
manage their own internal buffers, and whether these buffers are
cleansed or not depends on the OpenSSH client's libc (stdio)
implementation, but not on OpenSSH itself.
Tedy, jestli jsem to pochopil správně, ten problém je v tom, že klient načte klíče pomocí standardní knihovny, která si soubor sama bufferuje.
Proto tedy unikne ten zašifrovaný klíč, protože to uniká přímo z funkce načítající ten soubor.
-
Aha, už to vidím. Klient vydá jakákoli data z nově alokovaného bufferu, který není nulovaný. To už je podle mě samo o sobě špatně, paměť de facto poskytovaná po síti by měla být podle mě nulovaná při alokaci. Naštěstí kód OpenSSH nuluje paměť s klíči při uvolnění, takže se struktury obsahující klíče takto nenasdílejí. Jenže...
1) Problém nastává v glibc funkcích implementujících ANSI souborové API, které samostatně bufferuje data při čtení ze souborů a nezajišťuje vymazání dat při uvolnění bufferů.
2) Jiný problém nastává při volání realloc(), které zanechává data v původní lokaci.
3) Ještě jiný problém nastává při vynulování uvolňovaných dat, jestliže se kvůli optimalizacím vynulování neprovede.
Ale popravdě jenom u prvním problému je mi jasné, že se týká pouze klíčů načítaných přímo ze souboru. Navíc by stačilo ANSI funkce vůbec nepoužívat ve prospěch POSIX fukcí. Tak jako tak se chovají divně. U zbylých dvou je potřeba znát rozhraní SSH agenta, takže tam jsem tak trochu ze hry.
Nicméně pro všechny tyto problémy je společné to, že narušují předpoklad, že uvolněná paměť je čistá, tedy neobsahuje žádná citlivá data. Jenže s takovým předpokladem prostě nejde počítat. Takže se bavíme pouze o následcích, ale chyba je skutečně v tom, že rozhraní vůči ssh serveru umožňuje číst neinicializovanou paměť, která z principu může obsahovat citlivá data.
Nejsem expert na hardening, takže k mírnění následků (když už dojde k leakování neinicializovaného bufferu po síti) se nebudu nějak víc vyjadřovat.
-
Jenda (neregistrovaný)
Protože SSH agent je samostatný proces, a u této chyby lze číst pouze paměť SSH klienta (resp. prostě procesu, ve kterém se projevila). U jiných potenciálních chyb by mohlo jít číst libovolnou paměť, ale tam tě sestřelí segmentace operačního systému, když se pokusíš hrábnout někam, kde ti to nepatří.
Se SSH agentem jsou zase jiné veselosti, např. agent forwarding, který umožní vzdálenému serveru podepsat cokoli tvým klíčem - samozřejmě jen když mu to povolíš, ale podobně, jako tady byla zapnutá nějaká funkce (roaming), o které nikdo nevěděl, bych se bál, že se může objevit chyba, která umožní zneužít agenta.
-
ebik (neregistrovaný)
No, kdokoli ma roota na tom stroji, kam ses prihlasil s forwardingem, tak muze:
1.) zjistit z promenne prostredi vsech tvych procesu - zejmena tveho shellu, ktery je z sshd spusten.
2.) stat se tebou ('su') a nastavit si promenne prostredi (viz 1.). Pak je od tebe z pohledu ssh klienta naprosto nerozeznatelny a muze se prihlasit kamkoli muzes ty (dokud jses na takovem stroji prihlasen).Agent forwarding je v podstate o duvere - veris, ze na cilovem stroji neni root, ktery by chtel pouzivat tveho ssh agenta k tomu aby se dostal nekam dal.
-
Jenda (neregistrovaný)
Tak já nevím, co chceš slyšet. Chyba je v kódu pro komunikaci se serverem a umožňuje číst paměť toho procesu, který komunikuje. ssh-agent se serverem nekomunikuje (pouze si se ssh klientem vyměňují data k podepsání nějakým jiným protokolem, ve kterém chyba není), tak ho server nemůže přesvědčit, aby mu poslal svoji paměť.
-
ebik (neregistrovaný)
Jen pokud máte dostatečně silná hesla a používáte je jen k přihlášení přes ssh. A máte je do různých serverů různá (nebo alespoň do různých "systémů"). Je to už pár let, co napadený ssh server mohl 'zalogovat' uživatelské heslo, pokud se uživatel přihlašoval heslem (resp. možná ne přímo heslo, ale informaci, která počet možných hesel omezila na nějaké směšné číslo.). Bohužel CVE nevím, jen jsem dostal upozornění od správce serveru, ať si změním heslo.
-
Jenda (neregistrovaný)
> Bohužel CVE nevím, jen jsem dostal upozornění od správce serveru, ať si změním heslo.
To bych považoval za feature, ne za bug. To heslo se prostě přenáší.
Ještě by teoreticky mohl poslat salt z /etc/shadow a ty bys spočítal hash a poslal mu ho zpátky. Ale minimálně při změně toho hesla ho vidí SSH server a PAM.
ČLÁNKY DO MAILU