Dvě bezpečnostní chyby v OpenSSH

Byla vydána verze 7.1p2 sady aplikací pro SSH komunikaci OpenSSH. Řešeny jsou dvě bezpečnostní chyby CVE-2016-0777 a CVE-2016-0778 v experimentální podpoře roamingu v OpenSSH klientu. Za jistých okolností může server vytáhnout z paměti klienta citlivé informace, například privátní klíče. Okamžitým řešením je vložit "UseRoaming no" do ssh_config. Opravy jsou postupně k dispozici (Debian, OpenBSD, Red Hat, ...).

14.1.2016 18:38 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[Jendа]

Pozn. „experimentální podpora“ je defaultně zapnuta od roku 2010, což je také doba, od kdy je bug zneužitelný.

Před chybou by mělo ochránit držení klíče pouze ssh-agentem, nikoli ssh klientem, což má zase jiné potenciální bezpečnostní problémy (agent forwarding), takže si člověk nevybere.

[R]

Zaujimalo by ma, naco je v kliente ta experimentalna podpora roamingu, ked server ju nepodporuje! Existuje vobec nejaky SSH server, ktory to podporuje?

[Jendа]

No asi to plánovali přidat, pak z toho sešlo, a zapomněli to tam. Jinak podobnou funkci umí Mosh.

[Michal Kubeček]

Mně na tom přijde nejvíc znepokojující to, že někoho, kdo vyvíjí takhle bezpečnostně citlivý projekt, vůbec napadne experimentální a nezdokumentovanou featuru, která zatím vlastně ani nejde v praxi použít, nastavit jako defaultně zapnutou.

[Jendа]

Detaily

[petrfm]

Ten linux je samá díra

[⧠ A = 0]

Co má OpenSSH společného s Linuksem?

Už vím, je napsaný v C.

[Jendа]

Co má OpenSSH společného s Linuksem?

Jak hovorově říkáš běžně používanému desktopovému nebo serverovému systému založenému na některé z distribucí GNU/Linuxu s přídavkem dalších aplikací, jako například X serveru, mailového klienta, textového editoru nebo webového prohlížeče?

Když se tě někdo zeptá, jaký OS používáš, co mu odpovíš?

[⧠ A = 0]

Když se tě někdo zeptá, jaký OS používáš, co mu odpovíš?

Debian.

Co má OpenSSH společného s Linuksem?

Jak hovorově říkáš běžně používanému desktopovému nebo serverovému systému založenému na některé z distribucí GNU/Linuxu s přídavkem dalších aplikací, jako například X serveru, mailového klienta, textového editoru nebo webového prohlížeče?

Pokud mluvím naprosto obecně o libovolném systému s linuksovým jádrem, pak asi Linux. Ale to se mi moc často nestává.

[petrfm]

Zbytečné kecy o ničem Takže jste se po hodině psaní dopracovali k tomu, že linux je samá díra DDD

[⧠ A = 0]

Linux sice je bastl obsahující pravděpodobně spoustu děr, ale to se vůbec netýká tématu zprávičky.

[petrfm]

Zprávička i můj komentář jsou o dírách, ty tady debatuješ o nesmyslech

[pavlix]

Oba debatujete o nesmyslech.

[Adolf Hitler]

Unsinn bist du selbst, dicker Jude.

[Jendа]

Debian.

OK, když příště v podobné situaci jako petrfm napíšu "ty linuxové distribuce jsou samá díra", budeš spokojený?

Pokud mluvím naprosto obecně o libovolném systému s linuksovým jádrem, pak asi Linux. Ale to se mi moc často nestává.

petrfm se to teď stalo, řekl Linux, a dostal pojeb.

[Václav "Darm" Novák]

Odkdy je OpenSSH, projekt OpenBSD foundation, součástí kernelu Linuxu?

[petrfm]

Je soucasti kazde bezne linuxove distribuce. Treba windows ho neobsahuje, tudiz LINUX je sama dira

[Pedro1]

