Zákeřná rozšíření prohlížečů používala novou techniku pro ukrytí komunikace

snad žádná distribuce nemá balíčky v gitu, ale mám k dispozici celý řetězec kroků (od zdrojáku po repositář). O aktualizacích vím dopředu a ne tak, že se prostě stáhnou bez mého vědomí. U některých distribucí ani nejsou binární balíčky, ale vše se sestavuje na místě.

Ano, řada rozšíření v gitu je (ne ty nejpoužívanější), ale jaksi chybí možnost ověřit, že přesně to stejné je součástí toho co je v prohlížeči. Nemluvě o obsahu, který se stahuje z internetu, to už nemám vůbec jak ověřit.

Poslední dobou se ukazuje, že vlastně je problém aktualizace rozšíření, kdy se mění majitel nebo jeho zájmy. Nedávno třeba v Chromu změnil majitele Tab suspender, aktualizace se nainstaluje všem a při zachování práv o tom člověk ani neví.

snad žádná distribuce nemá balíčky v gitu, ale mám k dispozici celý řetězec kroků (od zdrojáku po repositář).
Mezi distribucemi není zdaleka běžné, že byste celý ten řetězec kroků dokázal zopakovat – nemají ověřitelné sestavení.

Ano, řada rozšíření v gitu je (ne ty nejpoužívanější), ale jaksi chybí možnost ověřit, že přesně to stejné je součástí toho co je v prohlížeči.
Jako že je problém vzít ten JavaScript/HTML/CSS z nainstalovaného rozšíření a porovnat ho s tím Gitem? Mně to připadá podstatně jednodušší, než vzít nainstalovanou binárku a porovnávat jí se zdrojákem v Gitu.

Nemluvě o obsahu, který se stahuje z internetu, to už nemám vůbec jak ověřit.
Jak jsem psal, rozšíření potřebuje nějaká oprávnění, aby mohlo s internetu něco stahovat. Měl byste věnovat pozornost tomu, jaká oprávnění rozšíření dáváte.

Poslední dobou se ukazuje, že vlastně je problém aktualizace rozšíření, kdy se mění majitel nebo jeho zájmy. Nedávno třeba v Chromu změnil majitele Tab suspender, aktualizace se nainstaluje všem a při zachování práv o tom člověk ani neví.
Distribuční balíčky jsou proti tomuhle podle vás chráněné jak?

Nainstalovat si do prohlížeče každé rozšíření, na které člověk narazí, je stejně nebezpečné, jako nainstalovat si do počítače každý program, na který člověk narazí. Akorát mi není jasné to vaše porovnávání s distribučními balíčky, protože jediný rozdíl, který vidím, je v tom, že distribuční balíčky se typicky šíří jako přeložená binárka, kdežto rozšíření do prohlížeče jsou zazipovaný JavaScript. Pokud chcete kontrolovat, co instalovaná aplikace/rozšíření dělá, připadá mi ten zdroják v JavaScriptu čitelnější, než ELF binárka.

Filip Jirsák: Mezi distribucemi není zdaleka běžné, že byste celý ten řetězec kroků dokázal zopakovat – nemají ověřitelné sestavení.

https://wiki.debian.org/ReproducibleBuilds
https://reproducible-builds.org/reports/2021-01/
https://vdwaa.nl/arch-linux-reproducible-builds-progress-2020.html

k3dAR: Ano, to jste vybral těch pár, které mají reprodukovatelné sestavení. Zbytek to nemá, a distribucí jsou desítky. Takže to není zdaleka běžné.

Mezi distribucemi není zdaleka běžné, že byste celý ten řetězec kroků dokázal zopakovat – nemají ověřitelné sestavení.

někde důvěra být musí, ověřitelné sestavení má zajistit, že správce balíčku či kdokoliv třetí nemůže do kód nic přidat. Pořád ale platí, že u distribucí mají jednotný proces jak balíčky sestavují, jsou podepsané, je k nim zdrojový kód a procházejí stejnou kontrolou.

Jako že je problém vzít ten JavaScript/HTML/CSS z nainstalovaného rozšíření a porovnat ho s tím Gitem? Mně to připadá podstatně jednodušší, než vzít nainstalovanou binárku a porovnávat jí se zdrojákem v Gitu.

