Vlákno názorů k článku
Zveřejněn exploit na chybu v glibc
od luky - Funguje to jen pokud uzivatel ma pravo spoustet...
-
Tato zprávička moc popis neřeší, odkazuje se na předchozí zprávičku. Z té mi (při troše zamyšlení a znalosti, co je glibc) přijde zjevné, že ke zneužití potřebuju být schopen nastavit proměnnou prostředí nějaké binárce, která poběží s oprávněním, které jinak nemám*. Tedy typicky něco se suid bitem. Tedy typicky sudo, někdy
třeba dumpcap.
Ano, šlo to asi napsat explicitněji.*) V opačném případě je to jako vloupat se do dveří, ke kterým mám klíče.
-
Filip JirsákStříbrný podporovatelNikoli.
sudose používá právě k tomu, abyste mohl na někoho delegovat jednu nebo pár činností, ke kterým je jinak potřeba oprávnění roota, a nemusel jste dotyčnému dát všechna rootovská oprávnění.
To, že si v Ubuntu kdysi řekli, že používatsuje přece nebezpečné, a místo toho začali používatsudobez omezení, to je jiná věc. Ale stále je dobré rozlišovat, že když se napíšesudo, myslí se tímsudos omezením, jaký program smí dotyčný spouštět. A když se smí dotyčný převtělit na roota, nazývat tosu. -
Nezkoušel jsem, ale podle popisu bych řekl, že ano:
1. Uživatel spustí sudo.
2. Binárka sudo natáhne glibc.
3. Knihovna glibc zpracuje GLIBC_TUNABLES.
4. Teprve poté se sudo pokouší zpracovat sudoers.Ke zneužití zranitelností dojde už v kroku 3, ke zpracování sudoers (a následnému odmítnutí) už ve kroku 2.
-
Filip JirsákStříbrný podporovatel
Díky. Uniklo mi, že jde o proměnnou GLIBC_ a že ji tedy nejspíš glibc zpracovává vždy, když je knihovna použita.
-
Pro jistotu jsem ještě hledal, k čemu ta proměná vlastně slouží. Mj. umožňuje nastavit nějaké vlastnosti alokátoru. Hádám, že se to bude řešit ještě před voláním main. Případně při prvním volání Málkov či jiné funkce, jejíž chování to ovlivní.
BTW, na GLIBC_TUNABLES mě až tak neznepokojuje to, že měli chybu ve zpracování, jako spíš to, že se to zpracovává I u SUID binárek. To je volba pro ladění, ne pro produkci, a tuším, že její pečlivé nastavení může umožnit zneužití některých chyb.
-
Filip JirsákStříbrný podporovatel
No jo, jenže porovnání effective uid a real uid by byl zase další kód, ve kterém může být chyba. A co by vlastně měl být ten důvod, proč nepoužít GLIBC_TUNABLES – že se liší? Nebo že effective uid je 0 a real uid ne?
Podle mne je problém spíš v tom, že se tolik věcí řídí přes proměnné prostředí, nad kterými nemůžete mít žádnou kontrolu. Ale glibc nemá moc jiných možností, odkud si něco přečíst, aniž by to zároveň neovlivnilo jiné procesy.
-
Tak ve všem lze udělat chybu, ale porovnání dvou čísel (+možná totéž pro GID) může být celkem silné řešení. Neřešil bych porovnání s nulou, root je u SUIDu jen jedna z možností. Takže nejspíš real ≠ effective.
A v neposlední řadě by tento relativně jednoduchý kód (ve kterém samozřejmě může být chyba) zabránil použití mnohem složitějšího kódu (nejen parsování proměnné, ale taky další chování na základě jejího obsahu), ve kterém bude nejspíš chyb mnohem víc.
Při psaní aplikací určených pro SUID je potřeba opatrnosti. Některé proměnné prostředí (LD_PRELOAD?) se ignorují automaticky, na jiné jiné (možná PATH) je potřeba si dávat pozor. Automaticky ignorovat GLIBC_TUNABLES mi smysl dává, stejně to není určeno k běžnému použití.
Proměnné prostředí samy o sobě problém nejsou, kromě několika případů:
a. Bezhlavé zpracování všech proměnných (zdravím Bash a Shellshock)
b. SUID binárky – tam, kde u běžných binárek není prostor k útoku (útočník by získal leda to, co už stejně má), je situace u SUID binárek mnohem komplikovanější.
c. Možnost nastavit příliš široký rozsah proměnných – u úplně univerzální možnosti je asi zjevné,něco je špatně (lze nastavit třeba LD_PRELOAD), ale IIRC některý CGI software nastavoval env podle hlaviček prefixovaných „http_“, a pak šlo některému softwaru nastavit „http_proxy“.