Hlavne, ze widle (windows) jsou bez chybicky.

[Václav "Darm" Novák]

Zatím. Jinak jistě, žádný z konkurenčních OS neměl nikdy žádný exploit, všechny ty botnety jsou vlastně iluze :)

[Jendа]

Můžeš mi (a Pedro1) vysvětit, jak z tvrzení „Linux není bezpečný“ vyplývá tvrzení „Windows jsou bezpečnější“?

[pavlix]

Vycházíš z chybného předpokladu, že se jedná primárně o tvrzení. Forma tvrzení je v tomto případě jaksi vedlejší.

[Hans1024]

Asi pouzitim stejneho principu, podle ktereho je linux oznaceni pro veskery software v distribuci

[pavlix]

+1

[Václav "Darm" Novák]

No, ten výrok „Windows ho neobsahuje, tutíž Linux je samá díra“ je trochu tendenční sám o sobě :) Nijak se tím nesnažím snížit ten průšvih OpenSSH.

[petrfm]

OpenSSH je základní a nejpoužívanější nástroj pro vzdálený přístup k linuxu. Poslední dobou je to samá díra, která vylézá na povrch. Oponovat tomu tvrzením, že hlavně že windows... blabla je dost dementní. Je to jako kdybych řekl - jsi debil. Já vím, ale lojza od naproti je taky Prostě debata malých dětí.

Nic z toho, co tady padlo, nemění nic na mém tvrzení, že linux je samá díra. Nebo má někdo nějaký důstojný argument? Čekám zase na ty perly. Nepíše se to třeba s velkým písmenem, nebo tak něco? nebo díra není oficiální termín pro bezpečnostní chybu? Hoši, hoši, musíte mít smutný život...

[d.c.]

Poslední dobou je to samá díra, která vylézá na povrch.

Například?

[petrfm]

Tak například viz článek nad touto diskusí

[d.c.]

Vyroky "kazdou chvili" a "prvni chyba po dlouhe dobe" IMHO nepopisuji stejnou situaci.

[Josef Kufner]

OpenBSD, ze kterého OpenSSH pochází, nedávno dostalo více prostředků, neboť z téhož projektu pochází i nejpoužívanější SSL knihovny a nedávno se ukázalo (Heartbleed), jak kritická část infrastruktury celého Internetu tenhle projekt je. Takže se za poslední měsíce odvedlo více práce a ulovilo více chyb.

[Radek Miček]

dostalo více prostředků

Obávám se, že to příliš nepomůže.

[Jendа]

OpenSSL nepochází z OpenBSD, zpívají to v písničce k 5.7. Teprve po Heartbleedu to forkli jako LibreSSL.

[Josef Kufner]

Dobrá poznámka. Nicméně OpenSSH je OpenBSD Secure Shell. Heartbleed byl ten kopanec do sponzorů a těch projektů, které se tím zviditelnily bylo povícero.

[Václav "Darm" Novák]

Nic to nemění na faktu že samá díra je každý software. Pokud dobře chápu tuto chybu, zneužitelnost není tak velká, i když to problém samozřejmě je. Na čem záleží nejvíc je jak rychle je průšvih opraven. Což je v případě Linuxových systémů skoro hned, u konkurence občas celé měsíce.

[Jendа]

Na čem záleží nejvíc je jak rychle je průšvih opraven.

Podle toho, od koho očekáváš útok. V době, kdy si každý stát může koupit u HackingTeamu 0daye, ti nepomůže ani oprava do minuty po zveřejnění.

[Václav "Darm" Novák]

Furt lepší než čekat půl roku. Aspoň se ti sníží množství potenciálních útočníků. U klientů hacking teamu čekám policii a bezpečnostní složky. U několik měsíců neřešeného exploitu už to umí zneužít každý automat.

[lertimir]