To právě problém je, asi jsi to nikdy nezkoušel, ale v rozšíření je často jiná struktura kódu, soubory jsou sdružené, bývají odstraněné komentáře či jinak transformovaný kód. Typescript soubory bývají už kompilované, v repu jsou jako .ts a spousty dalších překážek, abych dokázal ověřit, že tam někde není funkce navíc. Těch kódů pro balíčky v gitu je ale strašně málo.

Jak jsem psal, rozšíření potřebuje nějaká oprávnění, aby mohlo s internetu něco stahovat. Měl byste věnovat pozornost tomu, jaká oprávnění rozšíření dáváte.
to ale není tak docela pravda, u Chromu si rozšíření může nadefinovat dopředu url, z kterých stahuje obsah a ten se normálně stáhne do samotného rozšíření (běží v sandboxu), není potřeba žádné extra oprávnění jako pro úpravu obsahu stránky. Zásadní problém ale není s přidělením práv, ale že se nedozvím o aktualizaci, kdy se mohl změnit vlastník (děje se) nebo se změnil záměr autora (chce začít na tom vydělávat).

Ale u distribucí každá aktualizace prochází určitým procesem kontroly, zabalení atd., tohle mohu ověřit. U rozšíření nic takového není, každý autor to dělá jinak, kolikrát ani autora neznám (anonymní účet pouze pro rozšíření). Tvoje argumentace je alibistická, jak mám poznat rozšíření které není nebezpečné? Poměrně dost rozšíření se stalo nebezpečnými až po jejich rozšíření, do té doby byly v pořádku. O aktualizaci se jednoduše nedozvím, abych si to prošel, prohlížeč si to stáhne a spustí bez mého vědomí sám.

ověřitelné sestavení má zajistit, že správce balíčku či kdokoliv třetí nemůže do kód nic přidat.
Ne, to samozřejmě ověřitelné sestavení nezajistí. Ověřitelné sestavení zajistí akorát to, že si můžete ověřit, že balíček byl sestaven z daných zdrojových kódů.

Pořád ale platí, že u distribucí mají jednotný proces jak balíčky sestavují, jsou podepsané, je k nim zdrojový kód a procházejí stejnou kontrolou.
Zatímco pro rozšíření prohlížečů platí, že mají jednotný proces, jak se balíčky sestavují, jsou podepsané, zdrojový kód je přímo v nich a procházejí stejnou kontrolou, jako drtivá většina distribučních balíčků – tedy žádnou.

To právě problém je, asi jsi to nikdy nezkoušel, ale v rozšíření je často jiná struktura kódu, soubory jsou sdružené, bývají odstraněné komentáře či jinak transformovaný kód. Typescript soubory bývají už kompilované, v repu jsou jako .ts a spousty dalších překážek, abych dokázal ověřit, že tam někde není funkce navíc.
Pořád je to výrazně jednodušší, než to hledat v ELF binárce.

to ale není tak docela pravda, u Chromu si rozšíření může nadefinovat dopředu url, z kterých stahuje obsah a ten se normálně stáhne do samotného rozšíření (běží v sandboxu), není potřeba žádné extra oprávnění jako pro úpravu obsahu stránky.
Máte příklad takového rozšíření? Podle mne je to pořád jedno z oprávnění, které musí uživatel před instalací odsouhlasit.

Ale u distribucí každá aktualizace prochází určitým procesem kontroly, zabalení atd., tohle mohu ověřit.
Myslím, že co se týče „procesu kontroly“, jste dost velký optimista.

Tvoje argumentace je alibistická, jak mám poznat rozšíření které není nebezpečné?
Jak to poznáte u distribučních balíčků? Jak to poznáte u balíčků z komunitních repozitářů?

Poměrně dost rozšíření se stalo nebezpečnými až po jejich rozšíření, do té doby byly v pořádku.
Proč si myslíte, že se to samé neděje u aplikací?

