Názory k článku
Zveřejněn exploit na chybu v glibc
-
-
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“. -
DannyStříbrný podporovatelprvni PoC se objevily uz predevcirem...
https://github.com/leesh3288/CVE-2023-4911
https://github.com/RickdeJager/CVE-2023-4911 -
msmucrBronzový podporovatelVíceméně všechny systémy (RHEL, Debian based..), co někde provozuji, už mají vydanou a naaplikovanou opravu. Co mi přišlo zajímavé, že u SUSE je oprava jen pro OpenSUSE Tumbleweed. OpenSUSE Leap a SLES tím nejsou postižené, přestože mají aktuálně stejnou verzi glibc jako Debian 11.
https://www.suse.com/security/cve/CVE-2023-4911.htmlZatím jsem to víc nezkoumal ze zdrojových balíčků, a upřímně jsem glibc tunables nikdy nepoužíval, ale pravděpodobně to už řeší nějaký jejich jiný patch nebo build option.
-
- tak a jak je na tom CentOS Stream ve srovnání s klony:- AlmaLinux 9 - released: 06.10.2023 - ALSA-2023-5453
- AlmaLinux 8 - released: 05.10.2023 - ALSA-2023-5455
- Rocky Linux 9 - released: N/A - N/A
- Rocky Linux 8 - released: 10.7.2023 - RLSA-2023:5455
- CentOS Stream 9 - released: N/A - N/A
- CentOS Stream 8 - released: N/A - N/A
- RHEL 9 - released: 05.10.2023 - RHSA-2023:5453
- RHEL 8 - released: 05.10.2023 - RHSA-2023:5455
viz RH cve-2023-4911
Nechci CentOS Streamům křivdit, protože jsem danou zranitelnost na posledních verzích glibc přímo netestoval, ale v changelogu u balíčků o fixu není ani zmínka. Na druhou stranu poslední verze glibc obsahují dle changelogu opravy pro CVE-2023-4527 a CVE-2023-4813, které jsou součástí výše uvedených SA. Tak třeba jen někdo zapomněl aktualizovat changelog.
Navíc podobná stránka s ERRATA CentOS Streamu opravdu chybí... člověk se jednoduše nedozví o vydaných balíčcích a hlavně security fixech...
Takže v clonových válkách v tomto směru a v tomto případě za mne vede Alma... držím palce a jen tak dál.
9. 10. 2023, 21:12 editováno autorem komentáře
-
msmucrBronzový podporovatel
U toho Rocky Linux 9 je to tak, jak píšete. Nejspíš tam opomněli aktualizovat erratu na webu, protože balíček s aktualizací je už pár dní k dispozici. Na některých serverech s RL 9 používám dnf automatic, a tam se mi to podle logu aktualizovalo v pátek ráno a build date je ještě o den dřív.
Balíček glibc v Oracle Linux má kombinaci jejich a upstream patchů, tam to bylo už ve středu.
RHEL 9 samotný to pak měl ještě dříve.
CentOS Stream to opravdu doteď nemá, a proof of concept na https://www.qualys.com/2023/10/03/cve-2023-4911/looney-tunables-local-privilege-escalation-glibc-ld-so.txt to opravdu sestřeluje, takže pokud to chce někdo řešit bez vlastního buildu, tak nezbyde než použít systemtap viz.
https://access.redhat.com/security/cve/cve-2023-4911
ČLÁNKY DO MAILU