Google har presenterat projektet OSS Rebuild för att identifiera dolda ändringar i paket.

Google har introducerat projektet OSS Rebuild, som syftar till att identifiera dolda ändringar i färdiga paket som publiceras i repon. OSS Rebuilds arbete är baserat på konceptet reproducibla byggen och handlar om att kontrollera att paketet som finns i repon stämmer överens med paketet som erhållits genom ombyggnad från den angivna källkoden som motsvarar den angivna paketversionen. Kodverktyget är skrivet i Go och distribueras under Apache 2.0-licensen.

För närvarande har OSS Rebuild stöd för verifiering av paket från repon som NPM (JavaScript/TypeScript), PyPI (Python) och Crates.io (Rust). I framtiden planerar man att utöka antalet stödda repon. I praktiken möjliggör verktyget att identifiera attacker av typen "supply chain", där efter att konton har komprometterats eller intriger har inträffat i projektet, publiceras en skadlig uppdatering i repon. Vid detta tillfälle förblir koden i det ursprungliga repon korrekt, medan skadliga ändringar endast införs i de färdiga paketen.

Systemet skapar automatiskt ett skript för reproducerbart bygge av det valda paketet, med hjälp av heuristik och genom att välja parametrar som möjliggör identiska artefakter i paketet. Om det inte går att reproducera paketet som finns i repon automatiskt, kan man manuellt lägga till byggspecifikationen. När paketet har kunnat reproduceras, sparar OSS Rebuilds verktyg en beskrivning av byggprocessen för framtida verifiering av nya versioner av paketet. Dessutom publiceras information för verifiering med hjälp av SLSA-ramverket.

Efter att verifieringen av en specifik version av paketet genomförts, genereras certifieringsdata som kan användas av andra för att bedöma redan verifierade paket. Verifieringen kan genomföras genom att köra kommandoradsverktyget eller genom att jämföra hash-värdet som sparats i en separat molnlagring. Infrastruktur för paketverifiering kan sättas upp på egen servern. Dessutom kan man få information om verifieringar som utförs av Google för flera tusen paket.

Exempel på olika attackmetoder som OSS Rebuild skulle kunna skydda mot inkluderar att lägga till en baksida i XZ, införa skadlig kod i den officiella JavaScript-klienten för kryptovalutan Solana och att införa ändringar genom changed-files-handlaren.

• I fallet med projektet XZ innehöll koden i repositoryt inga misstänkta ändringar, medan de komponenter som skapade baksidan levererades inuti filer som användes i testsviten för att kontrollera korrektheten av XZ:s avinstallerare. Baksidan aktiverades på byggsystemnivå, och själva koden för XZ överensstämde med koden i repositoryt. Aktiverande baksida m4-makron för Automake-verktyget inkluderades endast i den färdiga arkivfilen med koden och saknades i repositoryt. För att upptäcka sådana attacker i OSS Rebuild tillämpas dynamisk analys av paketartefakter, exekveringsvägar och misstänkta operationer.
• Införandet av skadliga ändringar i biblioteket @solana/web3.js inträffade på grund av en kompromiss av den ansvariga personens konto, med hjälp av metoder för social ingenjörskonst och phishing. En ny utgåva med skadliga ändringar publicerades i NPM-repositoryt. I projektets Git-repository skapades inte denna utgåva, och de skadliga ändringarna fanns endast i det resulterande paketet. Skyddet i detta fall består av att identifiera kod i paketet som saknas i det primära repositoryt.
• Kompromiss av repositoryt för changed-files möjliggjorde en attack på projekt som använder changed-files för att spåra förändringar av filer och kataloger i en GitHub Actions-baserad kontinuerlig integrationsinfrastruktur. För att skydda mot förändringsinförande efter en kompromiss av byggmiljön, tillämpas spårning av förändringar och misstänkt aktivitet i standardiserade nedskurna byggmiljöer i OSS Rebuild.

Källa: opennet.ru