Umožňují sudo a .profile/.bashrc triviální eskalaci oprávnění?

Cokoli, co můžete udělat s napadeným účtem, může udělat i útočník.

V zásadě je to proto, že poskytovatelé Linuxu mezi uživateli ne poskytují izolaci mezi jednotlivými procesy běžícími jako stejný uživatel. Jakýkoli proces spuštěný jako daný uživatel má ekvivalentní schopnosti jako jakékoli jiné procesy běžící pod tímto uživatelem.

Je pravda, že spustitelný soubor sudo systému lze tímto způsobem obejít?

Ano, i jinak. Pokud zvýšíte oprávnění na root na kompromitovaném neprivilegovaném účtu, kompromitujete root. Pokud zrušíte oprávnění z root pomocí su na neprivilegovaný účet, kompromitujete také root! Nikdy nemůžete bezpečně zvýšit oprávnění na nedůvěryhodném účtu. I když je možné využít systém pomocí PATH , je také možné unést samotný bash proces, aby bylo možné čichat vstup kláves. Zakázání spouštění pomocí noexec není dále užitečné, protože interprety (bash, python, perl atd.) budou stále běžet. noexec možnost není a nikdy nebyla navržena jako bezpečnostní prvek, přestože je jako taková pravidelně prodávána.

Neúplný seznam způsobů, jak by útočník mohl zneužít použití sudo nebo su :

• Pomocí LD_PRELOAD proměnná na nadřazeném procesu (např. bash ).

• Propojení nadřazeného procesu pomocí ptrace() nebo process_vm_writev() .

• Sniffování nebo vkládání úhozů do emulátoru terminálu pomocí protokolu X11.

• Vytváření aliasů nebo funkcí pro zabalení skutečného sudo spustitelný.

Vysvětlil jsem to podrobněji ve své odpovědi na jinou otázku.

Proč jsou stolní systémy Linux ve výchozím nastavení nastaveny tak snadno zneužitelným způsobem?

Zvýšení oprávnění u nedůvěryhodného účtu není něco, co předpokládáme dělat. Nemluvě o tom, že desktopový Linux je dodatečný nápad ve velkém schématu obecné architektury *nix. Je to selhání bezpečnostního divadla, které neustále opakuje tytéž špatné rady, nikoli selhání bezpečnostní architektury samotného Linuxu. Lidé opakovaně říkají, že použijte sudo pro root, protože mnoho nových uživatelů místo toho spustí vše jako root, dokonce i jejich prohlížeče! V tomto případě je lepší použít sudo . Je to škodlivé v případě, kdy je uživatel již dostatečně chytrý, aby nepoužíval root na všechno.

Všimněte si, že sudo je vysoce konfigurovatelný a může být navržen tak, aby umožňoval pouze určité příkazy. Tady to opravdu září. Můžete nakonfigurovat sudo aby vám umožnil spouštět pouze apt-get update jako root (s heslem nebo bez něj) a vše ostatní zakázat. To by navíc zamezilo útočníkovi dělat cokoli jiného než... no... provádět aktualizaci softwaru.

Je důležité si pamatovat, že i když jej nakonfigurujete tak, aby umožňoval spouštění pouze určitých příkazů jako root, stále se můžete střílet do nohy, pokud zařadíte na seznam povolených programů, které nejsou navrženy ke spuštění jako root, prostřednictvím nedůvěryhodného uživatele. Viděl jsem skutečný příklad, kdy se někdo snažil spustit VeraCrypt tímto způsobem, a vysvětlil jsem, proč je to nebezpečné. Myšlenka byla, že VeraCrypt je bezpečný pro spuštění jako root, takže by mělo být bezpečné používat sudo povýšit jej na root jako nedůvěryhodného, ​​neprivilegovaného uživatele. Ukazuje se, že myšlenka je chybná a umožňuje triviální eskalaci privilegií!

Neměl by se výchozí způsob vyvolání sudo ujistit, že se ve skutečnosti jedná o spustitelný soubor poskytovaný systémem (nikdo nebude pokaždé psát /usr/bin/sudo)?

Zadáním celé cesty vás neochrání! Můžete snadno vytvořit funkci, která obsahuje úvodní / a přepíše skutečný spustitelný soubor. I když se spustitelný soubor ujistil, že je pravý a pokusil se porazit sniffování, škodlivý proces by mohl unést bash zpracovávat a čichat úhozy nezávisle na sudo , což z jeho pohledu znemožňuje detekci.

$ function /usr/bin/sudo { echo 'hijacked!'; }
$ /usr/bin/sudo id
hijacked!

V takovém prostředí se zdá, že používání sudo je zásadně nejisté a bylo by lepší povolit přihlášení jako root a přihlášení na samostatném TTY.

Toto je vždy pouzdro. Všimněte si, že ani přihlášení do jiného TTY není dokonale bezpečné. Měli byste použít SAK, kombinaci Secure Attention Key, abyste zajistili, že komunikujete s relací skutečného přihlášení (agetty nebo logind , například). SAK je klíčová kombinace, na kterou jádro naslouchá (a tudíž nemůže být potlačena uživatelským prostorem). Když to detekuje, zabije každý proces v aktuálním TTY a spustí se výzva k přihlášení. Pokud jste přešli na originální, nekompromisovaný TTY, pak pouze způsobí, že výzva zmizí a znovu se objeví. Pokud používáte unesený TTY, zabije to škodlivý proces a vrátí výzvu k pravému přihlášení.