ტროას წყაროს შეტევა კოდის ცვლილებების შესატანად, რომლებიც უხილავია დეველოპერისთვის

კემბრიჯის უნივერსიტეტის მკვლევარებმა გამოაქვეყნეს მავნე კოდის ჩუმად ჩასმის ტექნიკა თანატოლების მიერ განხილულ წყაროში. მომზადებული თავდასხმის მეთოდი (CVE-2021-42574) წარმოდგენილია სახელწოდებით Trojan Source და ეფუძნება ტექსტის ფორმირებას, რომელიც განსხვავებულად გამოიყურება შემდგენლის/ინტერპრეტიტორისა და კოდის მნახველი პირისთვის. მეთოდის მაგალითები ნაჩვენებია C, C++ (gcc და clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go და Python-ისთვის მოწოდებული სხვადასხვა შემდგენელებისა და ინტერპრეტატორებისთვის.

მეთოდი ეფუძნება სპეციალური Unicode სიმბოლოების გამოყენებას კოდის კომენტარებში, რომლებიც ცვლის ორმხრივი ტექსტის ჩვენების ბრძანებას. ასეთი საკონტროლო სიმბოლოების დახმარებით, ტექსტის ზოგიერთი ნაწილის ჩვენება შესაძლებელია მარცხნიდან მარჯვნივ, ზოგი კი - მარჯვნიდან მარცხნივ. ყოველდღიურ პრაქტიკაში, ასეთი საკონტროლო სიმბოლოები შეიძლება გამოყენებულ იქნას, მაგალითად, ფაილში ებრაული ან არაბული კოდის ხაზების ჩასასმელად. მაგრამ თუ თქვენ დააკავშირებთ ხაზებს სხვადასხვა ტექსტის მიმართულებებს ერთ სტრიქონში, მითითებული სიმბოლოების გამოყენებით, ტექსტის პასაჟები, რომლებიც ნაჩვენებია მარჯვნიდან მარცხნივ, შეიძლება გადაფაროს არსებულ ჩვეულებრივ ტექსტზე, რომელიც ნაჩვენებია მარცხნიდან მარჯვნივ.

ამ მეთოდის გამოყენებით, თქვენ შეგიძლიათ დაამატოთ მავნე კონსტრუქცია კოდში, მაგრამ შემდეგ ამ კონსტრუქციის ტექსტი გახადეთ უხილავი კოდის ნახვისას შემდეგ კომენტარში ან მარჯვნიდან მარცხნივ ნაჩვენები პირდაპირი სიმბოლოების შიგნით, რაც გამოიწვევს მთლიანად მავნე ჩასმაზე ზედმიწევნით სხვადასხვა სიმბოლოები. ასეთი კოდი დარჩება სემანტიკურად სწორი, მაგრამ განსხვავებულად იქნება ინტერპრეტირებული და ნაჩვენები.

კოდის განხილვისას დეველოპერი შეხვდება სიმბოლოების ვიზუალურ წესრიგს და დაინახავს არასაეჭვო კომენტარს თანამედროვე ტექსტურ რედაქტორში, ვებ ინტერფეისში ან IDE-ში, მაგრამ შემდგენელი და თარჯიმანი გამოიყენებს სიმბოლოების ლოგიკურ წესრიგს და დაამუშავეთ მავნე ჩასმა ისე, როგორც არის, კომენტარებში ორმხრივი ტექსტისთვის ყურადღების მიქცევის გარეშე. პრობლემა ეხება სხვადასხვა პოპულარულ კოდის რედაქტორებს (VS Code, Emacs, Atom), ასევე ინტერფეისებს საცავებში კოდის სანახავად (GitHub, Gitlab, BitBucket და ყველა Atlassian პროდუქტი).

მავნე ქმედებების განსახორციელებლად მეთოდის გამოყენების რამდენიმე გზა არსებობს: დამალული „დაბრუნების“ გამოხატვის დამატება, რაც იწვევს ფუნქციის ვადაზე ადრე დასრულებას; გამონათქვამების კომენტირება, რომლებიც ჩვეულებრივ ხილული იქნება, როგორც სწორი კონსტრუქტები (მაგალითად, მნიშვნელოვანი შემოწმების გამორთვა); სტრიქონების სხვა მნიშვნელობების მინიჭება, რაც იწვევს სტრიქონების ვალიდაციის წარუმატებლობას.

მაგალითად, თავდამსხმელმა შეიძლება შესთავაზოს ცვლილება, რომელიც მოიცავს ხაზს: if access_level != "user{U+202E} {U+2066}// შეამოწმეთ თუ admin{U+2069} {U+2066}" {

რომელიც ნაჩვენები იქნება მიმოხილვის ინტერფეისში, თითქოს access_level != “user” { // შეამოწმეთ თუ ადმინისტრატორი

გარდა ამისა, შემოთავაზებულია თავდასხმის სხვა ვარიანტი (CVE-2021-42694), რომელიც დაკავშირებულია ჰომოგლიფების გამოყენებასთან, სიმბოლოებით, რომლებიც მსგავსია გარეგნულად, მაგრამ განსხვავდებიან მნიშვნელობით და აქვთ განსხვავებული უნიკოდის კოდები (მაგალითად, სიმბოლო „ɑ“ წააგავს „ a", "ɡ" - "g", "ɩ" - "l"). მსგავსი სიმბოლოები შეიძლება გამოყენებულ იქნას ზოგიერთ ენაში ფუნქციების და ცვლადების სახელწოდებით დეველოპერების შეცდომაში შეყვანისთვის. მაგალითად, შეიძლება განისაზღვროს ორი ფუნქცია ერთმანეთისგან განსხვავებულ სახელებთან, რომლებიც ასრულებენ სხვადასხვა მოქმედებებს. დეტალური ანალიზის გარეშე, მაშინვე არ არის ნათელი, ამ ორი ფუნქციიდან რომელია მოწოდებული კონკრეტულ ადგილას.

როგორც უსაფრთხოების ზომა, რეკომენდირებულია, რომ შემდგენელებმა, თარჯიმნებმა და ასამბლეის ინსტრუმენტებმა, რომლებიც მხარს უჭერენ უნიკოდის სიმბოლოებს, აჩვენებენ შეცდომას ან გაფრთხილებას, თუ არის დაუწყვილებელი საკონტროლო სიმბოლოები კომენტარებში, სტრიქონების ლიტერალებში ან იდენტიფიკატორებში, რომლებიც ცვლის გამომავალი მიმართულებას (U+202A, U+202B, U +202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E და U+200F). ასეთი სიმბოლოები ასევე აშკარად უნდა იყოს აკრძალული პროგრამირების ენის სპეციფიკაციებში და დაცული უნდა იყოს კოდის რედაქტორებსა და საცავის ინტერფეისებში.

დანართი 1: მოწყვლადობის პატჩები მომზადდა 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\uXNUMX\uXNUMX\uXNUMX\uXNUMX/path/' წყარო

დანართი 2: Russ Cox, Plan 9 OS და Go პროგრამირების ენის ერთ-ერთი შემქმნელი, გააკრიტიკა გადაჭარბებული ყურადღება აღწერილი თავდასხმის მეთოდის მიმართ, რომელიც დიდი ხანია ცნობილია (Go, Rust, C++, Ruby) და არ იყო სერიოზულად მიღებული. . კოქსის თქმით, პრობლემა ძირითადად ეხება ინფორმაციის სწორად ჩვენებას კოდის რედაქტორებში და ვებ ინტერფეისებში, რაც შეიძლება გადაიჭრას სწორი ინსტრუმენტებისა და კოდის ანალიზატორების გამოყენებით განხილვისას. ამიტომ, სპეკულაციურ თავდასხმებზე ყურადღების მიქცევის ნაცვლად, უფრო მიზანშეწონილი იქნება კოდის და დამოკიდებულების განხილვის პროცესების გაუმჯობესებაზე ფოკუსირება.

რას კოქსი ასევე თვლის, რომ შემდგენლები არ არის სწორი ადგილი პრობლემის მოსაგვარებლად, რადგან სახიფათო სიმბოლოების აკრძალვით შემდგენლის დონეზე რჩება ინსტრუმენტების უზარმაზარი ფენა, რომლებშიც ამ სიმბოლოების გამოყენება მისაღები რჩება, როგორიცაა build სისტემები, ასამბლერები, პაკეტის მენეჯერები და სხვადასხვა კონფიგურაციის პარსერები და მონაცემები. მაგალითად, მოყვანილია Rust პროექტი, რომელმაც აკრძალა LTR/RTL კოდის დამუშავება შემდგენელში, მაგრამ არ დაუმატა დაფიქსირება Cargo პაკეტის მენეჯერს, რომელიც საშუალებას იძლევა მსგავსი შეტევა Cargo.toml ფაილის მეშვეობით. ანალოგიურად, ფაილები, როგორიცაა BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml და მოთხოვნები.txt, შეიძლება გახდეს თავდასხმების წყარო.

წყარო: opennet.ru