O aktualizaci se jednoduše nedozvím, abych si to prošel, prohlížeč si to stáhne a spustí bez mého vědomí sám.
To je asi jediný relevantní rozdíl. Ale opravdu u distribučních balíčků procházíte zdrojový kód všech změn?

Zkrátím to.

Máte příklad takového rozšíření? Podle mne je to pořád jedno z oprávnění, které musí uživatel před instalací odsouhlasit.
Myslím si, že obsah v content_securi­ty_policy (v případě Chromu) se nemusí odsouhlasovat a může obsahovat url, ze kterých rozšíření může obsah stahovat, nemám ale takové rozšíření, resp. netuším jak ho rychle najít.

To je asi jediný relevantní rozdíl. Ale opravdu u distribučních balíčků procházíte zdrojový kód všech změn?
Správná otázka. Vysvětlím jaký v tom vidím rozdíl.

Při aktualizacích se dělá běžná operativa, kontrola CVE, Errata, owasp testy, ověří se security kanály distribucí. Vše je dáno tím, že některé distribuce již mají svoje procesy, kterými kód prochází, pokud procesy jsou dostečné, je zbytečné automaticky práci replikovat a využívá se přenesená důvěra, často dostačuje. Ale např. u Chrome nebo Firefoxu je kontrola pouze automatická, k tomu ještě není veřejně dokumentovaná, to je přesně co mi vadí. Pokud si jí chci dělat sám, nejsou k tomu dostupné nástroje a možnosti.

Proč si myslíte, že se to samé neděje u aplikací?
Ono se to děje, viz problémy s balíčky u pipu, perlu, node.js, php. U ubuntu jsem občas viděl závadné externí PPA repositáře. Hlavní repositáře distribucí mají ale dobrou pověst a tyhle problémy se jim nedějí, proto jsem je použil pro porovnání. U všech ale mám nějakou možnost kód ověřit před jeho spuštěním, nikoliv u prohlížečů, Google naopak k tomu je extrémně uzavřený, Firefox je na tom lépe, ale také to není ono. A to mi vadí.

Při aktualizacích se dělá běžná operativa, kontrola CVE, Errata, owasp testy, ověří se security kanály distribucí. Vše je dáno tím, že některé distribuce již mají svoje procesy, kterými kód prochází, pokud procesy jsou dostečné, je zbytečné automaticky práci replikovat a využívá se přenesená důvěra, často dostačuje. Ale např. u Chrome nebo Firefoxu je kontrola pouze automatická, k tomu ještě není veřejně dokumentovaná, to je přesně co mi vadí. Pokud si jí chci dělat sám, nejsou k tomu dostupné nástroje a možnosti.
Argumentoval jste tu i distribucemi, které nemají binární balíčky. Pokud se nic nezměnilo, třeba Gentoo nemá ani ty automatické kontroly. A pochybuju, že i u Debianu nebo RHELu kontroluje všechny změny člověk – nanejvýš to dělá nějaký automatický scanner, jako u těch doplňků prohlížečů.

Rozšíření do prohlížeče jsou distribuovaná jako zip se zabaleným JavaScriptem (a HTML+CSS). Takže možnost to kontrolovat je. Že k tomu nemáte nástroje, to je řekl bych spíš váš problém než problém kohokoli jiného. Kontrola, kterou by vám dodal někdo jiný, by (vzhledem k tomu, co píšete) byla k ničemu, ne? Když vám vadí, jak Google kontroluje rozšíření, mělo by vám vadit úplně stejně, kdyby vám ten kontrolní nástroj zpřístupnil. Pořád přeci jde o důvěru Googlu.

Hlavní repositáře distribucí mají ale dobrou pověst a tyhle problémy se jim nedějí, proto jsem je použil pro porovnání.
Což je podle mne dané spíš tím, že se to prostě nedělá, než že by to nešlo. Případně je pro útočníky jednodušší dopravit škodlivý kód k uživateli jiným způsobem, než přes oficiální distribuční repo. Vystaví na webu nějakou elektronovou aplikaci a uživatel si to stáhne a spustí sám mimo distribuční kanály. Nebo mu to poskytne jako Docker image. Řekl bych, že distribuční balíčky představují dost práce navíc, kterou spousta vývojářů nechce podstoupit – a vývojáři škodlivého kódu k nim patří také. To je podle mne celé. Přitom je to škoda, protože mechanismus automatických aktualizací, o které se stará operační systém, je správně – a je hloupé, že se vracíme do situace, kdy se každá aplikace distribuuje jinak, fakticky se jen stahuje z nějakého webu a v systému běží milion kontrol, jestli tahle a tahle aplikace náhodou nemá novou verzi.

