Hlavní navigace

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

Sdílet

Petr Krčmář 4. 2. 2021
google-chrome-hacked Autor: Depositphotos

Na konci loňského roku se objevila informace o tom, že na tři miliony prohlížečů Chrome a Edge je napadeno jedním z 28 zákeřných rozšíření. Ta se tvářila jako nástroje pro stahování obrázků z různých webů, přitom ale sbírala osobní údaje a přesměrovávala na phishingové weby. Společnosti Google a Microsoft se postaraly o rychlé odstranění těchto rozšíření.

Nyní lidé z Avastu odhalili novou techniku, kterou rozšíření používala pro ukrytí své komunikace s řídicími servery. Byly k tomu využity hlavičky Cache-Control, které se obvykle starají o řízení kešování u klientů. Rozšíření posílala na svou doménu požadavky určené pro webovou analýzu a od serveru zpět přicházely v hlavičce zašifrované instrukce včetně dalšího kódu.

Rozšíření pak byla schopna hlavičku dešifrovat a provést kód v ní. Nejvíce napadených prohlížečů bylo v Brazílii, Francii a na Ukrajině. Úplně na začátku na problém upozornil Edvard Rejthar ve svém článku Hledání škodlivého kódu mezi doplňky prohlížeče aneb odhalujeme malware, který původně vyšel na blogu CZ.NIC.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 4. 2. 2021 11:53

    ...

    tohle je asi nemožné vyloučit, vždy je možné nějak přenášet informace, klidně formou zpozdění odpovědi ze serveru. Teď se snaží využívat viditelné hlavičky, kteér se ignorují, když mají špatný obsah, zákeřnějších možností je ale celá řada.

    Bohužel ani u jednoho prohlížeče si nemohu snadno rozšíření ověřit, u linuxu mám často k balíčkům zdrojové kódy, balíčky prošli nějakém review a procesem zabalení, jsou podepsané, vím co je jejich obsahem (u některých distribucí). U rozšíření do prohlížeče nevím vůbec nic, část obsahu si stahují ze serveru, google neposkytuje žádný nástroj jak ověřit obsah rozšíření, mohu se jenom spolehnout na hlášení uživatelů, kterým to vlastně je jedno.

  • 4. 2. 2021 12:45

    Filip Jirsák

    Balíčky rozšíření pro prohlížeče také obsahují zdrojový kód a jsou podepsané. Aby si rozšíření stahovalo další kód ze serveru, potřebuje na to oprávnění – a takové chování je velmi netypické a podezřelé.

    Jakým nástrojem ověřujete distribuční balíčky a proč ten samý nástroj nepoužijete na rozšíření prohlížeče?

  • 4. 2. 2021 17:58

    ...

    no, existující třetí strany, které mi dovolí rozšíření stáhnout (vždy ale poslední verzi, ne starou), rozbalit a podívat se do něj, Google, FF a jiní to ale sami neposkytují. Pokud jde o aktualizace, tak jejich obsah se nedá odchytávat už vůbec (leda si stahovat poslední verzi, mít uloženou předchozí a dělat si ručně porovnání), proto nemohu použít stejný nástroj.

    distribuce jako gentoo, arch, alpine, openbsd mají stav v git repositáři, mohu ho procházet, vím přesně co která aktualizace obsahuje a vím, že aktualizace prošly určitým procesem schválení. U google nebo FF vím akorát, že plugin je testován robotem podle nějakých pravidel, že plugin si bez problémů může stáhnout cokoliv dodatečného.

  • 4. 2. 2021 18:14

    Filip Jirsák

    Takže rozdíl je v tom, že jedna linuxová distribuce má balíčky v Gitu (a překládáte si je až u sebe). A ostatní mají v Gitu zdroje, ze kterých snad balíčky sestavují. Hm. Některá rozšíření prohlížečů mají také zdrojáky v Gitu.

  • 4. 2. 2021 23:20

    ...

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

  • 5. 2. 2021 0:03

    Filip Jirsák

    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.

  • 5. 2. 2021 8:46

    Filip Jirsák

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

  • 5. 2. 2021 9:16

    ...

    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.

  • 5. 2. 2021 10:52

    Filip Jirsák

    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?

  • 5. 2. 2021 12:12

    ...

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

  • 5. 2. 2021 13:40

    Filip Jirsák

    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.

  • 5. 2. 2021 13:53

    ...

    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.

  • 5. 2. 2021 17:41

    Filip Jirsák

    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.

  • 5. 2. 2021 21:51

    ...

    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

  • 5. 2. 2021 22:31

    Filip Jirsák

    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.

  • 4. 2. 2021 21:56

    Cabrón

    Opravte mne pokud se mýlím, ale WebExtension doplněk žádné speciální povolení pro stahování kódu nepotřebuje - může do stránky vložit <script> (většina si o přístup k DOMu říká), ten script si může tahat libovolný payload odkudkoliv a spouštět ho, a např. na stránce transparentně odchytávat události klávesnice nebo brabčit localStorage a některé cookies. Serveru útočníka stačí posílat adekvátní CORS hlavičky.

    Obranou jsou doplňky pro selektivní blacklisting souborů podle URL, ale to jednak málokdo používá a jednak je to na ústupu (uMatrix končí, například).

  • 5. 2. 2021 1:31

    bez přezdívky

    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.

  • 5. 2. 2021 8:48

    Filip Jirsák

    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…)

  • 5. 2. 2021 9:22

    ...

    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.

  • 5. 2. 2021 9:49

    Filip Jirsák

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

  • 5. 2. 2021 10:15

    ...

    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.

  • 5. 2. 2021 11:02

    Filip Jirsák

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

  • 5. 2. 2021 11:32

    ...

    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.

  • 5. 2. 2021 12:05

    Filip Jirsák

    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.

  • 12. 2. 2021 2:55

    ebik

    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.

  • 12. 2. 2021 8:10

    Filip Jirsák

    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.