Ale něco trochu pomůže. Třeba pomůže, když nejede žádná služba, kterou nepotřebuješ. A ty které potřebuješ tak máš nakonfigurované tak, že se k nim připojuješ pouze z (relativně) spolehlivého místa. (Tím nemluvím o webovém serveru, tam se chovám tak, a radím lidem, aby přistupovali k tomu tak, že veřejné je všechno, i když veřejnost třeba v této chvili vše nevidí.) A uživateli při práci z bezpečností pomůže, když to co nezná pustí v sandboxu. jako Oz nebo více v QubesOS. Neberu to tak fatalisticky.

[petrfm]

Jenomže já bych rád třeba k souborům přistupoval odkudkoliv. Představa, že to budu blokovat na nějaké IP rozsahy je na nic, když se potřebuju nouzově připojit třeba z chytrého mobilu.

Řeším to teď VPNkou, ale je otázka, nakolik je VPN bezpečné řešení.

[lertimir]

To je jen míra paranoi, kterou člověk bere jako dostatečnou. Pro mne je ssh i VPN bezpečné. Třeba popisovaná zranitelnost využitelná (pokud jsem tomu v tom rychlém čtení porozuměl dobře) pokud šlápnu na kompromitovaný server a současně v průběhu práce (nebo možná krátce předtím aby klíče zůstaly v io bufferech) se také zaloguji na jiný ssh server klíčem, tak útočník ze serveru 1 může mi ukrást klíče k serveru 2. Budiž. pokud tohle vím, tak ochrana tím, že jsem jen na jednom serveru, významně zvýší šanci, že se nic nestane. Na druhou stranu třeba monitoring, který ven ze systému hlásí všechny loginy včetně pokusů nebo dokonce audit, který loguje a hlásí všechny příkazy, které se na systému provedou, tě pravděpodobně upozorní, když by se něco dělo, co se dít nemá. Nebo můžeš si systém postavit tak, že máš jeden systém (1) jako vstupní bránu, tam je jen holý systém a ssh server a teprve z něj se připojuješ dále do skutečně řízeného systému včetně potřebných tunelů (2) a potřebuješ na spojení informace, které na tom systému 1 nejsou a pošleš je vždy znovu po tom spojení. Takový systém, když má společně definovaný monitoring vstupu a audit příkazů, je vysoce obtížně zlomit tak, aby neposlal žádnou zprávu. Takže když se na něj přípojíš, víš že je bezpečný. Když se dál připojíš nějakým spojením třeba na IPv6 Unique Local Address, tak nikdo adresu není schopen najít scanováním, jenom ji může odchytit, když má přistup do LAN. Zaleží kolik paranoi potřebuješ. Asi na všechno se dá najít situace, kdy je to nedostatečné. A ším více prostředků člověk použije, tím více vymění pohodlí za bezpečnost.

[Jendа]

a současně v průběhu práce (nebo možná krátce předtím aby klíče zůstaly v io bufferech) se také zaloguji na jiný ssh server klíčem, tak útočník ze serveru 1 může mi ukrást klíče k serveru 2

Ne. Útočník ti může ukrást ten klíč, kterým se přihlašuješ k tomu jeho serveru. A většina lidí má samozřejmě svůj klíč na víc serverech, takže se pak útočník může přihlásit i na tyto ostatní servery.

Na druhou stranu třeba monitoring, který ven ze systému hlásí všechny loginy včetně pokusů

Po ukradení klíče to přihlášení bude vypadat zcela regulérně, asi bys to mohl chytit jenom tak, že by ses koukal na jeho čas a psal si, kdy se tam opravdu přihlašuješ.

nebo dokonce audit, který loguje a hlásí všechny příkazy, které se na systému provedou

Hmm, jo. Ale existuje vůbec pro Linux takový auditovací soft? Nejde totiž jen o příkazy, ale i třeba o SFTP přenosy.

Zaleží kolik paranoi potřebuješ.

A kolik použitelnosti…

[petrfm]

Ono by se to asi dalo resit zaslanim emailu o kazdem prihlaseni, s tim, ze bych danou schranku mel pristupnou treba na smartphonu. Prihlasim se, pipne mi email, ignoruju. Kdyz mi pipne email, aniz bych se prihlasoval, neco se deje.

