Názory k článku Postřehy z bezpečnosti: v PyPI bylo objeveno přes sto balíčků s malwarem

Pamatuju si mé první pokusy s Javascriptem kdy jsem přitom nahlížel do příručka Javy a divil jsem se, že skoro nic z toho nefunguje

Musím ocenit smysl pro humor autorů Javy a JavaScriptu, když se po dvaceti letech vrátili na místo činu a dohodli se, že když do obou jazyků přidávají operátor šipky, musí být v jednom jazyce šipka s jednou čárkou a ve druhém se dvěma. Tradice je potřeba zachovávat, a když to má způsobovat zmatení, je potřeba mást i nastupující generace.

"Zatímco zdrojová podoba závadného balíčku je „čistá“, verze wheel je nakažená. Tu však správce balíčků pip upřednostňuje, takže si uživatel automaticky nainstaluje škodlivou verzi."
- A kdo za to nese zodpovědnost?

Že by ten, kdo udělal nakažený balíček? Nebo snad naše vláda?

Spravca repozitara balickov.

To je dost blbé, že si tam každý může dát beztrestně jakýkoliv malvér. To už je lepší používat jiné nástroje jak PyPI. A k PyPI přistupovat jako k permanentně zavirovanému.

Ne. Musíš používat ověřené knihovny. To znamená takové, které už nějakou dobu vyvíjí nějaký důvěryhodný vývojář s nějakou historií. To je úplně stejné jako u jakékoli knihovny. PyPI je prostředek, jak centrálně spravovat velké množství knihoven, ale to neznamená, že to je zásadně bezpečnější nebo méně bezpečné než třeba stahovat si ty knihovny z GitHubu.

Pokud je ale možné nějaký wheel udělat nakažený a "ekvivalentní" zdrojáky jsou čisté, je tam prostor pro řešení.

Seznam těch "nakažených" balíčků neobsahuje nic, o čem bych osobně slyšel. Pár věcí se snaží číhat na překlep (tikinters atd.), zbytek je binec.

To jiste, protoze uz zitra to nemuze nekomu pre(pro)dat. A ze takove pripady vubec ale vubec neexistuji.

A jak prosímtě poznám tu "ověřenou knihovnu"? Jsi si vědom toho, že takovýhle útok může udělat nepozorovaně i třetí strana bez vědomí správců, když se jí nějak podaří nabourat proces buildu? Díky neschopnosti to ověřit, může tam taková věc viset poměrně dlouho.

To vypada jako dan za jednoduchost pypi. Treba kdyz clovek neco uploaduje na Launchpad, tak uploadne jenom zdrojaky a binarky sestavuje Launchpad. To ovsem vyzaduje mnohem vetsi disciplinu pri tvorbe toho zdrojaku.

nemožnost si ověřit autenticitu toho, co je v pypi je jednoznačně problém pypi. Nedává žádný nástroj, jak lze garantovat či ověřit, že daný balíček je postavený z konkrétního zdrojového kódu.

Tohle znamená, že v produkcích nemůžeme přímo používat pypi repositáře, ale musí se vše klonovat interně, mít nad tím nějaký proces kontroly a pak to pustit do aplikací.

Jiste ... schvalne ju?

root.cz ...

ajax.googleapis.com
cloudflare.com
googlesyndica­tion.com
seznam.cz
performax.cz
...

Mam pokracovat? Jakej je v tom rozdil? Jo aha, to co sosa web je vlastne (jeste furt) primo zdrojak, ze? Takze je 100% jisty ze to dela presne to, co je v tom zdrojaku, ze?

Chmm ... a ? Jo aha, vysledek je ale uplne stejnej.

proč sem motáš web? Runtime aplikace může mít výrazně jiný pravidla než samotné její sestavení. Nerozumím jak to s tím souvisí.

Co nechapes na tom ze je uplne jedno jestli mas zdrojak a binarku nebo jen zdrojak, vysledek je presne stejnej.

Nikdo nikdy neni schopen nijak overit, ze soucasti neni nejakej cerv.

Kdyzbys to delat chtel, tak jiste vis, ze takovej proces zabere roky, a ty pak po tech letech nasadis ty roky stary knihovny, protoze u nich mas rekneme solidni pravdepodobnost, ze v nich nic neni. A i kdyz si budes chtit sam pro sebe auditovat pidiknihovnu, tak si ji muzes napsat sam, protoze to bude o rad rychlejsi nez zkoumat cizi vytvor.

Však to brzy bude v pořádku. Neustále čtu, že v otevřeném zdrojovém kódu je nesnadné skrýt škodlivý kód a komunita toto hlídá. Takže mohu bezproblémů stahovat a užívat. Oh wait, vlastně i já bych měl se hlídat, tak teď nevím, smím vůbec používat SW, když neumím si hlídat čistotu získaných kódů?

Pracuje se na tom, můžeš se zapojit.

To to nevysvetlis. Ja som sa o to pokusal uz tisikrat.

