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
