korrektiewe vrystellings van die verspreide bronbeheerstelsel Git 2.24.1, 2.23.1, 2.22.2, 2.21.1, 2.20.2, 2.19.3, 2.18.2, 2.17.3, 2.16.6, 2.15.4 en 2.14.62.24.1 XNUMX, wat kwesbaarhede reggestel het wat 'n aanvaller toegelaat het om arbitrêre paaie in die lêerstelsel te herskryf, afgeleë kode-uitvoering te organiseer of lêers in die ".git/"-gids te oorskryf. Die meeste probleme wat deur werknemers geïdentifiseer is
Microsoft Security Response Center, vyf van die agt kwesbaarhede is spesifiek vir die Windows-platform.
- - stroomopdrag "feature export-marks=path" skryf etikette na arbitrêre dopgehou, wat gebruik kan word om arbitrêre paaie in die lêerstelsel te oorskryf wanneer 'n "git fast-import"-bewerking uitgevoer word met ongemerkte invoerdata.
- - verkeerde ontsnapping van opdragreëlargumente na afstanduitvoering van aanvallerkode tydens rekursiewe kloning deur die ssh:// URL te gebruik. In die besonder, ontsnappingsargumente wat op 'n terugskuinsstreep eindig (byvoorbeeld "toets \") is verkeerd hanteer. In hierdie geval, wanneer 'n argument met dubbele aanhalings geformuleer is, is die laaste aanhaling ontsnap, wat dit moontlik gemaak het om die vervanging van jou opsies op die opdragreël te organiseer.
- - wanneer submodules rekursief gekloon word ("kloon —recurse-submodules") in die Windows-omgewing onder sekere omstandighede aktiveer die gebruik van dieselfde git-gids twee keer (.git, git~1, git~2 en git~N word erken as een gids in NTFS, maar hierdie situasie is slegs vir git~1 getoets), wat gebruik kan word om te organiseer skryf na die gids ". git". Om die uitvoering van sy kode te organiseer, kan 'n aanvaller byvoorbeeld sy script vervang deur die post-checkout hanteerder in die .git/config lêer.
- - die hanteerder vir letteraandrywingname in Windows-paaie wanneer paaie soos "C:\" vertaal word, is slegs ontwerp om enkelletter Latynse identifiseerders te vervang, maar het nie die moontlikheid in ag geneem om virtuele aandrywers te skep wat toegewys is via "subst letter:path" . Sulke paaie is nie as absoluut nie, maar as relatiewe paaie behandel, wat dit moontlik gemaak het om 'n rekord in 'n arbitrêre gids buite die werkgidsboom te organiseer wanneer 'n kwaadwillige bewaarplek gekloon is (byvoorbeeld wanneer nommers of unicode karakters in die skyf gebruik word naam - "1:\wat\die\ hex.txt" of "ä:\tschibät.sch").
- - wanneer u op die Windows-platform werk, die gebruik van alternatiewe datastrome in NTFS, geskep deur die ":stream-name:stream-type"-kenmerk by die lêernaam by te voeg, oorskryf lêers in die ".git/"-gids wanneer 'n kwaadwillige bewaarplek gekloon word. Byvoorbeeld, die naam ".git::$INDEX_ALLOCATION" in NTFS is as 'n geldige skakel na die ".git"-gids hanteer.
- - wanneer Git in 'n WSL (Windows Subsystem for Linux) omgewing gebruik word wanneer toegang tot die werkgids verkry word beskerming teen naammanipulasie in NTFS (aanvalle deur FAT naam vertaling was moontlik, byvoorbeeld, ".git" kon verkry word deur die "git~1" gids).
- -
skryf na die ".git/"-gids op die Windows-platform wanneer kwaadwillige bewaarplekke gekloon word wat lêers bevat met 'n backslash in die naam (byvoorbeeld "a\b"), wat aanvaarbaar is op Unix/Linux, maar aanvaar word as deel van die pad op Windows. - - onvoldoende kontrolering van submodule name kan gebruik word om geteikende aanvalle te organiseer, wat, indien rekursief gekloon, moontlik kan om die aanvaller se kode uit te voer. Git het nie die skep van 'n submodule-gids binne 'n ander submodule se gids verhoed nie, wat in die meeste gevalle net tot verwarring sou lei, maar het nie moontlik verhoed dat die inhoud van 'n ander module tydens die rekursiewe kloningsproses oorskryf word nie (byvoorbeeld die submodule-gidse "seekoei" en "seekoei/hooks" word geplaas as ".git/modules/seekoei/" en ".git/modules/seekoei/hooks/", en die hakegids in seekoei kan afsonderlik gebruik word om geaktiveerde hake te huisves.
Windows-gebruikers word aangeraai om onmiddellik hul weergawe van Git op te dateer, en om nie ongeverifieerde bewaarplekke te kloneer tot die opdatering nie. As dit nog nie moontlik is om die Git-weergawe dringend op te dateer nie, word dit aanbeveel om nie "git clone —recurse-submodules" en "git submodule update" met ongemerkte bewaarplekke te laat loop om die risiko van aanval te verminder, om nie "git te gebruik nie. vinnig invoer" met ongemerkte invoerstrome, en nie om bewaarplekke na NTFS-gebaseerde partisies te kloon nie.
Vir ekstra sekuriteit verbied nuwe vrystellings ook die gebruik van konstrukte van die vorm "submodule.{name}.update=!command" in .gitmodules. Vir verspreidings kan u die vrystelling van pakketopdaterings op die bladsye dop ,, , , , , , .
Bron: opennet.ru