Jaderné noviny – 19. 10. 2017: unsafe_put_user() se ukazuje býti skutečně nebezpečné

1. 11. 2017 | Redakce | Jaderné noviny | 3584×

Stavy vydání jádra. Objasnění vymáhání licence ze strany jaderné komunity. Citát týdne: Linus Torvalds. unsafe_put_user() se ukazuje býti skutečně nebezpečné.

Stav vydání jádra

Současné vývojové jádro je 4.14-rc5, vydané 15. října. Linus řekl: „Rozhodně jsme měli menší, ale taky větší rc5 a tenhle týden konečně vypadal trochu normálně, když už tohle vydání bylo až do teď divočejší, než by asi mělo být. Takže pokud budu předpokládat, že se tento trend udrží, všechno bude v pořádku. Zaklepu to na dřevo.“

Seznam regresí z 15. října čítá devět známých problémů v cyklu 4.14.

Stabilní aktualizace: 4.13.6, 4.9.55, 4.4.92 a 3.18.75 byly vydány 12. října. Ihned poté je následovala 4.9.56 opravující chybu v síťování, která proklouzla do 4.9.55. Potom 14. října vyšla 4.13.7 vyšla s důležitou bezpečnostní opravou (viz článek níže). A konečně 4.13.8, 4.9.57, 4.4.93 a 3.18.76 vyšly 18. října.

Objasnění vymáhání licence ze strany jaderné komunity

V reakci na obavy, týkající se zneužívání vymáhání licencí kolem jádra, dala Linux Foundation Technical Advisory Board dohromady tento patch, který do jádra přidává dokument vysvětlující jejich postoj k vymáhání licencí. Tento dokument byl podepsán nebo odkývnut velkým počtem jaderných vývojářů. Zvláště usiluje o omezení účinku „trestu smrti kvůli GPLv2“ konstatováním, že porušená licenční smlouva nabude opět platnosti návratem k dodržování jejích podmínek. „Právní kroky považujeme za poslední možnost, na kterou dojde pouze v případě, kdy selžou jiné prostředky komunity o vyřešení problému. Jakmile se podaří problém s nesouladem vyřešit, bude se daný uživatel moci připojit k naší práci na tomto projektu. Společně budeme silnější.“

Více informací najdete v tomto zápisku Grega Kroah-Hartmana.

Citát týdne

Další věc, která stojí za zmínku, je, kolik náhodného fuzzingu lidi dělají a kolik se toho daří najít. Fuzzing jsme dělali vždycky (kdo si pamatuje starý program „crashme“, který generoval náhodný kód a skákal na něj? Zpočátku jsme to dělali docela dost), ale lidé dělají dobrý cílený fuzzing v subsystémech ovladačů apod., díky těmto snahám se podařilo najít různé opravy (nejen minulý týden). Je radost se na to dívat.

—Linus Torvalds

unsafe_put_user() se ukazuje býti skutečně nebezpečné

unsafe_put_user() turns out to be unsafe. Jonathan Corbet. 13. říjen 2017

Když veterán jaderného vývoje zanese závažnou bezpečnostní díru do jádra, může být poučné se podívat, odkud se příslušná zranitelnost vlastně vzala. Mimo jiné může ukázat prstem na API, kterému se takové problémy daří vytvářet. A jak se ukázalo, samotná vědomost, že API je nebezpečné, a jeho označení za nebezpečné nemusí k zabránění problémům stačit.

Koncem roku 2015 se vývojáři snažili vymyslet způsob, jak urychlit pohyb dat mezi uživatelským a jaderným prostorem. Přístup k uživatelským datům z jádra, ať už z důvodu čtení nebo zápisu, má jasné bezpečnostní důsledky, takže se jádro musí ujistit, že požadovaný přístup je něco, na co má žadatel právo. To znamená ověřit, zda je určená oblast paměti skutečně přístupná. Na novějším hardwaru to může také vyžadovat dočasné vypnutí mechanismů jako např. ochrana proti přístupu supervizora (SMAP). Tyto přípravy jsou v porovnání s obyčejným kopírováním dat drahé a mohou se nasčítat v případě, že jádro musí vykonat sekvenci několika čtení či zápisů do uživatelského prostoru.

Zjevným řešením je provést přípravy skupiny operací najednou a potom provést přímo tyto operace samotné. Tím se dá dosáhnout rozložení ceny jedné skupiny kontrol na více přístupů. Za tímto účelem přidal Linus Torvalds do jádra 4.5 novou sadu přístupových funkcí:

unsafe_get_user(value, source);
unsafe_put_user(value, destination);

Tyto „funkce“ jsou ve skutečnosti makra, která se expandují různě – v závislosti na typu source nebo destination. Pokud je například source ukazatel na hodnotu u16, pak volání unsafe_get_user() z daného umístění získá bezznaménkovou 16bitovou hodnotu a uloží ji v value. Tyto funkce tedy odpovídají tradičním makrům get_user() na put_user(), ale s jednou změnou: zbavují se obvyklé kontroly oprávnění.

