Jaderné noviny – 29. 1. 2015: Zranitelnost načítání šifrovacích modulů

18. 4. 2015 | Redakce | Jaderné noviny | 2810×

Stav vydání jádra. Citáty týdne. Zranitelnost načítání šifrovacích modulů.

Stav vydání jádra

Aktuální verze jádra: 3.19-rc6

Aktuální vývojové jádro je 3.19-rc6, vydané 25. ledna.

>Stabilní aktualizace: Stabilní verze jádra 3.18.4, 3.14.30 a 3.10.66 byly vydány 27. ledna. V revidování jsou tři stabilní jádra: 3.18.5, 3.14.31, and 3.10.67. Dají se očekávat 30. ledna, možná ještě před tímto datem.

Citáty týdne:

„A protože proklínám lidi, kteří ignorují nahlášené regrese s odůvodněním "opravuje to chybu", měl bych si udělat čas a říci vám, jak rád vidím, když vysvětlujete lidem, kteří regresi nahlásili, proč se to stalo a jaké vás k tomu vedly důvody. *Takhle* by to mělo fungovat. "Moje chyba, tohle byl důvod, proč jsem si myslel, že je to dobrý nápad.“

- Linus Torvalds

Faktem je, že jsou to ty nejmenší vestavěné systémy, které **obzvláště** potřebují silné šifrování. Bylo by... nešťastné.. kdyby se, až se příště Severní Korea naštve na Velkého Satana, všechny naše žárovky, ledničky, auta, topení, atd, staly objektem útoku.

- Ted Ts'o

Zranitelnost načítání šifrovacích modulů

Vkládání modulu do běžícího jádra je poměrně invazivní, proto je tato operace několika způsoby omezena. Ve většině případů vyžaduje načtení modulu práva roota (nebo schopnost CAP_SYS_MODULE), ale existují i výjimky. Některé moduly se načtou automaticky, jakmile dojde k připojení nového hardwaru nebo souborového systému či když je zapotřebí nového kryptografického algoritmu jádra. V tomto posledním případě však neoprávnění uživatelé mohou kterýkoli modul z knihovny načíst využitím díry v krypto subsystému, tedy až donedávna.

Tento nedostatek objevil před téměř dvěma roky Mathias Krause, když ve vláknu poukázal na podobný bug spojený s mountováním a uživatelskými jmennými prostory. Tehdy šlo o to, že root v uživatelském jmenném prostoru (který mohl být běžným uživatelem v nejvyšším jmenném prostoru) mohl připojit souborový systém za pomoci možnosti -t (type) a přidat modulu libovolný název jako parametr. To způsobovalo, že jádro načetlo modul, i když nešlo o souborový systém. Krause poznamenal, že totéž se týkalo kryptografického subsystému.

Problém s připojením byl opraven krátce poté, co byl nahlášen, ale oprava kryptografické chyby očividně proklouzla. Ani jedna z těchto chyb neumožňovala neoprávněným uživatelům nahrát libovolné (tedy útočníkem ovládané) moduly, což by byl daleko větší problém. I tak možnost nahrávat neočekávané moduly ze standardního umístění (běžně /lib/modules) může vést k různým zranitelnostem, včetně zvýšení úrovně oprávnění - v podstatě ke kompromitování celého systému.

Vzhledem k tomu, že moduly jádra mají k jádru blízký přístup, docházelo v minulosti ke zneužívání těchto chyb v zabezpečení. Ale pokud si administrátor myslí, že běžný uživatel nemůže nahrávat konkrétní moduly, mohl by být méně ochotný aktualizovat jádro k vyřešení problému zdánlivě nedůležitého modulu. Také existuje nebezpečí neznámých či zero-day chyb v zabezpečení. Riziko těchto chyb může být velmi malé, ale i tak je nahrávání modulů do jádra vyhrazeno jen některým uživatelům.

Obvyklou opravou (která byla aplikována pro souborový systém) je navodit jméno modulu uživatele specifickým textovým řetězcem; pro souborové systémy se používalo„fs-“. Všechny souborové systémy, které mohou být postaveny jako moduly, dostanou MODULE_ALIAS(), s použitím prefixu. Požadavek pro request_module byl upraven, aby předcházel prefixu, což znamená, že jádro již nebude nahrávat jakýkoli modul jako souborový systém, ten by již skutečně musel být modulem souborového systému.