Ale, ruku na srdce, neda se to obejit? A nemuze utocnik vyuzit zase nejakou jinou diru, diky ktere se prihlasi do systemu, aniz by to bylo jakkoliv zjistitelne? Druha vec je, zda vubec tusi, ze mi tam neco takoveho bezi a az to zjisti, uz je pro nej pozde, protoze vim, ze nekdo prekonal SSH a jsem schopen zalogovat kdy a kdo.

Nejaky tip na takovy hlidaci script ?

BTW : neni potom SFTP bezpecnejsi reseni, nez treba samba? A pkud chci napr. datove uloziste dostupne odkudkoliv, s co nejmensi mirou rizika, ze se k datum dostane i nekdo jiny, pak pouzivat pro pristup z venku pouze SSH a sambu si zablokovat pouze na IP z rozsahu vnitrni site.

[lertimir]

Ale, ruku na srdce, neda se to obejit? A nemuze utocnik vyuzit zase nejakou jinou diru, diky ktere se prihlasi do systemu, aniz by to bylo jakkoliv zjistitelne? Druha vec je, zda vubec tusi, ze mi tam neco takoveho bezi a az to zjisti, uz je pro nej pozde, protoze vim, ze nekdo prekonal SSH a jsem schopen zalogovat kdy a kdo.

Tím co povolíš, definuješ i kanály, které může útočník použít. Třeba se můžeš rozhodnout, že použiješ jen SSH, tak že veškeré další věci jedou jen na localhost a musíš si vše ostatní připojovat jen přes ssh tunely. A pak na SSH to uřídíš (když nebude využita 0-day), logováním.

[lertimir]

Na druhou stranu třeba monitoring, který ven ze systému hlásí všechny loginy včetně pokusů

Po ukradení klíče to přihlášení bude vypadat zcela regulérně, asi bys to mohl chytit jenom tak, že by ses koukal na jeho čas a psal si, kdy se tam opravdu přihlašuješ.

Myslím tím něco, čím se v jednoduché formě např hlási googlí účet. Když si pustíš nového klienta na nějakém zařízení a zkontaktuješ gogolí účet imapem. tak ti na záložní email přijde vyrozumění o novém přihlášení z nějakého nového zařízení. Pokud budu na systému paranoidní, tak si dokážu představit, že si nastavím, že mi systém pošle email, kdykoliv se někdo úspěšně přihlásí z nové IP adresy, a těch pár mailů denně, které budou mé skutečné přihlášení mi vadit nebude. (i když teď okamžitě nevím přesně jak bych to nakonfiguroval a asi to bude chtít ruční práci.)

nebo dokonce audit, který loguje a hlásí všechny příkazy, které se na systému provedou

Hmm, jo. Ale existuje vůbec pro Linux takový auditovací soft? Nejde totiž jen o příkazy, ale i třeba o SFTP přenosy.

Myslím že auditd to umí. a audisp-remote audit pošle na jiný stroj. Niméně nikdy jsem to nekonfiguroval.

Zaleží kolik paranoi potřebuješ.

A kolik použitelnosti…

Ano to jsou dvě strany jedné mince.

[R]

Pouzivajte na prihlasovanie heslo a nie kluce :D

BTW. Kedysi davno som niekde nasiel skript na nastavenie prihlasovanie klucom. Trochu som si ho upravil a pouzivam. Pre kazdy server generuje novy kluc.

[Lol Phirae]

Nekrmit trolly a kokoty.

[petrfm]

Ale, copak, držíš dietu? Jako největší ko*ot se tu totiž projevuješ už delší doby ty

[Conscript89]

Tak proc pises Linux a ne linuxove distribuce?

[leste]

Kecáš. Já ve Windows ssh používám. Denně.

[pavlix]

OpenSSH?

[pako]

Nevím jak leste, já ano (Cygwin).