Jinak to vypadá, že jediné, co vám doopravdy na doplňcích vadí, je to, že není možné je aktualizovat ručně. Což je pro drtivou většinu uživatelů (tedy pro Chrome) naprosto v pořádku. Možnost vypnutí automatických aktualizací bych čekal třeba u Vivaldi – zkuste to vývojářům navrhnout.

Rozšíření do prohlížeče jsou distribuovaná jako zip se zabaleným JavaScriptem (a HTML+CSS). Takže možnost to kontrolovat je. Že k tomu nemáte nástroje, to je řekl bych spíš váš problém než problém kohokoli jiného A jak se k těm zip archivům dostanu? Google má nasazenou ochranu proti strojovému hromadném stažení. Kde se dozvím, že se nějaké rozšíření změnilo? Mohu se to dozvědět před jeho stažením a spuštěním prohlížečem? Ne, nemohu.

Jinak tě nechám ve světě, že zdrojový kód balíčků nikdo nekontrole a distribuce to šířší dál. To je mylná představa.

A jak se k těm zip archivům dostanu?
Třeba tak, že se ve vývojářských nástrojích podíváte, odkud se to stahuje.

Google má nasazenou ochranu proti strojovému hromadném stažení.
Proč je potřebujete stahovat hromadně?

Kde se dozvím, že se nějaké rozšíření změnilo? Mohu se to dozvědět před jeho stažením a spuštěním prohlížečem? Ne, nemohu.
Potřebujete, abych vám sem zkopíroval svůj předchozí komentář, na který mimochodem reagujete, nebo si ho přečtete sám?

Jinak tě nechám ve světě, že zdrojový kód balíčků nikdo nekontrole a distribuce to šířší dál. To je mylná představa.
A já jsem myslel, že se konečně něco dozvím. Zajímalo by mne, kdo a jak podle vás kontroluje zdrojový kód aplikace, než pro ni vznikne ebuild pro Gentoo. A také by mne zajímalo, kdo a jak podle vás kontroluje kód aplikace, než se z něj udělá deb balíček pro Debian.

Třeba tak, že se ve vývojářských nástrojích podíváte, odkud se to stahuje.
a to je ten problém, nejprve musí rozšíření nainstalovat a spustit, to je skvělé pro ty hodně nebezpečné.

Proč je potřebujete stahovat hromadně?
Hromadně právě kvůli dopředné kontrole, kvůli možnosti nastavení automatických procesů, které budou kontrolovat více rozšíření najednou. Např. v jedné firmě s asi 150 uživateli máme dohromady nainstalovaných nějakých 900 různých rozšíření, na které je potřeba dávat oko a ověřovat každou jejich novou verzi.

A já jsem myslel, že se konečně něco dozvím. Zajímalo by mne, kdo a jak podle vás kontroluje zdrojový kód aplikace, než pro ni vznikne ebuild pro Gentoo. A také by mne zajímalo, kdo a jak podle vás kontroluje kód aplikace, než se z něj udělá deb balíček pro Debian.
Mohu třeba citovat Debian guidlines pro mainteinery při aktualizaci balíčků:

8.2 Inspection of the new upstream releaseWhen preparing packages of a new upstream release for the Debian archive, you must check the new upstream release first.Start by reading the upstream changelog, NEWS, and whatever other documentation they may have released with the new

version.You can then inspect changes between the old and new upstream sources as follows, watching out for anything suspicious:$ diff -urN foo-oldversion foo-newversionChanges to some auto-generated files by Autotools such as missing, aclocal.m4, config.guess, config.h.in,

config.sub, configure, depcomp, install-sh etc.