Ale však tá škodná nie je v zdrojáku, ale v binárke (Wheels)... zároveň FOSS neznamená väčšiu bezpečnosť, ale väčšiu možnosť overiť si bezpečnosť...U PyPi je problém ako už zaznelo že binárky sa nahrávajú osobitne, namiesto toho aby sa buildovali zo samotných poskytnutých zdrojákov... Ale to nie je chyba FOSS.. to je chyba len samotného PyPi...

Vždyť v článku je jasně napsáno, že ve zdrojovém kódu ten malware vůbec není a je jen v binárních balíčcích vedle. Takže prohlídkou zdrojových souborů se to vůbec nedalo najít a chyba rozhodně není v otevřeném přístupu ke zdrojákům.

Je to chyba konkrétní platformy, která umožňuje nahrát zvlášť zdrojáky a pak něco spustitelného, co mohlo vzniknout jakkoliv a ne sestavením z těch zdrojáků.

Akoze nedalo? ved ked zo dzrojaku vidim, ze to vola nejaku binrku, tak sa zameriam na danu binarku.

A teď se bavíš o konkrétním bezpečnostním problému s PyPi/pip, nebo o něčem obecném?

Ne, že to volá nějakou binárku, ale že vedle těch zdrojáků leží i nějaká zkompilovaná binárka. A na mou duši, na psí uši je to zkompilované z těch zdrojáků a ne úplně z něčeho jiného. Přísahám na zdraví svých dětí ;)

Takže problém není v open source, ale že PyPi si v některých aspektech na pořádné open source jen hraje.

Spise jen setri (sve) zdroje, ale s (ne)hrani na opensource to nesouvisi. Samozrejme, prekladat si ty binarky ze zdrojaku lokalne u PyPi by bylo urcite cistejsi reseni nez spolehat se na to, ze tu binarku treti strana uploadne spravne....

Ja skor poukazujem na to, ze ked je daco open source neimplikuje to z pohladu bezpenosti nic, lebo len veris, ze v tej binarke nie je nieco skodlive rovnako ako v uzavretom kode.

"Vždyť v článku je jasně napsáno, že ve zdrojovém kódu ten malware vůbec není"

Ehm.. ve zdrojovem kodu samozrejme je a byt musi, jak jinak by asi vznikla binarka. Problem je uplne jinde, publikovany zdrojovy kod neodpovida publikovane binarce.

Coz je neco, co obecne nema zadne reseni. Protoze dokazat, ze binarka a zdrojak si odpovidaji se nijak obecne neda, dokonce ani rekomplaci ne, protoze ta binarka bude typicky jina pri kazde kompilaci ze? Staci k tomu velmi malo.

Pokud si pamatuju, tak na to tema i tady nejaky ten clanek je, a zajistit, ze z konkretnich zdrojaku vypadne vzdy exaktne stejna binarka vyzaduje spoustu prace a velmi obsahlou dokumentaci na tema nastaveni prostredi.

nikoliv, binárku ti umím napsat i přímo ve strojovém kódu, kdysi jsme tak některé části také sestavovali po instrukcích.

Tady je ale asi myšleno, ve zdrojovém kódu samotného balíčku a ne někde u autora toho malware, že?

Ano, dá se dokázat, že binárka a zdroj si odpovídají, hledej "reproducible builds", to je tahounem poslední doby a kódy se tomu uzpůsobují. Jiná cesta asi nebude, problém nakažených binárek se zvětšuje.

Třeba takový nixos je celý postavený nad tím, že každé opakované volání má shodný výsledek, dostupných balíčků v něm je už ke sto tisícům vč. spousty python balíčků a teď nově se otevírá i spolupráce s php
https://phpconference.com/web-development/leveraging-nix-php-ecosystem/ a slidy tady https://github.com/drupol/ipc2023/releases/tag/v23-79efbb4c24ab0d42c73906d16233a79d9659c5ca)

openSUSE pokračuje ve svém tažení, https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/VWWVEPYEUBBMZN6K7VGUU5KKC7CBSSM2/, 87 % balíčků mají reproducible build.

Debian už pokořil hranici 90 % na většině platformách, https://tests.reproducible-builds.org/debian/reproducible.html

Kdyby to někoho zajímalo, tak na sledování změn v pypi používáme diffoscope.org, teď nově je i oficiálně "stable" na pypi repositáře. Mám chuť na to už nějakou dobu napsat článek a téma více osvětlit, třeba mě tohle donutí se tomu věnovat.

"Pro pravidelné spouštění malware využívá pod Windows naplánovaný VB skript"

VBScript je označený jako obsolette a v další verzi Win už bude jen jako Optional component

To mi nepřipadá moc optimistické, při průchodu minovým polem vědět, že tam nějaká bezpečná cestička musí být.

Navíc v kompibaci s typickým AI projektem, kterej těch knihoven jsou nižší desítky, s jejich dependencemi vyšší desítky, navíc "díky" zvykům v Pythoním ekosystému dost šasto velmi specifické na kompatibilní verze... Tohle už je dávno nad možnostmi běžného smrtelníka.

A to si predstav jaky je teprve bordel na webu a vsemoznych js knihoven, ktere ti patlalove tvorici web navic rovnou ze zcela anonymnich zdroju o kterych nic nevedi pouzivaji.