Chyba v sudo umožňuje navýšení práv, stačí jako UID nastavit -1 nebo 4294967295

V praxi je tato chyba zneužitelná jen v prostředích, kde se používá sudo k získání práv nějakého jiného uživatele kromě roota. Nebo se mýlím? Zajímalo by mě, jak běžný je takový setup.

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

Nejsem si jist. Mam pristup na roota povolen, ale jen na nektere prikazy. Ale eskalovat si jakykoliv prikaz se mi nedari. Ve finale ani ten co mam povoleny. Ne nemam patch. :)

Patch sice je, ale ve spoustě distribucí zatím opravný balíček nebyl vydán.

Na žádném ubuntu od 18.04 pod 19.10 mi to nefunguje. Buď chce stejně heslo, nebo napíše neznámý uživatel

a neaktualizoval si vcera kdyz byla aktualizace sudo baliku? ;-)

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.

"Pak už bohužel nezbývá, než využít sudo."

Jak nezbyva? Ja na vetsine stroju nemam vubec sudo nainstalovany... natoz abych ho vyuzival...

Jak nezbyva? Ja na vetsine stroju nemam vubec sudo nainstalovany... natoz abych ho vyuzival...

Já jen tleskám.

> 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ím

Takž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

> 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!

A teď zpátky od emotivních prohlášení do reality. Jednak reality toho, jak se UAC a sudo skutečně používají. Jednak reality toho, že už Microsoft linuxáci nepotřebují (ani k tomu, aby měli na co nadávat), ale už potřebuje Microsoft nás.

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í.

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

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

To je pravda. Nejde pod ním (alespoň) ale spouštět procesy (nízká impersonation level).

U mě na nezaktualizovaném Debianu se to neprojevuje, zkoušel jsem na více strojích a nepovedlo se ani na jednom.

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