Podobná pravidla jsou i jinde. Např. u RHEL ta kontrola je vždy u všech aktualizací, to aspoň slibují v podmínkách. U Gentoo mají vlastní security tým, který slouží jako podpora mainteinerům, jejich QA Reports jsou automatizované, zodpovědnostní mainteinera je právě kontrola zdrojového kódu při aktualizaci.

Můžeme diskutovat jak moc je tohle spolehlivé, ale k tomu jsou potřeba data o spolehlivosti záchytu škodlivých balíčků. Každopádně u rozšíření do prohlížečů tenhle proces neexistuje a automatická kontrola propouští podobná nebezpečná rozšíření opakovaně. V tomhle je rozdíl. Přitom bych řekl, že napadání serverů je daleko lukrativnější než napadání prohlížečů uživatelů.

5. 2. 2021, 21:53 editováno autorem komentáře

Distribuční balíčky také ověřujete tak, že je hned nainstalujete do živého systému?

Mohu třeba citovat Debian guidlines pro mainteinery při aktualizaci balíčků
Aha, takže od „pečlivě se to kontroluje“ jsme se už dostali k „v doporučení je napsáno, že je vhodné zkontrolovat změny“.

Na ten kód se (možná) dívá někdo, kdo o té aplikaci nic neví a schovat před ním škodlivý kód není nic těžkého. Důležité balíčky mají doufám lepší kontrolu, ale na spuštění škodlivého kódu vám stačí kterýkoli okrajový balíček.

Rozdíl mezi serverem a prohlížečem je v tom, že na serveru máte pár aplikací, zatímco uživatelé si do prohlížeče instalují kde co. Jakmile povolíte instalovat kde co (Docker, pluginy do WordPressu), dostanete se s bezpečností na stejnou úroveň, jaká je v těch rozšířeních prohlížeče.

Kolik lidí si nainstaluje nějaké rozšíření bez toho, že by mu odsouhlasili požadovaná oprávnění? Něco kolem nuly, bych tipnul.

Uživatel tři tečky chce kontrolovat zdrojový kód rozšíření. Myslím, že přečíst si navíc i oprávnění, která rozšíření vyžaduje, by pro něj neměl být takový problém. (I když – když je pro něj problém rozbalit zip se zdrojovým kódem…)

pokud ale instaluji něco na blokování reklam nebo správce hesel je logické, že tomu dám rozšíření na zasahování do stránky, v momentě instalace mohu klidně udělat zevrubnou kontrolu.

Pár Adblocků už takhle nechvalně skončilo poté, co změnili majitele, pro uživatele to je nerozpoznatelný a to je problém.

Všechna zodpovědnost visí na Google a jiných správcích storů, kteří ale neposkytují žádné nástroje nám správcům jak tohle vůbec kontrolovat, naopak aktivně brání (rate limity a recaptcha) robotickému stahování rozšíření a jejich následné analýze. Neposkytují ani snadnou možnost detekovat aktualizaci jinak než stahovat vše pořád dokola.

Já nerozporuju, že existují problémy, které popisujete. Akorát to srovnáváte s distribučními balíčky – které mají ovšem úplně ty samé problémy (plus jeden navíc, že je to typicky kompilovaný kód, takže když zkontrolujete zdroják, ještě se od něj musíte dostat k tomu zkompilovanému kódu).

vyjmenoval jsem tady řadu distribucí, které kompilovaný kód neposkytují. O to ale nejde, on i ten kompilovaný kód je podepsaný, vím, kdo ho zabalil, jakým procesem prošel a vím, kde k němu je zdrojový kód. Tohle u rozšíření neplatí vůbec.

Existuje riziko, že byl napadený samotný proces kompilování a balení u distribuce, tomu má bránit technologie reprodukovatelných binárek, některé distribuce na tom již léta pracují. U rozšíření ale tohle riziko platí dvojnásob, kterýkoliv vývojář rozšíření může být napadený a někdo v pozadí může dělat nežádoucí úpravy, jenže narozdíl od linuxové distribuce je těhle vývojářů obrovské množství, jsou to i jednotlivci a lze čekat, že takové napadení může zůstat nepovšimnuto měsíce, roky, u distribucí naopak nečekám (= mám k jejich dokumentovaným procesům důvěru narozdíl od anonymních vývojářů), že se něco takového může dít hromadně a dlouhodobě.

