ການໂຈມຕີແຫຼ່ງ Trojan ເພື່ອແນະນໍາການປ່ຽນແປງລະຫັດທີ່ເບິ່ງບໍ່ເຫັນກັບນັກພັດທະນາ

ນັກຄົ້ນຄວ້າຈາກມະຫາວິທະຍາໄລ Cambridge ໄດ້ເຜີຍແຜ່ເຕັກນິກສໍາລັບການໃສ່ລະຫັດທີ່ເປັນອັນຕະລາຍຢ່າງງຽບໆເຂົ້າໄປໃນລະຫັດແຫຼ່ງທີ່ທົບທວນຄືນໂດຍຫມູ່ເພື່ອນ. ວິທີການໂຈມຕີທີ່ກຽມໄວ້ (CVE-2021-42574) ຖືກນໍາສະເຫນີພາຍໃຕ້ຊື່ Trojan Source ແລະອີງໃສ່ການສ້າງຂໍ້ຄວາມທີ່ມີລັກສະນະທີ່ແຕກຕ່າງກັນສໍາລັບຜູ້ລວບລວມຂໍ້ມູນ / ນາຍແປພາສາແລະຜູ້ທີ່ເບິ່ງລະຫັດ. ຕົວຢ່າງຂອງວິທີການແມ່ນສະແດງໃຫ້ເຫັນສໍາລັບ compilers ແລະແປພາສາຕ່າງໆທີ່ສະຫນອງສໍາລັບ C, C++ (gcc ແລະ clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go ແລະ Python.

ວິທີການແມ່ນອີງໃສ່ການນໍາໃຊ້ຕົວອັກສອນ Unicode ພິເສດໃນຄໍາເຫັນຂອງລະຫັດທີ່ປ່ຽນລໍາດັບການສະແດງຂອງຂໍ້ຄວາມສອງທິດທາງ. ດ້ວຍຄວາມຊ່ອຍເຫລືອຂອງລັກສະນະການຄວບຄຸມດັ່ງກ່າວ, ບາງສ່ວນຂອງຂໍ້ຄວາມສາມາດສະແດງຈາກຊ້າຍໄປຂວາ, ໃນຂະນະທີ່ອື່ນໆ - ຈາກຂວາໄປຊ້າຍ. ໃນການປະຕິບັດປະຈໍາວັນ, ຕົວອັກສອນຄວບຄຸມດັ່ງກ່າວສາມາດຖືກນໍາໃຊ້, ສໍາລັບການຍົກຕົວຢ່າງ, ເພື່ອແຊກເສັ້ນລະຫັດໃນພາສາ Hebrew ຫຼື Arabic ເຂົ້າໄປໃນໄຟລ໌. ແຕ່ຖ້າທ່ານສົມທົບເສັ້ນທີ່ມີທິດທາງຂໍ້ຄວາມທີ່ແຕກຕ່າງກັນໃນຫນຶ່ງແຖວ, ໂດຍໃຊ້ຕົວອັກສອນທີ່ລະບຸ, ຂໍ້ຄວາມທີ່ສະແດງຈາກຂວາຫາຊ້າຍສາມາດທັບຊ້ອນຂໍ້ຄວາມປົກກະຕິທີ່ມີຢູ່ຈາກຊ້າຍໄປຂວາ.

ການນໍາໃຊ້ວິທີການນີ້, ທ່ານສາມາດເພີ່ມໂຄງສ້າງທີ່ເປັນອັນຕະລາຍກັບລະຫັດ, ແຕ່ຫຼັງຈາກນັ້ນເຮັດໃຫ້ຂໍ້ຄວາມທີ່ມີໂຄງສ້າງນີ້ເບິ່ງບໍ່ເຫັນເມື່ອເບິ່ງລະຫັດ, ໂດຍການເພີ່ມຄໍາເຫັນຕໍ່ໄປນີ້ຫຼືພາຍໃນຕົວອັກສອນທີ່ສະແດງຈາກຂວາຫາຊ້າຍ, ເຊິ່ງຈະນໍາໄປສູ່ຄວາມສົມບູນ. ຕົວອັກສອນທີ່ແຕກຕ່າງກັນຖືກໃສ່ເທິງການແຊກທີ່ເປັນອັນຕະລາຍ. ລະຫັດດັ່ງກ່າວຈະຍັງຄົງຖືກຕ້ອງຕາມຄວາມໝາຍ, ແຕ່ຈະຖືກຕີຄວາມໝາຍ ແລະສະແດງຄວາມແຕກຕ່າງ.

ໃນຂະນະທີ່ທົບທວນລະຫັດ, ຜູ້ພັດທະນາຈະຖືກປະເຊີນຫນ້າກັບລໍາດັບສາຍຕາຂອງຕົວອັກສອນແລະຈະເຫັນຄໍາຄິດຄໍາເຫັນທີ່ບໍ່ຫນ້າສົງໄສໃນຕົວແກ້ໄຂຂໍ້ຄວາມທີ່ທັນສະໄຫມ, ການໂຕ້ຕອບເວັບຫຼື IDE, ແຕ່ຜູ້ລວບລວມແລະນາຍແປພາສາຈະໃຊ້ຄໍາສັ່ງຢ່າງມີເຫດຜົນຂອງຕົວອັກສອນແລະຈະ. ປະມວນຜົນການໃສ່ຮ້າຍກາດຕາມທີ່ເປັນຢູ່, ໂດຍບໍ່ຕ້ອງໃສ່ໃຈກັບຂໍ້ຄວາມສອງທິດທາງໃນຄຳເຫັນ. ບັນຫາມີຜົນຕໍ່ຕົວແກ້ໄຂລະຫັດທີ່ນິຍົມຕ່າງໆ (VS Code, Emacs, Atom), ເຊັ່ນດຽວກັນກັບການໂຕ້ຕອບສໍາລັບການເບິ່ງລະຫັດໃນ repositories (GitHub, Gitlab, BitBucket ແລະຜະລິດຕະພັນ Atlassian ທັງຫມົດ).

ມີຫລາຍວິທີທີ່ຈະໃຊ້ວິທີການປະຕິບັດການກະທໍາທີ່ເປັນອັນຕະລາຍ: ການເພີ່ມການສະແດງອອກ "ກັບຄືນ" ທີ່ເຊື່ອງໄວ້, ເຊິ່ງນໍາໄປສູ່ການສໍາເລັດຫນ້າທີ່ກ່ອນເວລາ; ການສະແດງຄວາມຄິດເຫັນທີ່ສະແດງອອກໂດຍປົກກະຕິຈະເຫັນໄດ້ວ່າເປັນໂຄງສ້າງທີ່ຖືກຕ້ອງ (ຕົວຢ່າງ, ເພື່ອປິດການກວດສອບທີ່ສໍາຄັນ); ການມອບຫມາຍຄ່າສະຕຣິງອື່ນໆທີ່ນໍາໄປສູ່ຄວາມລົ້ມເຫຼວຂອງການກວດສອບສາຍສະຕິງ.

ຕົວຢ່າງ, ຜູ້ໂຈມຕີອາດຈະສະເໜີການປ່ຽນແປງທີ່ປະກອບມີແຖວ: if access_level != "user{U+202E} {U+2066}// ກວດເບິ່ງວ່າ admin{U+2069} {U+2066}" {

ເຊິ່ງຈະຖືກສະແດງຢູ່ໃນການໂຕ້ຕອບການທົບທວນຄືນຄືກັບວ່າ access_level != "ຜູ້ໃຊ້" { // ກວດເບິ່ງວ່າ admin

ນອກຈາກນັ້ນ, ຕົວແປການໂຈມຕີອື່ນໄດ້ຖືກສະເຫນີ (CVE-2021-42694), ທີ່ກ່ຽວຂ້ອງກັບການນໍາໃຊ້ homoglyphs, ລັກສະນະທີ່ຄ້າຍຄືກັນ, ແຕ່ມີຄວາມແຕກຕ່າງກັນໃນຄວາມຫມາຍແລະມີລະຫັດ unicode ທີ່ແຕກຕ່າງກັນ (ຕົວຢ່າງ, ຕົວອັກສອນ "ɑ" ຄ້າຍຄື ". a”, “ɡ” - “g”, “ɩ” - “l”). ຕົວອັກສອນທີ່ຄ້າຍຄືກັນສາມາດຖືກນໍາໃຊ້ໃນບາງພາສາໃນຊື່ຂອງຫນ້າທີ່ແລະຕົວແປເພື່ອເຮັດໃຫ້ຜູ້ພັດທະນາຫຼອກລວງ. ຕົວຢ່າງ, ສອງຫນ້າທີ່ທີ່ມີຊື່ທີ່ບໍ່ສາມາດແຍກອອກໄດ້ອາດຈະຖືກກໍານົດທີ່ປະຕິບັດທີ່ແຕກຕ່າງກັນ. ໂດຍບໍ່ມີການວິເຄາະຢ່າງລະອຽດ, ມັນບໍ່ຊັດເຈນໃນທັນທີທີ່ສອງຫນ້າທີ່ນີ້ເອີ້ນວ່າຢູ່ໃນສະຖານທີ່ສະເພາະ.

ເປັນມາດຕະການຄວາມປອດໄພ, ແນະນໍາໃຫ້ຄອມພີວເຕີ, ນາຍພາສາ ແລະເຄື່ອງມືປະກອບທີ່ຮອງຮັບຕົວອັກສອນ Unicode ສະແດງຂໍ້ຜິດພາດ ຫຼືການເຕືອນຖ້າມີຕົວອັກສອນຄວບຄຸມທີ່ບໍ່ໄດ້ຈັບຄູ່ໃນຄໍາຄິດເຫັນ, ຕົວໜັງສືສະຕຣິງ ຫຼືຕົວລະບຸທີ່ປ່ຽນທິດທາງຂອງຜົນຜະລິດ (U+202A, U+202B, U +202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E ແລະ U+200F). ຕົວອັກສອນດັ່ງກ່າວຄວນຖືກຫ້າມຢ່າງຈະແຈ້ງໃນສະເພາະຂອງພາສາການຂຽນໂປຣແກຣມ ແລະຄວນເຄົາລົບໃນຕົວແກ້ໄຂລະຫັດ ແລະສ່ວນຕິດຕໍ່ຂອງບ່ອນເກັບຂໍ້ມູນ.

Addendum 1: vulnerability patches ໄດ້ຖືກກະກຽມສໍາລັບ GCC, LLVM/Clang, Rust, Go, Python ແລະ binutils. GitHub, Bitbucket ແລະ Jira ຍັງແກ້ໄຂບັນຫາດັ່ງກ່າວ. ການແກ້ໄຂສໍາລັບ GitLab ກໍາລັງດໍາເນີນຢູ່. ເພື່ອລະບຸລະຫັດທີ່ມີບັນຫາ, ມັນແນະນໍາໃຫ້ໃຊ້ຄໍາສັ່ງ: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069/'] ແຫຼ່ງ

Addendum 2: Russ Cox, ຫນຶ່ງໃນນັກພັດທະນາຂອງ Plan 9 OS ແລະພາສາການຂຽນໂປລແກລມ Go, ໄດ້ວິພາກວິຈານຄວາມສົນໃຈຫຼາຍເກີນໄປຕໍ່ວິທີການໂຈມຕີທີ່ອະທິບາຍ, ເຊິ່ງເປັນທີ່ຮູ້ຈັກກັນມາດົນນານ (Go, Rust, C++, Ruby) ແລະບໍ່ໄດ້ເອົາໃຈໃສ່ຢ່າງຈິງຈັງ. . ອີງຕາມ Cox, ບັນຫາສ່ວນໃຫຍ່ແມ່ນກ່ຽວຂ້ອງກັບການສະແດງຂໍ້ມູນທີ່ຖືກຕ້ອງໃນຕົວແກ້ໄຂລະຫັດແລະການໂຕ້ຕອບເວັບ, ເຊິ່ງສາມາດແກ້ໄຂໄດ້ໂດຍໃຊ້ເຄື່ອງມືທີ່ຖືກຕ້ອງແລະຕົວວິເຄາະລະຫັດໃນລະຫວ່າງການທົບທວນ. ດັ່ງນັ້ນ, ແທນທີ່ຈະດຶງດູດຄວາມສົນໃຈກັບການໂຈມຕີແບບຄາດເດົາ, ມັນຈະເຫມາະສົມກວ່າທີ່ຈະສຸມໃສ່ການປັບປຸງຂະບວນການທົບທວນລະຫັດແລະການເພິ່ງພາອາໄສ.

Ras Cox ຍັງເຊື່ອວ່າການລວບລວມຂໍ້ມູນບໍ່ແມ່ນບ່ອນທີ່ເຫມາະສົມທີ່ຈະແກ້ໄຂບັນຫາ, ເນື່ອງຈາກວ່າໂດຍການຫ້າມສັນຍາລັກອັນຕະລາຍໃນລະດັບການລວບລວມ, ຍັງມີອຸປະກອນຊັ້ນໃຫຍ່ທີ່ການນໍາໃຊ້ສັນຍາລັກເຫຼົ່ານີ້ຍັງຄົງເປັນທີ່ຍອມຮັບ, ເຊັ່ນ: ລະບົບການກໍ່ສ້າງ, ເຄື່ອງປະກອບ,. ຜູ້ຈັດການແພັກເກດ ແລະຕົວແຍກວິເຄາະການຕັ້ງຄ່າຕ່າງໆ ແລະຂໍ້ມູນ. ເປັນຕົວຢ່າງ, ໂຄງການ Rust ໄດ້ຖືກມອບໃຫ້, ເຊິ່ງຫ້າມການປຸງແຕ່ງລະຫັດ LTR / RTL ໃນ compiler, ແຕ່ບໍ່ໄດ້ເພີ່ມການແກ້ໄຂໃຫ້ກັບຜູ້ຈັດການຊຸດ Cargo, ເຊິ່ງອະນຸຍາດໃຫ້ມີການໂຈມຕີທີ່ຄ້າຍຄືກັນຜ່ານໄຟລ໌ Cargo.toml. ເຊັ່ນດຽວກັນ, ໄຟລ໌ເຊັ່ນ BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml ແລະ requirements.txt ສາມາດກາຍເປັນແຫຼ່ງທີ່ມາຂອງການໂຈມຕີ.

ແຫຼ່ງຂໍ້ມູນ: opennet.ru