corrective release ng distributed source control system 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 at 2.14.62.24.1. XNUMX, na nag-ayos ng mga kahinaan na nagbigay-daan sa isang attacker na muling isulat ang mga arbitrary na path sa file system, ayusin ang remote code execution, o i-overwrite ang mga file sa direktoryo ng “.git/”. Karamihan sa mga problema ay natukoy ng mga empleyado
Microsoft Security Response Center, lima sa walong mga kahinaan ay partikular sa Windows platform.
- — streaming command na “feature export-marks=path” sumulat ng mga label sa mga di-makatwirang direktoryo, na maaaring magamit upang i-overwrite ang mga arbitrary na landas sa file system kapag nagsasagawa ng "git fast-import" na operasyon na may walang check na data ng input.
- - hindi tamang pagtakas sa mga argumento ng command line sa malayuang pagpapatupad ng attacker code sa panahon ng recursive cloning gamit ang ssh:// URL. Sa partikular, ang pagtakas sa mga argumento na nagtatapos sa isang backslash (halimbawa, "pagsubok \") ay hindi nahawakan nang tama. Sa kasong ito, kapag nag-frame ng argumento na may double quote, ang huling quote ay nakatakas, na naging posible upang ayusin ang pagpapalit ng iyong mga opsyon sa command line.
- — kapag recursively cloning submodules (“clone —recurse-submodules”) sa Windows environment sa ilalim ng ilang partikular na kundisyon na-trigger ang paggamit ng parehong git directory nang dalawang beses (.git, git~1, git~2 at git~N ay kinikilala bilang isang direktoryo sa NTFS, ngunit ang sitwasyong ito ay sinubukan lamang para sa git~1), na maaaring magamit upang ayusin pagsulat sa direktoryo na ". git". Upang ayusin ang pagpapatupad ng kanyang code, ang isang attacker, halimbawa, ay maaaring palitan ang kanyang script sa pamamagitan ng post-checkout handler sa .git/config file.
- — ang handler para sa mga pangalan ng letter drive sa mga path ng Windows kapag nagsasalin ng mga path tulad ng “C:\” ay idinisenyo lamang upang palitan ang mga single-letter na Latin identifier, ngunit hindi isinasaalang-alang ang posibilidad ng paglikha ng mga virtual drive na itinalaga sa pamamagitan ng “subst letter:path” . Ang ganitong mga landas ay itinuturing hindi bilang ganap, ngunit bilang mga kamag-anak na landas, na naging posible, kapag nag-clone ng isang malisyosong imbakan, upang ayusin ang isang tala sa isang di-makatwirang direktoryo sa labas ng puno ng gumaganang direktoryo (halimbawa, kapag gumagamit ng mga numero o unicode na mga character sa disk pangalan - “1:\what\the\ hex.txt" o "ä:\tschibät.sch").
- — kapag nagtatrabaho sa platform ng Windows, ang paggamit ng mga alternatibong stream ng data sa NTFS, na nilikha sa pamamagitan ng pagdaragdag ng attribute na “:stream-name:stream-type” sa pangalan ng file, i-overwrite ang mga file sa ".git/" na direktoryo kapag nag-clone ng malisyosong repositoryo. Halimbawa, ang pangalang ".git::$INDEX_ALLOCATION" sa NTFS ay itinuring bilang isang wastong link sa ".git" na direktoryo.
- — kapag gumagamit ng Git sa isang WSL (Windows Subsystem para sa Linux) na kapaligiran kapag ina-access ang gumaganang direktoryo proteksyon laban sa pagmamanipula ng pangalan sa NTFS (posible ang mga pag-atake sa pamamagitan ng pagsasalin ng pangalan ng FAT, halimbawa, maaaring ma-access ang ".git" sa pamamagitan ng direktoryo ng "git~1").
- -
sumusulat sa direktoryo ng ".git/" sa platform ng Windows kapag nag-clone ng mga nakakahamak na repositoryo na naglalaman ng mga file na may backslash sa pangalan (halimbawa, "a\b"), na katanggap-tanggap sa Unix/Linux, ngunit tinatanggap bilang bahagi ng ang landas sa Windows. - — hindi sapat na pagsuri ng mga pangalan ng submodule ay maaaring gamitin upang ayusin ang mga naka-target na pag-atake, na, kung recursively na-clone, ay posibleng upang isagawa ang code ng umaatake. Hindi napigilan ng Git ang paglikha ng isang direktoryo ng submodule sa loob ng direktoryo ng isa pang submodule, na sa karamihan ng mga kaso ay hahantong lamang sa kalituhan, ngunit hindi maaaring maiwasan ang mga nilalaman ng isa pang module na ma-overwrite sa panahon ng proseso ng recursive cloning (halimbawa, ang mga direktoryo ng submodule Ang "hippo" at "hippo/hooks" ay inilalagay bilang " .git/modules/hippo/" at ".git/modules/hippo/hooks/", at ang direktoryo ng mga hook sa hippo ay maaaring hiwalay na magamit upang mag-host ng mga na-trigger na hook.
Ang mga gumagamit ng Windows ay pinapayuhan na agad na i-update ang kanilang bersyon ng Git, at pigilin ang pag-clone ng mga hindi na-verify na repository hanggang sa pag-update. Kung hindi pa posible na agarang i-update ang bersyon ng Git, pagkatapos ay upang mabawasan ang panganib ng pag-atake, inirerekumenda na huwag patakbuhin ang "git clone —recurse-submodules" at "git submodule update" na may hindi naka-check na mga repositoryo, hindi gumamit ng "git fast-import" na may mga walang check na input stream, at hindi para i-clone ang mga repository sa mga partisyon na nakabatay sa NTFS.
Para sa karagdagang seguridad, ipinagbabawal din ng mga bagong release ang paggamit ng mga construct ng form na "submodule.{name}.update=!command" sa .gitmodules. Para sa mga pamamahagi, maaari mong subaybayan ang paglabas ng mga update sa package sa mga pahina ,, , , , , , .
Pinagmulan: opennet.ru