Je zřejmé, že stejné schéma může být aplikováno na šifrovaný subsystém, toto řešení však má několik zádrhelů, jak už ostatně Kraus uvedl ve svém příspěvku na G+. Za prvé, chyba v zabezpečení je o něco snadněji přístupná než mount a chyba jmenného prostoru. Každý user-space program, který se váže k socketu AF_ALG (který uživatelskému prostoru poskytuje netlink rozhraní k šifrovacímu subsystému), může určit typ šifry, kterou chce použít. Pokud vybraná šifra není k dispozici, pokusí se jádro šifru daného jména načíst. Vzhledem k tomu, že neexistuje omezení pro jméno, bude každé jméno modulu schváleno a bude načteno.

Úprava všech šifrovacích algoritmů, které mohou být sestaveny jako moduly přidáním „šifrovací“ předpony a změnou kódu pro načítání modulů, je zřejmou cestou kupředu. Změnu provedl Kees Cook, ale s opravou nastal problém. Kryptografické šifry mohou také určit mód, takže šifra AES v ECB (electronic codebook) by byla také specifikována jako „ecb(aes)“. Cookova původní oprava by umožnila, aby byl kterýkoli modul upřesněn v režimu (např. vfat(aes) a načten.

To vedlo Cooka ke druhé opravě, která ovšem postrádala některé potřebné kryprografické aliasy. Ty dodal až Krauseův patch.

I tak se v tomto procesu ještě podařilo najít chybu (nesouvisela s jádrem). Jádro převádí načítání modulů nástroji uživatelského prostoru modprobe, který najde modul, načte ho a použitím funkce init_module() jej načte do jádra. Vyšlo najevo, že Krause pro testování patche používá příkazový procesor BusyBox. Objevil to, že modprobe procesoru BusyBox efektivně využívá kořen názvu modulu, který zpracovává, což znamená, že všechno až po poslední „/“ je ignorováno. Žádost o /vfat se změní na žádost o „šifrovaný /vfat“, ale modprobe BusyBoxu první část klidně ignoruje a načte modul vfat, což nás přivádí opět na začátek.

Tento problém postihl nejen šifrování (Krause ve skutečnosti v zprávě chyb šifrování ani nezmiňuje, zřejmě proto, že ještě nedošlo ke sloučení Cookových oprav). Povšiml si ještě dvou příkazů, které nahrávaly moduly, když neměly:

    # ifconfig /usbserial up
    # mount -t /snd_pcm none /

V obou případech je prefix použit („netdev-“ a „fs-“), ani nedošlo k žádným komplikacím, ale BusyBox je celkem úspěšně ignoroval. Správce BusyBoxu, Denys Vlasenko chybu opravil hned druhý den poté, co ji Krause nahlásil.

Zpočátku docházelo ke komplikacím, ale jak Krause poznamenal, tyto chyby jsou nyní odstraněny:

Celkově vzato vedla prvotní připomínka k jinak nesouvisejícímu LKML vláknu k nedostatečné opravě, která, když byla testována, odhalila svou nedostatečnost a ještě další chybu v úplně jiném kódu. Tomu říkám hezká oprava chyb;)

Chyba v jádru se vyskytovala od roku 2011, kdy bylo zavedeno rozhraní AF_ALG ke šifrovacímu subsystému ve verzi 2.6.38. Chybám byla přiřazena tři samostatná čísla CVE: CVE-2013-7421 pro původní chybu, na kterou Krause upozornil v roce 2013, CVE-2014-9644 pro variaci „vfat(aes) a CVE-2014-9645 pro chybu modprobe BusyBoxu. Opravy jádra jsou součástí hlavních aktualizací a budou vydány ve verzi 3.19; Dá se očekávat také podpora stabilních jader.

I když se nejedná o kritickou chybu, nedoporučuje se ponechávat neautorizovaným uživatelům možnost pohrávat si s útrobami jádra. Chyba i tak zůstávala nevyřešená po dva roky od svého objevení, což je celkem překvapivé. Zakázat nahrávání modulů (ať už při bootování či konfiguraci jádra) je jednou z možností, kterak zmírnit hrozbu, příliš se však nehodí pro některé typy systémů (hlavně pro desktopy a laptopy).

       