Rozšíření, které byly dodatečně upraveny, aby dělali nežádoucí činnost je zdokumentovaných obrovské množství (Google je např. odstraňuje bez dodatečného upozornění), proto to vidím jako velké riziko, naopak napadených buildovacích procesů u linuxových distribucí je poskrovnu a riziko je zatím v teoretické rovině. I v tomhle je značný rozdíl.

on i ten kompilovaný kód je podepsaný, vím, kdo ho zabalil, jakým procesem prošel a vím, kde k němu je zdrojový kód. Tohle u rozšíření neplatí vůbec
Vypadá to, že opravdu nevíte, jak rozšíření v prohlížeči vypadají. Už jsem vám několikrát psal, že jsou podepsaná, zdrojový kód je přímo v balíčku toho rozšíření (pořád je to HTML, CSS, JavaScript). Proces zabalení vypadal tak, že se ty soubory zabalily do jednoho zipu – to také není nic složitého.

Ke zbytku – problém je, že porovnáváte dvě neporovnatelné věci. Zabalení rozšíření prohlížeče znamená jenom jeho zazipování, takže je ověřitelné – prostě ten zip zase rozbalíte a musíte dostat stejné soubory. Vy v případě rozšíření nepíšete o napadení vytváření balíčku, ale o napadení zdrojových kódů balíčku. Tomu odpovídá napadení zdrojových kódů aplikace. Což se děje, a balíčkování v distribuci tomu nijak nezabrání (o čemž svědčí i to, že se ty napadené aplikace dostaly až do distribucí).

No jo, ale k rozšíření nemám původní zdrojový kód a ani nemusím znát autora, nemám to tedy proti čemu ověřovat. Krom toho řada rozšíření si ten kód stahuje dodatečně, viz i o čem je tahle zprávička.

Já jsem myslel, že chcete ověřovat, co to rozšíření dělá. K tomu nepotřebujete znát autora, a kód transpilovaný do JavaScriptu je pro to pořád vhodnější, než ELF binárka.

Podepsaná kým?

V případě distribucí je balíček podepsaný maintanerem (při uploadu) - ten má ručit za bezpečnost. Nesmí přidávat features (alespoň ne sám od sebe), dá se zpětně dohledat pochybení a stát se mainainerem je také netriviální proces.

V případě rozšíření podepisuje rozšíření původní vývojář, nikdo další to po něm nekontroluje, a je normální, když se rozšíření samo aktualizuje během jednoho týdne několikrát. Změnu funkcionality také hlídá jen ten jeden vývojář. Pokud už nechce doplněk spravovat, tak má možnost ho prodat (prodat přístup k uploadu) třetí straně, která svojí investici zhodnotí nějakým malware nebo adware kódem.

Rozšíření je podepsané tím, kdo výsledný balíček sestavuje – typicky vývojář rozšíření. Distribuční balíček je také podepsaný tím, kdo ho sestavuje – a nezřídka je to také vývojář té aplikace. V obou případech dotyčný má ručit za bezpečnost. Že distribuční správce nesmí přidávat features nikdo nekontroluje, děje se to – a pokud featuru vhodně pojmenuje („backport opravy“), dokonce to po něm všichni chtějí. Pochybení se dá zpětně dohledat také v obou případech – jak u distribučního balíčku, tak u rozšíření. Nevím, jestli „prosím vás, nemohl by si někdo tento balíček vzít na starost, kdokoli, je to jednoduché“ je netriviální proces…

To, že se software aktualizuje několikrát týdně, je normální – akorát distribuce to moc nezvládají. Změnu funkcionality hlídá jen vývojář, správce balíčku nikoli. Prodat balíček může i distribuční správce.

Samozřejmě se bavíme o „nezajímavých“ balíčcích – VIP balíčky typu Apache nebo OpenSSL mají jinou péči (třeba je distribuční správci „vylepšují“ bezpečnostními chybami, že…), ale zákeřný kód může být v jakémkoli balíčku.