Tidligere denne uken ble to Python-biblioteker som inneholder skadelig kode fjernet fra Python Package Index (PyPI), Pythons offisielle lager for tredjepartspakker.
Det er den siste inkarnasjonen av et problem som mange moderne programvareutviklingssamfunn står overfor, og reiser et viktig spørsmål for alle utviklere som er avhengige av programvare med åpen kildekode: Hvordan kan du gjøre det mulig for folk å bidra med sin egen kode til et felles arkiv for gjenbruk , uten at disse repoene ble vektorer for angrep?
I det store og hele er de offisielle biblioteksregistrene fra tredjeparter for språk som er åpne kildekodeprosjekter, som Python, trygge. Men ondsinnede versjoner av et bibliotek kan spre seg raskt hvis de ikke er merket av. Og det faktum at de fleste slike språkoppbevaringssteder blir overvåket av frivillige, betyr at bare så mange øyne er på utkikk, og bidragene får ikke alltid den nødvendige granskingen.
De to ondsinnede pakkene som ble fjernet fra PyPI denne uken, brukte et triks som ble kalt “skrivefeil,” dvs. å velge navn som er lik nok til ofte brukte pakker for å glemme varsel, og som kan føre til utilsiktet installasjon hvis noen feil skriver inn det tiltenkte navnet. Forsøk på å maskere som dateutil og manet pakker - brukt til å manipulere Python datetime-objekter og utføre omtrentlige treff på henholdsvis strenger - de ondsinnede pakkene fikk navnetpython-dateutil og jeIlyfish (med store bokstaver I i stedet for den første små bokstaven L).
Når installert,python-dateutil og jeIlyfish oppførte seg akkurat som originalene - bortsett fra å prøve å stjele personlige data fra utvikleren. Paul Ganssle, en utvikler på dateutil team, fortalte ZDNet at den sannsynlige årsaken til angrepet var å finne ut hvilke prosjekter offeret jobbet med, for å starte senere angrep på disse prosjektene.
Python-biblioteker faller vanligvis i to leirer - modulene som utgjør standardbiblioteket som leveres med Python-kjøretiden, og tredjepartspakker som er vert på PyPI. Mens modulene i standardbiblioteket er nøye inspisert og nøye undersøkt, er PyPI langt mer åpent av design, slik at fellesskapet av Python-brukere fritt kan bidra med pakker for gjenbruk.
Ondsinnede prosjekter er funnet på PyPI før. I ett tilfelle satte skadelige pakker feil på Django-rammeverket, en stift for webutvikling i Python. Men problemet ser ut til å bli stadig mer presserende.
“Som medlem av Python-sikkerhetsteamet (PSRT) får jeg rapporter om skrivefeil eller skadelige pakker hver uke,” sa Christian Heimes, en kjerne Python-utvikler, i Pythons offisielle utviklingsdiskusjonsforum. “(Morsomt faktum: Det var fire e-posttråder om skadelig innhold på PyPI denne måneden, og i dag er det bare 4. desember.)”
Python Software Foundation har planer på bordet for å beskytte PyPI mot misbruk, men de vil ta tid å fullføre. Tidligere i år rullet Python-teamet ut tofaktorautentisering som et alternativ for PyPI-brukere som laster opp pakker. Det gir et beskyttelseslag for utviklere som laster opp til PyPI, noe som gjør det vanskeligere å kapre kontoene sine og laste opp skadelig programvare i deres navn. Men det adresserer ikke skrivehuk eller andre misbruk av allmenningen.
Andre tiltak inkluderer å se på måter å kompensere for problemene med automatisering. Arbeidsgruppen i Python Software Foundation som håndterer emballasje har mottatt tilskudd fra Facebook Research for å lage mer avanserte PyPI-sikkerhetsfunksjoner, for eksempel kryptografisk signering av PyPI-pakker, og automatisk påvisning av ondsinnede opplastinger (i stedet for arbeidskrevende manuell screening).
Tredjeparter tilbyr også en viss beskyttelse. Reversing Labs, et uavhengig sikkerhetsfirma, oppdaget et PyPI-basert angrep etter å ha gjennomført en skanning av hele depotet for mistenkelige filformater. Men selskapet innrømmer at slike skanninger ikke er en erstatning for intern kontroll. "For å redusere muligheten for å være vert for skadelig programvare," skrev selskapet, "vil slike arkiver alle ha nytte av kontinuerlig behandling og en bedre gjennomgangsprosess."
Den beste løsningen, som Pythons egne utviklere er klar over, må komme innenfra.