Komentáře

[Petr Tomášek]

Překladateli, cos zas hulil? To musí bejt fakt kvalitní matroš, to se jen tak nevidí...

[petr_p]

na podobný bug

oprávnění - v podstatě

navodit jméno modulu uživatele specifickým textovým řetězcem

dostanou MODULE_ALIAS(), s použitím prefixu

přístupná, než mount

Jádro převádí načítání

který zracovává

A nakonec tahle červená citací je ve tmavém stylu podivně kontrastní (asi jako červená na modré), takže se nedá číst.

[Filip Jirsák]

„A protože nadávám na lidi, kteří ignorují regresní zprávy, protože „opravují chybu“ měl bych si udělat čas na to říct, jak se mi líbilo vidět vás, jak vysvětlujete lidem, kteří tuto regresi oznámili, jak se to stalo a jaké bylo uvažování. Takhle by to mělo fungovat. Kvůli tomu jsem měl pocit, že to byl dobrý nápad, moje chyba.“

Četl jsme to česky třikrát, a stejně jsem to nepochopil. Přitom v originálu to nijak zamotané není.

A protože proklínám lidi, kteří ignorují nahlášené regrese s odůvodněním "opravuje to chybu", měl bych si udělat čas a říci vám, jak rád vidím, když vysvětlujete lidem, kteří regresi nahlásili, proč se to stalo a jaké vás k tomu vedly důvody. *Takhle* by to mělo fungovat. "Moje chyba, tohle byl důvod, proč jsem si myslel, že je to dobrý nápad."

[logik]

Trochu nechápu, jak pomůže nahrávání pouze modulů se speciálním prefixem: pokud budu chtít jádro kompromitovat vlastním modulem, co mi brání u toho modulu dát patřičný prefix?

[Jendа]

Musíš ten svůj modul dostat do /lib/modules.

[logik]

Jasně, ale to jsem před úpravou musel také, ne?

[Petr Tomášek]

man insmod

[Jendа]

insmod: ERROR: could not insert module aes-jenda.ko: Operation not permitted

[Filip Jirsák]

Myslím, že to neřeší případ, kdy můžete jádru podstrčit vlastní modul. Řeší to případ, kdy v systému je modul, který může nahrát jen správce - ale tahle chyba to umožňovala obejít a nahrání modulu mohl vyvolat i běžný uživatel.

[logik]

Jo, to je asi pravda, ale zas využít tohoto k nějaký zranitelnosti si moc neumím představit. Nicméně díra to je, to jo.

[Filip Jirsák]

Může jít třeba o ovladač nějakého hardwaru. Třeba to může být samostatný počítač, který nemá nahraný modul pro síťovou kartu a pro flash disky, aby nijak nemohl komunikovat se světem. Pouze když je potřeba aktualizace, správce nahraje příslušný modul, provede aktualizaci, a modul zase odpojí. Jistě že by bylo lepší fyzicky znemožnit připojení USB a síťového kabelu, ale třeba někde to řešení s moduly může stačit (když funguje).

[R]

Alebo moze ist o lubovolny modul, ktory ma nejaku zneuzitelnu bezpecnostnu dieru.

[Jendа]

Realističtější mi přijde třeba nějaký špatně napsaný driver HW, který vytvoří zařízení, nad kterém nějaké uživatelské IOCTL způsobí buffer overflow v jádře. Každopádně to asi není úplně běžný use-case.

[Filip Jirsák]

Tam nějak nevidím souvislost s tou chybou. Pokud je v nějakém modulu chyba, je nebezpečný bez ohledu na to, jakým způsobem se do jádra nahraje.

[Jendа]

Jasně, ale zatímco na většině počítačů nebude nahraný děravý modul pro USB kávovar a útočník proto utře nos, v případě existence takovéto chyby si ho útočník může nahrát.

[Michal Kubeček]

Úrčitá forma DoS se dá způsobit i modulem, který je naprosto v pořádku, např. v případě konfliktních modulů natažení jednoho znemožní (automatické) natažení druhého. Nebo mne napadá třeba ixgbevf, který způsobí, že VF budou místo VF vidět jako normální rozhraní, s čímž konfigurace nemusí počítat (pak sice bývá zvykem ho blacklistovat, ale nějaký corner case tohoto typu by se nejspíš našel).