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

[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).