Vlákno názorů k článku Postřehy z bezpečnosti: v PyPI bylo objeveno přes sto balíčků s malwarem od jk3. - "Zatímco zdrojová podoba závadného balíčku je „čistá“, verze...
-
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.
-
Ta tvoje komunita se to vubec nemusi dozvedet, a to klidne nikdy. Znam osobne pripady kdy byl projekt predany nekomu jinemu, a to sakumprask se vsimvsudy - vcetne mailu, klicu atd atd.... ten nekdo dal pokracoval ve vyvoji, z pohledu uzivatele se vubec nic nezmenilo, jen par zasvecenych vedelo, ze to uz neni puvodni autor. Jeste vetsi posusnani je to na projektech, kde je to vic lidi. Ty lidi se prubezne menej, a kdykoli muze kdokoli z nich vlozit neco ne uplne kaleho, a nikdo nebude denne analyzovat kazdy patch.
S OSS to nema spolecnyho zhola nic.
-
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
googlesyndication.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.
-
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.
-
DannyStříbrný podporovatelOverit se to samozrejme da vzdycky. Jen u binarky je to overeni o dost pracnejsi. Jedno to neni.
-
Vidím rozdíl v čase detekce: build time, startup, runtime.
Zjistit, že je máte v aplikaci backdoor až když běží je leckdy prostě pozdě a škoda už mohla být napáchána. Nepomůže ani stage, ani tam nechcete nechat těžit kryproměny. A taky může trvat pěkně dlouho, než se aplikace prozradí podezřelou interakcí, takže to před produkcí (testování, stage) ani nemusí nastat.
V neposlední řadě nechcete spoléhat na to, že útočníci zrovna nejsou o krok napřed před vašimi detekčními nástroji.
Řešení je nenechat ty binárnky uploadovat autorem, ale buldit je transparentně ze zdrojáků tak, že budeme moci ověřit, co balík dělá, pohledem do kódu.
Jak lidská tak strojová detekce je u kódu snazší, a nevyžaduje spuštění. A ne, argument že to většina lidí nedělá neobstojí, protože množství lidí, kteřý by kontrolovali ty binárnky, je ještě menší...
