Názor k článku Sofistikovaná sabotáž XZ zabrala roky, odhalena byla šťastnou náhodou od Filip Jirsák - A pokud tohle bude uzavřeno bez úpravy procesů,...

  • Článek je starý, nové názory již nelze přidávat.
  • 1. 4. 2024 9:42

    Filip Jirsák
    Stříbrný podporovatel

    A pokud tohle bude uzavřeno bez úpravy procesů, tak Linux není možné považovat za bezpečný. Tohle se prostě vůbec nemělo stát.
    Mně teda překvapuje, že tohle někoho překvapuje. Dalo se očekávat, že někdo něco takového zkusí – příkladů, že to jde, už bylo docela dost.

    Komunitní opensource je stále založen především na důvěře. Pokud někdo přispívá a alespoň trochu to dává smysl, nikdo moc nezkoumá, co umí nebo dokonce jaké má úmysly. Komunitního opensource softwaru je pořád daleko víc, než kolik zvládnou lidé, kteří ho dělají, kvalitně obsloužit.

    Podobných varování bylo už několik. Namátkou třeba vývojář Debianu, který chtěl vylepšit OpenSSL a místo toho způsobil to, že se generovaly slabé klíče. Pokud vím, nikdo to nepovažoval za úmysl, prostě se jen pustil do něčeho, čemu dobře nerozuměl. Nebo to byl případ odstranění knihovny left-pad z npm registry, které sice bylo úmyslné, ale úmyslem nebylo rozbít půlku internetu.

    Dalo se celkem očekávat, že když k takovýmto chybám dochází omylem, může někdo zkusit udělat něco takového i úmyslně.

    Po chybách v OpenSSL se vybralo pár nejdůležitějších projektů, které jsou pro internet klíčové ale nebyly z hlediska správy v dobrém stavu. Vznikla Core Infrastructure Initiative. Jenže projektů, na kterých opensource svět závisí a skrze které je možné zaútočit je řádově více. XZ je jenom jedním z moha – každý si přece řekne, že je to jen jedna z kompresních knihoven, kdyby s ní byl nějaký problém, můžeme si zvolit některou z jiných knihoven. Ano, můžeme – ale reálně se ta knihovna XZ používá ve spoustě případů a je možné skrze ní napadnout skoro kterýkoli systém – i takové systémy, které ji nepoužívají.

    Přitom ta knihovna reálně závisí na jednom jediném člověku. Lasse Collin mohl nějaký kód přijmout nebo odmítnout, mohl přizvat nebo odmítnout dalšího správce, mohl mu správcovství předat. Já jsem přesvědčen, že Lasse Collin neudělal žádnou chybu, neměl důvod JiaT75 nějak více prověřovat. Ale ono je to vedlejší – i kdyby chybu udělal, problém je v tom, že to celé záviselo na jediném člověku a po něm už nebyla prakticky žádná kontrola. Za prvé nemůžeme po vývojáři spravedlivě chtít, aby rozpoznal léčku pravděpodobně nějaké tajné služby. Správci opensource jsou vývojáři, ne špioni.
    Za druhé to celé posouváme jen o člověka dál. Co kdyby se tajným službám podařilo naverbovat přímo Lasse Collina? Třeba by mu dost zaplatili. Nebo co kdyby se s ním prostě něco stalo a on přešel k temné straně síly? Co kdyby byl Lasse Collin od začátku nastrčený?

    Fungování projektu XZ ovšem není výjimkou, když to budeme brát na počet projektů, bude to spíš pravidlem. A jak je vidět, zneužít se dá i nějaký menší projekt, o kterém si po většinu doby ani neuvědomujeme, že ho používáme.

    Řešením ale není něco měnit přímo na těch opensource projektech – že by se o ně staralo více lidí. To je absolutně nereálné.

    Spousta lidí si myslí, že opensource je bezpečný proto, že v něm může hledat chyby kdokoli. Problém je v tom slovíčku může – ano, opravdu může, ale prakticky nikdo to nedělá, takže z tohoto důvodu je to stejné, jako by nemohl. Tj. aby se situace zlepšila, je potřeba, aby se ty problémy opravdu hledaly – pravděpodobně ne ručně, na to nejsou kapacity, ale automaticky. Nálezy aby pak hodnotili lidé mimo ty projekty a teprve to, co vyhodnotí jako problém, šlo ke správcům konkrétního projektu, včetně popisu, jak problém zreplikovat. (Postup „náš uzavřený nástroj, který vám nedáme k dispozici, našel těchto 150 potenciálních chyb, prohrabte se tím a třeba něco najdete“ je k ničemu.)

    V případu XZ vidím jednu chybu, která měl rozeznít alarm, ale kterou by bylo triviální obejít – přidání souboru, který je v repository, do .gitignore. To ukazuje na chybu, ale zároveň to nejde použít jako spolehlivý signál útoku, protože pro útočníka by bylo snadné to obejít. (Spíš to ukazuje na to, že na technickém poli útočníci nebyli zas až tak dobří – pořád z toho plyne, že byli mnohem lepší zpravodajci než programátoři.)

    Pak je tam jedna systémová chyba, která by se měla napravit, i když to bude obtížné. Ta chyba spočívá v tom, že různé nástroje na kontrolu kvality kódu mají možnost selektivně vypínat některé kontroly, když hlásí planý poplach. To vypnutí ovšem vypíná danou kontrolu úplně, není svázáno s původní chybou. Takže stačilo nejprve podstrčit legitimní kód, kvůli kterému bylo nutné vypnout nějakou kontrolu, a pak už se ten kód dá nahradit čímkoli jiným a ta kontrola zůstane pořád vypnutá. Ideální by bylo, aby se neuvádělo jen „vypínám kontrolu“, ale „vypínám kontrolu, protože X“ – a když přestane platit X, přestalo platit i vypnutí kontroly. Nebo se to dá obejít alespoň tak, že při změně kódu, u kterého je vypnutá kontrola, se ta kontrola musí zase zapnout – a teprve pokud znova neprojde, musel by ji někdo znova vědomě vypnout. To by se dalo hlídat automaticky.

    Nejdůležitější je ale zefektivnit a zkvalitnit hledání (bezpečnostních) chyb. Místo sypání co největšího množství CVE na jednu hromadu investovat do jejich rozlišování, místo soutěží o odhalování zero-day zranitelností, které tvoří špičku ledovce, se věnovat té mase, která je pod hladinou.