Zažil jsem už spousty napadených desktop linuxů
Čím konkrétně byly napadené? Díky.
Opravdu mě to zajímá, linux na desktopu používám od r. 2000 a s napadeným desktopem jsem se ještě v praxi nesetkal. Nezpochybňuji to, vím, že technicky to samozřejmě lze, ale jaké byly konkrétní příklady v praxi. Předem díky.
Je toho opravdu spousty. Viděl jsem a řešil třeba EvilGnome, stačilo spustit kód pod uživatelem a získal perzistentního daemona, který ovládal vzdáleně počítač. Šířil se jako payload u legitimní aplikací, tady za nákazu mohl překlepový balíček v pipu. Tady se to stalo u veřejných počítačů v jedné velké knihovně.
Letos třeba parazit od skupiny Kaiji. Hledá otevřené služby v dockeru a přes únik v dockeru získá kontrolu nad OS (docker a kontejnery na linux opravdu nejsou jako jail ve freebsd a nejsou určeny k zabezpečení). Za nákazu mohla web kamera v domácí síti koupená z Alíka, jak ta se nakazila jsem už neuměl zjistit, možná už v tom stavu přišla, do internetu neviděla, pouze do domácí sítě (zrovna nedávno tady na to bylo vlákno kolem web kamer, pozor na ně). Domácí stanice kolegy v práci.
Napadání desktopů na linuxu výrazně roste, hlavní problém je, že spousta služeb a aplikací běží pod jedním uživatelem a celá bezpečnost linuxu je založena na izolaci uživatelů a ne procesů, uid mapování v kontejnerech (např. snap) s app arrmor/selinux je super, ale velká spousta aplikací ještě tak neběží.
Stačí se podívat jaké zranitelnosti se opravovali v minulosti, např. Firefox CVE-2022-1802 znamenal, že kdokoliv, kdo mohl spustit JS v prohlížeči, mohl spustit libovolný kód jako firefox uživatel, což na desktopu je přihlášený uživatel (snap a jiné věci by mohly vektor útoků snížit).
Nebo letošní Chrome CVE-2023-0471, opět vzdálené spustění kódu pod právy procesu Chrome, pro desktop fatální problém.
Stejně tak jsou na vzestupu útoky na balíčkovací systémy (npm, pip, docker vévodí). U těhle balíčkovacích systémů nejsou žádné velké automatické kontroly, propašované překlepové balíčky nebo napadené vývojářské účty jsou časté. A ono to člověk jednou postihne. U CI deploymentů nám to nevadí, běží to izolovaně a kontroluje se chování, ale uživatelé běžně instalují věci pod svým přihlášeným účtem, spouští na linuxu přímo pod svým uživatelem, npm i pip zároveň spouští při instalaci balíčku libovolný kód.
Oprava sa správne projeví aj bez restartu, ak je na to prispôsobená. Že to nevynutí nie je chyba. A že je systém nebezpečný len preto že ho ty nereštartuješ? A to je ako bezpečné keď sa ti systém sám reštartne, a ty prídeš o dáta?
U drtivé většiny aplikací a i samotného kernelu nikoliv. Ukaž příklady, prosím. Není pořád běžné, aby aplikacen a linuxu se sama bez restartu přepsala v paměti. Na to jsou docela složité procesy s forkem a přechodem na nový runtime. Windows při aktualizaci nějakého souboru vynucuje ukončení procesu, který ten soubor používá, na linuxu se soubor bez problémů přepíše na disku, ale aplikace si drží otevřený ještě ten původní a musí si ho sama znovu otevřít (OS jí o změně ani nijak aktivně neinformuje). Na fedoře k tomu máme třeba program dnf needs-restarting, na ubuntu reboot-required (a případně přímo soubor /var/run/reboot-required.pkgs). Případně se dá zabrousit do výstup lsof a podívat se, který otevřený soubor změnil svůj obsah.
Zobrazit příspěvky
.