Tilanne alkoi arkisesta siivouksesta. Kehittäjä, joka kirjoittaa verkossa nimimerkillä ferstar, huomasi MacBook Airinsa levytilan käyvän vähiin ja avasi kotihakemistonsa piilokansiot. Kansio ~/.zcode oli paisunut yli 700 megatavuun. Sen sisällä, polussa v2/checkpoints, odotti yksi salattu tiedosto: 313 070 842 tavua.
Vieressä ollut metadatatiedosto kertoi lopun. Paketti oli niin sanottu baseline-tilannevedos, joka sisälsi 42 411 tiedostoa ja jonka lähetys oli jäänyt jumiin. Yritykset oli laskettu: 564.
Kyseessä oli ZCode, kiinalaisen Z.ai:n koodiagentti. Sama yhtiö tekee avoimin painokertoimin julkaistavia GLM-malleja ja on Kiinan suurimpia tekoäly-yhtiöitä. Hän purki ohjelman Electron-paketin auki ja julkaisi löydöksensä 18. syyskuuta blogissaan. Juttu nousi saman päivän aikana Hacker Newsin kärkeen.
“Niin kauan kuin olet kirjautuneena sisään, tämä taustaputki on pysyvästi päällä, eikä mikään käyttöliittymän asetus sammuta sitä.”
Miksi .git-kansion vuoto on pahempi kuin yhden tiedoston
Paketin sisältö jakautui ferstarin julkaiseman manifestin mukaan kolmeen osaan. Git LFS -välimuisti vei 196,1 megatavua, .git/objects 102,2 megatavua ja varsinainen lähdekoodi dokumentteineen noin 46 megatavua. Versionhallinnan kansio muodosti siis 86,6 prosenttia koko lastista.
Ero yksittäiseen tiedostoon on olennainen. Yksi tiedosto kertoo, miltä koodi näyttää tänään. Objektikanta kertoo, miltä se on näyttänyt joka ikinen kerta. Jos kehittäjä on joskus tallentanut commitiin rajapinta-avaimen tai tietokannan salasanan ja poistanut sen seuraavassa, avain on yhä kannassa. Poistaminen ei poista gitissä mitään, se lisää uuden version vanhan päälle.
Mukana oli myös kansio .git/logs, kooltaan vaatimaton 0,6 megatavua. Reflog kertoo, mitä haaroja koneella on luotu ja mitä on poistettu, myös ne joita ei ole koskaan työnnetty palvelimelle. Commit-historia puolestaan sisältää jokaisen tekijän nimen ja sähköpostiosoitteen. Yhdessä nämä piirtävät kartan siitä, ketkä yrityksessä työskentelevät minkäkin parissa ja mitä on kokeiltu ja hylätty.
Salaus, jonka avainta käyttäjällä ei ollut
ZCode salasi paketin AES-256-CTR-algoritmilla ja kääri istuntoavaimen RSA-OAEP-SHA256:lla. Julkinen avain tuli palvelimelta kunkin latauskierroksen alussa. Yksityinen avain ei käynyt käyttäjän koneella missään vaiheessa.
Kehittäjä ei siis pystynyt avaamaan omalla kiintolevyllään makaavaa pakettia. Siihen ei pystynyt ZCode-ohjelma itsekään. Juuri tätä ferstar piti ratkaisevana yksityiskohtana: jos toiminto olisi tarkoitettu käyttäjän omaan varmuuskopiointiin tai synkronointiin, avaimen kuuluisi olla käyttäjällä.
Asetuksista löytyi kaksi kytkintä, Optimize Experience ja Repo Snapshot Indexing. Kumpikaan ei estänyt pakkausta eikä lähetystä. Ne säätelivät vain sitä, saako aineistoa käyttää mallien koulutukseen.
Yhtiön vastine: anteeksipyyntö, poisto ja Apache 2.0
Z.ai pyysi anteeksi perjantaina. Yhtiön mukaan ongelma liittyi ZCoden koodipohjan indeksointiin ja Repo Wiki -toimintoon, joka oli tuotteen alkuvaiheessa päällä oletuksena.
“Kun Repo Wiki -toiminto luo wikisivuja, se voi käynnistää arkiston datan lähetyksen. Kun sivut on luotu pilvessä, lähetetty data tuhotaan välittömästi eikä sitä säilytetä.”
Tom's Hardwarelle antamassaan lausunnossa yhtiö kertoi korjanneensa käyttäjien tiedostojen ja datan lähettämisen ilman suostumusta ja vakuutti, että pilveen päätynyt aineisto on tuhottu. Latausputki poistettiin ohjelmasta versiossa 3.14.0. Vika havaittiin versiossa 3.12.3, joka oli julkaistu 17. syyskuuta.
Sunnuntaina 20. syyskuuta Z.ai avasi ZCoden lähdekoodin GitHub:ssa Apache 2.0 -lisenssillä ja lupasi ulkopuolisen arvioijan tarkastavan koodin. Repositorio keräsi vuorokaudessa yli 5 400 tähteä. Lausunnot on annettu yhtiön nimissä, eikä kukaan Z.ai:n johdosta ole kommentoinut tapausta omalla nimellään. Sitä, onko kerätty aineisto todella tuhottu, käyttäjä ei pysty itse tarkistamaan. Se on luottamuskysymys, ei tekninen.
Mitä tarkistaa, jos koodiagentti on jo käytössä
Tapaus ei vaadi paniikkia vaan yhden iltapäivän työn. Nämä kohdat kannattaa käydä läpi jokaisesta agenttityökalusta, joka on otettu käyttöön ilman tietoturva-arviota.
1. Katso, mitä työkalu kirjoittaa levylle. Kotihakemiston piilokansiot kertovat enemmän kuin tuotesivu. Iso salattu tiedosto, jonka avainta sinulla ei ole, on hälytysmerkki.
2. Mittaa lähtevä liikenne verkon reunalta, älä sovelluksen omasta lokista. Sovellus kertoo vain sen, mitä se on ohjelmoitu kertomaan.
3. Selvitä, ulottuuko indeksointi .git-kansioon. Jos ulottuu, oletus on että vanhat salaisuudet ovat mukana.
4. Vaihda ne salasanat ja avaimet, jotka ovat joskus olleet commitissa. Tämä kannattaa tehdä riippumatta siitä, onko vuotoa tapahtunut.
5. Kirjaa työkalu toimittajarekisteriin. Koodiagentti on alihankkija, jolla on pääsy koko koodipohjaan.