Absence kontrol je jasným důvodem k pojmenování „unsafe“, ačkoliv podle komentářů v kódu tento termín ve skutečnosti neplatí:

/*
 * The "unsafe" user accesses aren't really "unsafe", but the naming
 * is a big fat warning: you have to not only do the access_ok()
 * checking before using them, but you have to surround them with the
 * user_access_begin/end() pair.
 */

Vyžadované volání access_ok() zajistí, že příslušný ukazatel odkazuje na adresu uživatelského prostoru – jeho smyslem je zabránit uživatelskému prostoru chtít po jádru, aby přepsalo samo sebe. Volání user_access_begin() a user_access_end() zakazují a povolují SMAP. Myšlenka „nebezpečných“ spočívá v tom, že volání access_ok() a (zvláště) user_acess_begin() stačí před několika přístupy do uživatelského prostoru zavolat jednou, čímž se urychlí kód jako celek.

Během začleňovacího okna 4.13 Al Viro přepracoval implementaci systémového volání waitid() tak, aby se používaly „nebezpečné“ funkce. Tato varianta wait() vyžaduje, aby jádro strukturu signinfo_t v uživatelském prostoru naplnilo informacemi o tom, jak zanikl proces, na který se čekalo. To vyžaduje zápis několika hodnot z jádra do uživatelského prostoru. Nový kód přešel za účelem zrychlení těchto zápisů na unsafe_put_user(). Viro řádně volal user_access_begin() a user_access_end(), ale vynechal volání access_ok(). V důsledku toho mohlo volání waitid() požádat, aby struktura signifo() byla uložena v jaderném prostoru, čímž došlo k přepsání kusu paměti jádra. Lokální útočníci mívají z takového druhu neúmyslného chování většinou radost.

Výsledek se označuje jako CVE-2017-5123 a postihuje pouze jádra 4.13 a 4.14-rc. Chybu opravuje tento commit v hlavním repozitáři a dostane se do aktualizace stabilního větve 4.13.7. Dobrou zprávou je, že se na to přišlo brzy, a tak by měl být počet postižených strojů celkem malý.

Špatnou zprávou samozřejmě je, že k tomu vůbec došlo. Ukázalo se, že šlo o první případ použití unsafe_put_user() v hlavním repozitáři jádra. Napsal ho vývojář, který rozumí příslušným problémům, a stejně to udělal špatně. Co je horší, tento patch odhalil chybu v dosud nevyužité funkci, na konkrétní patch se podíval Torvalds, ale ani tak si problému nikdo nevšiml. Zdálo by se, že – komentářům navzdory – jsou „nebezpečné“ funkce skutečně pojmenované dobře, ale opravdu nebezpečné použití lidi, kteří se na kód dívají, netrkne – i když o sobě samy funkce hlásají, že jsou nebezpečné.

Doufejme, že recenzenti budou v budoucnu lépe srozuměni se skutečností, že k použití těchto funkcí jsou nezbytné dva předpoklady. Ještě lepší by byl nějaký kód běžící v jádrech konfigurovaných na ladění, který by detekoval absenci kontrol a spustil alarm. Mohlo by také být možné aplikovat určitý typ statické kontroly. Bez takové pomoci je možné, že se podobná chyba v budoucnu dostane do jádra znovu, ale tentokrát se na ni nepodaří přijít tak rychle.

       

Komentáře

[Petr Tomášek]

Prosímvás, nechtěl byste to někdo přeložit do češtiny?

[FfFAF]

co nechapes?

[Petr Tomášek]

Nechápu, jak zdejší redakce může nechat „překládat“ jakéhosi neumětele, kdo neumí ani česky ani překládat.

Namátkou:

Zaklepu to na dřevo

šroubované formulace typu:

týkající se zneužívání vymáhání licencí kolem jádra

nebo:

nemusí k zabránění problémům stačit.

dále:

vědomost, že API je nebezpečné

(Asi bylo míněno „povědomí o tom“. „Vědomost“ je opravdu něco jiného...)

A hlavně spousta naprosto šíleně dlouhých souvětí...

Celkově se to velmi blbě čte a je to moc šroubované. Osobně je pro mně jednoduší si to přečíst v originále než tady.

[Filip Jirsák]

Zaklepu to na dřevo

Zrovna tohle je ale správně, i když už se dnes často používá varianta „zaklepat na dřevo“, protože lidé nevědí, z čeho to pochází.

[Bystroushaak]

Nechápu, jak zdejší redakce může nechat „překládat“ jakéhosi neumětele, kdo neumí ani česky ani překládat.

No a přeloží to někdo jiný líp? Pokud jo, proč už to nepřekládá? Že by nikdo takový nebyl?