Kwetsbaarheidspunte in GitHub Actions-hanterers, wat outomaties aangeroep word wanneer pull-versoeke na die Nixpkgs-pakketbewaarplek gestuur word, wat in die NixOS-verspreiding en die Nix-pakketbestuurder-ekosisteem gebruik word, is bekend gemaak. Die kwesbaarheid het 'n ongemagtigde gebruiker toegelaat om 'n token te onttrek wat lees- en skryftoegang verleen tot die bronkode van alle pakkette wat in Nixpkgs aangebied word. Hierdie token het direkte wysiging van enige pakket deur die projek se Git-bewaarplek toegelaat, wat die hersienings- en goedkeuringsprosesse omseil het.
Die vermoë om Nixpkgs te kompromitteer en persoonlike kode in enige pakket in te spuit, is verlede Oktober deur sekuriteitsnavorsers by die NixCon-konferensie gedemonstreer en is onmiddellik in die projek se infrastruktuur opgedateer. Besonderhede van die aanval is egter eers 'n jaar later bekend gemaak. Die probleem het verband gehou met die gebruik van GitHub Actions-hanterers in die Nixpkgs GitHub-bewaarplek, wat aan die "pull_request_target"-gebeurtenis gekoppel is en outomatiese kontroles uitvoer op nuwe pull-versoeke.
Anders as die "pull_request" gebeurtenis, word hanteerders in "pull_request_target" lees/skryf toegang tot die bou-omgewing verleen, wat spesiale sorg vereis wanneer daar met data gewerk word wat in 'n trekversoek deurgegee word. Een van die hanteerders wat aan "pull_request_target" gebind is, het die "OWNERS"-lĂȘer wat in die trekversoek verskaf is, bekragtig deur die kode-eienaars-validator-hulpprogram te bou en te roep: stappe: â gebruik: actions/checkout@eef61447b9ff4aafe5dcd4e0bbf met: ref: refs/pull/$/merge pad: pr â run: nix-build base/ci -A kode-eienaarsValidator â run: result/bin/kode-eienaars-validator env: EIENAARS_LĂER: pr/ci/EIENAARS
Die probleem was dat as die OWNERS-lĂȘer verkeerd geformateer was, die codeowners-validator-hulpprogram die inhoud van die misvormde string na die standaard, publiek toeganklike logboek sou uitvoer. Die aanval het bestaan ââuit die plasing van 'n simboliese skakel met die naam OWNERS in die pull-versoek, wat na die ".credentials"-lĂȘer wys, wat geloofsbriewe in die bou-omgewing stoor. Gevolglik het die verwerking van hierdie lĂȘer 'n fout tot gevolg gehad en die eerste reĂ«l, wat die toegangstoken vir die bewaarplek bevat, is na die publieke logboek uitgevoer.
Daarbenewens is nog 'n kwesbaarheid gevind in die hanteerder wat editorconfig-reĂ«ls nagaan. stappe: â naam: Kry lys van veranderde lĂȘers vanaf PR uitvoer: gh api [âŠ] | jq [ ⊠] > «$HOME/changed_files» â gebruike: actions/checkout@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871 met: verw: refs/pull/$/merge â naam: Kontroleer EditorConfig uitvoer: kat «$HOME/changed_files» | xargs -r editorconfig-checker
In hierdie geval was die probleem die gebruik van die "xargs"-hulpprogram om editorconfig-checker met elke lĂȘer in die trekversoek uit te voer. Aangesien lĂȘername nie gevalideer is nie, kan 'n aanvaller 'n lĂȘer met spesiale karakters in die trekversoek insluit, wat as opdragreĂ«largumente verwerk sou word wanneer editorconfig-checker uitgevoer word. Byvoorbeeld, wanneer 'n "--help"-lĂȘer geskep word, sou editorconfig-checker 'n wenk oor die beskikbare opsies vertoon.
Bron: opennet.ru
