Názory k článku
Chyba v sudo umožňuje navýšení práv, stačí jako UID nastavit -1 nebo 4294967295
-
Nejen. Lze to zneužít i pokud neznáte heslo uživatele, za kterého jste přihlášeni. Tedy pokud útočník získá práva běžného uživatele, nezná jeho heslo, ale tento je uveden v sudoers, může útočník povýšit svá práva na roota.
Je to další vektor pro útočníky, jak poměrně snadno povýšit svá práva na roota. Má však určité podmínky (proto pravděpodobně není hodnocen 9+).
(viz https://access.redhat.com/security/cve/cve-2019-14287)
CVSS v3 Base Score 7.8
Attack Vector Local
Attack Complexity Low
Privileges Required Low
User Interaction None
Scope Unchanged
Confidentiality High
Integrity Impact High
Availability Impact High -
Osobně se snažím hledat cesty, jak nemít potřebu měnit, natož eskalovat práva. Většinou to jde vyřešit, ale je pravdou, že současné distribuce nejsou příliš "nakloněny" dokonale promyšlené segregaci oprávnění a separaci dat. Pak už bohužel nezbývá, než využít sudo.
Je to další důvod, proč mi velmi vyhovuje FreeBSD, kde téměř každý program v rc.conf může mít určeného uživatele a není potřeba se spoléhat na to, že to autoři vymysleli dobře. Pokud to jde, mohou běžet v jailu. Na ZFS dojde k deduplikaci base systemu (jednorázově při vytváření / aktualizaci jailu), takže stopa na disku je minimální, výkonový propad je takřka nulový. Tím se dá dost efektivně zbavit nutnosti sudo.
Sudo je totiž jen ohejbák na nedokonalost oprávnění v unixu, bohužel je to ohejbák až příliš mocný a s komplikovanou konfigurací (viz jen parametry, které se v sudoers dají nastavit).
Tato chyba je OBROVSKÝ ÚLET, kdyby se něco podobného podařilo Microsoftu, byl by v diskusích pranýřován dalších deset let.
-
> Sudo je totiž jen ohejbák na nedokonalost oprávnění v unixu, bohužel je to ohejbák až příliš mocný a s komplikovanou konfigurací (viz jen parametry, které se v sudoers dají nastavit).
Tohle uplne nechapu.
Ja napriklad pro zabbix agenta mam nasledujici sudo config:zabbix ALL=NOPASSWD: /sbin/iptables -S zabbix ALL=NOPASSWD: /usr/bin/apt-get update zabbix ALL=NOPASSWD: /usr/bin/apt-get -su upgrade zabbix ALL=NOPASSWD: /usr/sbin/repquota /
Takze uzivatle zabbix si muze pouze vypsat iptables pravidla, zjistit stav quoty pro vsechny uzivatele, aktualizovat cache balicku a vypsat pocet balicku k instalaci.
Jak to vyresim bez sudo? Necham bezet zabbix agent pod rootem (nikdy)? Nebo nastavit suid bit na celou binarku iptables a apt-get a kazdy uzivatel si bude moct delat, co chce?
Jak mi tady pomuze, kdyz by program (iptables je spatny priklad) bezel v chrootu a pod samostatnym uzivatelem?
>Tato chyba je OBROVSKÝ ÚLET, kdyby se něco podobného podařilo Microsoftu, byl by v diskusích pranýřován dalších deset let.
S tim naprosto souhlasim.
Ale sudo neni spatne. -
Takze uzivatle zabbix si muze pouze vypsat iptables pravidla, zjistit stav quoty pro vsechny uzivatele, aktualizovat cache balicku a vypsat pocet balicku k instalaci.
Pokud bych toto řešil, cronem roota bych vypisoval výstup do souboru, který by zabbix zpracovával. Tím oddělíte oprávnění, že ani při velké chybě v konfiguraci nemůže zabbix vyvolat nic za roota. (Exploitovatelný by byl bug buďto v sudo, nebo v iptables, nebo v apt-get, nebo v repquota - poměrně dost rizik na sledování, případně musíte bezmezně spoléhat, že ani v jednom ze čtyř zmíněných programů nebude chyba).
-
To je dobra kravina, co jste napsal.
Takze budeme pod rootem zpracovavat s maximalnimi opravnenimi vsechny takovehle potrebne veci. A budeme resit, aby se root nahodou nedostal tam, kam ta sluzba vlastne nema. A kdyz budeme potrebovat aktualni vystup, tak budeme muset cekat, nez se cron uraci spustit pod rootem danou ulohu, aby hodil vystup.
Ne diky, radeji to sudo a specialne pro monitoring obzvlast.
-
Takze budeme pod rootem zpracovavat s maximalnimi opravnenimi vsechny takovehle potrebne veci. A budeme resit, aby se root nahodou nedostal tam, kam ta sluzba vlastne nema. A kdyz budeme potrebovat aktualni vystup, tak budeme muset cekat, nez se cron uraci spustit pod rootem danou ulohu, aby hodil vystup.
Ne diky, radeji to sudo a specialne pro monitoring obzvlast.ný čas a pouze s vyjmenovanými parametry.
Tak to jste se teď trochu unáhlil.
Když přidám rootovi do crontabu těch pět vyjmenovaných příkazů, je to absolutně stejné, jako když povýšíte zabbix na roota pomocí sudo.
Až na malé rozdíly:
1. crontab se zavolá jen v určený čas - monitoring může např. v důsledku DoS útoku spustit příkazy klidně mnohokrát za sekundu (tj. chybí limitace)
2. crontab má specifikované pevné parametry volaných příkazů; do sudo můžete poslat i další a pokud selže zabezpečení sudo, může to představovat problém (a že sudo selhat může, právě řešíme)
3. samotný volaný program může být exploitovatelný - pokud ho volám z crontabu, zapíše výstup a nemůžu na jeho práci navázat ani zřetězením, ani správným načasovánímTakže JE bezpečnejší volat crontab roota, než povyšovat běžného uživatele (zabbix) na úroveň roota.
Tohle sudo-za-každou-cenu je neštěstí, kterým je prolezlý celý internet. Pokud to jde se sudo vyhnout, je to vždy lepší.
16. 10. 2019, 10:18 editováno autorem komentáře
-
Teoretiku. Pokud neco potrebuju odmonitorovat, potrebuju stav TED a ne, cekat az se spusti nejaky cron. To mam spoustet cron kazdou napr. kazdou vterinu? Anebo kdyz se mi zmeni stav, tak misto cronu 1x5 minut jak mi zajistite cron 1x1 minuta? Bude se kvuli tomu spoustet cron zbytecne kazdou minutu? Budu generovat cronem SNMP strom?
NE. Kravina. Total.
Sudo alespon trochu nahrazuje API, kterym se da dostat k monitorovanym hodnotam, ktere nejsou pristupne beznemu uzivateli.
-
Pokud neco potrebuju odmonitorovat, potrebuju stav TED a ne, cekat az se spusti nejaky cron. To mam spoustet cron kazdou napr. kazdou vterinu?
Ehm, @every_second umí cron na BSD, ale v Linuxu ne, pokud vím. Nepotkal jsem moc případů, kdy je potřeba mít data častěji než za minutu. I kdyby byla data potřeba sbírat často, dají se do monitorignu posílat naráz.
Pokud v praxi voláte sudo častěji než po minutě, tak potěš koště.
Sudo alespon trochu nahrazuje API, kterym se da dostat k monitorovanym hodnotam, ktere nejsou pristupne beznemu uzivateli.
Pěkně prasácká cesta, koledující si o průšvih. Data se mají z priviegované sféry pushovat, ne pullovat.
-
> Tato chyba je OBROVSKÝ ÚLET, kdyby se něco podobného podařilo Microsoftu, byl by
> v diskusích pranýřován dalších deset let.Však ono se mu také podařilo (a obecně daří), pokud přirovnáme sudo k User Account Control. Snad do konce roku 2018 mohl program obejít UAC dialog tak, že spustil whitelistovanou systémovou aplikaci (těch je stále dost) a v zásadě ji ukradl její token. Problém se projevoval od Windows 7 (kdy MS začal whitelistovat některé systémové aplikace) až do tehdy nejnovějších Windows 10 a dlouho se o něm veřejně vědělo (včetně PoC). Chybu mohl zneužít jen uživatel, který patří do skupiny Administrators (jen díky zapnutému UAC normálně pracuje s omezenějším oprávněním); to beru ajko alternativu k /etc/sudoers.
V rámci projektu UACMe jsou stále zdokumentovány postupy, jak UAC obejít
https://github.com/hfiref0x/UACME -
to beru ajko alternativu k /etc/sudoers
To úplně neodpovídá. UAC je mechanismus, který je postavený ještě nad administrátorem. Přesněji by UAC odpovídá spíš SELinux či AppArmor. UAC tedy přidává restrikci.
Sudo oproti tomu z běžného uživatele dělá někoho jiného, často roota. Sudo tedy ubírá restrikci.
-
Já měl za to (tedy laický pohled!), že "sudo" = "switch user & do" - tedy že umožní řízeně přepnout na konkrétního uživatele a spustit povolenou akci. Alternativou je tedy sekvence kroků su - spustit akci - exit,
A se možností přepnout na roota se DOST šetří... Tedy za předpokladu, že to nějakým "#-1" nejde přepnout chybou! -
Jednak reality toho, jak se UAC a sudo skutečně používají.
Toto srovnání bych raději nedělal. Sudo se většinou neopoužívá, ale zneužívá kvůli lenosti adminů a dělá díry do systému. Koncoví uživatelé jsou do toho hozeni a ti většinou opisují intenetové návody, aniž by rozuměli tomu, co dělají. Tristní stav.
UAC naopak přidal vrstvu. Microsoft se s aktualizacemi stará o to, aby se UAC dialog objevoval jen v pečlivě vybraných případech - pochopili totiž, že kdyby vyskakoval moc často, uživatelé by si odkliknutí zautomatizovali a ztratilo by to svůj smysl. Na toto třeba sudo prakticky nemyslí.
Microsoft linuxáci nepotřebují (ani k tomu, aby měli na co nadávat), ale už potřebuje Microsoft nás.
Ehm, dost odvážné tvrzení. Mně spíš přijde, že RedHat, Amazon, Microsoft a další, si celou linuxovou komunitu ochočili. Jsou to oni, kteří nalijí peníze do vývoje směru, který určí a komunita se musí přizpůsobit. Systemd je příklad za všechny, ale rozhodně ne jediný. Nicméně blahopřeji Vám, pokud vazalství považujete za vítězství.
-
Microsoft se s aktualizacemi stará o to, aby se UAC dialog objevoval jen v pečlivě vybraných případech - pochopili totiž, že kdyby vyskakoval moc často, uživatelé by si odkliknutí zautomatizovali a ztratilo by to svůj smysl.
1) Pečlivě vybrané případy, to jako fakt? :D
2) Neznám uživatele windows, kteří to odkliknutí nemají zautomatizované. (To samozřejmě neznamená, že neexistují, nicméně pro sudo musí člověk alespoň otevřít terminál, což pro většinu BFU evokuje větší pocit "dělám něco potenciálně nebezpečného" než dvě kliknutí myší.)
-
> Chybu mohl zneužít jen uživatel, který patří do skupiny Administrators.
Když jsi členem skupiny Administrators, tak už jsi na druhé strany bariéry. Game over. Žádný UAC tě nemůže zastavit.
Vždycky si můžeš požádat o tzv. linked token a voilà, můžeš cokoli. Již v okamžiku přihlášení se do systému ti systém přidělí oba dva tokeny, takže ne, tudy cesta nevede.
Marek.
-
nezkousel sem, ale urcite mas starsi nez 1.8.27-1+deb10u1 ktere s fixem vyslo 12.10. ?
https://metadata.ftp-master.debian.org/changelogs//main/s/sudo/sudo_1.8.27-1+deb10u1_changelog
