Vlákno názorů k článku Postřehy z bezpečnosti: nová aktivně zneužívaná zranitelnost Androidu od Jan - Ohledně Pythonu "Překontrolujte, zda tyto zákeřné knihovny omylem...

Ohledně Pythonu "Překontrolujte, zda tyto zákeřné knihovny omylem nepoužíváte. Pokud ano, nahraďte je a změňte všechny SSH a PGP klíče, které jste během minulého roku používali."

Já teda vůbec nemám přehled, která aplikace na Linuxu mi běží v Pythonu, ale jsem si jistý, že jich několik bude (sám si aktivně Python neinstaluji, ale dostane se mi tam přes systém dependencí, nebo už v Ubuntu byl) a že jsem i nějakou mohl spustit. A ostatní uživatelé na tom budou stejně.

Instrukci si teda překládám tak, že si v podstatě všichni uživatelé Linux mají změnit své ssh klíče.

To varování je spíš cíleno na lepiče, kteří se po dvouhodinovém youtube tutoriálu "Introduction to Django" prohlásí za backend developery. Ve webovém vývoji je bohužel běžná praxe používat správce balíčků třetích stran, kterým se předkládají seznamy závislostí někde sebrané z webu (requirements.txt u Pythonu, obdoba pro JS u npm, atd.). Repozitáře, ze kterých tyto nástroje čerpají, jsou často volně přístupné, kdokoliv může publikovat.

Běžně vídám situace, kdy vývojář chce něco zkusit, tak si vytvoří čistý virtualenv, do něj nasype requirements.txt toho, co ho zajímá, spustí na to `pip` a pak to všechno spustí pod rootem, aby mu to mohlo obsadit port 80 :-) virtualenv nijak neřeší přístup do filesystemu, takže v tu chvíli má úplně cizí kód root přístup a může si dělat co chce.

Ve světě Javascriptu je situace ještě absurdnější, tam mají i triviální aplikace graf závislostí se stovkami uzlů. Samostatný balíček pro červenou barvu atd. :-D

U systémových aplikací (těch v Pythonu, co máte v Ubuntu) se prakticky nikdy nepoužívají jiné balíčky, než ty systémové (v systémovém správci balíčků), takže by osudovou chybu musel udělat vývojář dané distribuce, což je daleko méně pravděpodobné.

to je jen otázka odkud to ten lepič získá. Tyhle balíčky se objevily v požadavcích na mirror na lokální pip repo na jednom projektu od několika vývojářů, takže někde nějaký ukázkový kód existoval. Tenhle problém nastává dlouhodobě u jakéhokoliv komunitního repa.

Mimochodem, tohle je vtipný problém "bezpečného" linuxu, všechny spuštěné procesy si prostě mohou přečíst bez problémů privátní klíče, knowhosts a spousty dalších důvěrných informací. Ten, kdo šifruje privátní klíč zase používá agenta, což je z bláta do louže.

Proto se postupně zavádí sandboxing. Unixový model důvěry v dnešní době (kdy každý denně stahujeme cizí kód a spouštíme ho pod svým účtem) už nefunguje, to mělo smysl na mainframech v dobách, kdy nebyly prohlížeče a web plný javascriptu.

Záleží, kde hostujete zdrojové kódy. Github requirements.txt kontroluje a posílá upozornění, když je tam verze s chybou.

jinak, váš příspěvek je takový zbytečný hejt na balíčkovací systémy.

@Jan [...] Instrukci si teda překládám tak, že si v podstatě všichni uživatelé Linux mají změnit své ssh klíče.

Ja si teda prekladam tak, ze v pripade ze neinstaluju python nebo jeho soucasti pouze ze systemoveho repositare za pomoci systemoveho nastroje pro spravu balicku ALE instaluju z python repositare PyPI pomoci python nastroje pro spravu "balicku" pip A zaroven sem timto pip instaloval "python3-dateutil" nebo "jeIlyfish"...
Protoze zakerne "balicky" NEbyli v systemovem, ale prave v tom PyPI repositari...