Քեմբրիջի համալսարանի գիտնականները հրապարակել են մի տեխնիկա, որը թույլ է տալիս անաղմուկ մուտքագրել վնասակար ծածկագիրը գործընկերների կողմից վերանայված սկզբնական կոդի մեջ: Պատրաստված հարձակման մեթոդը (CVE-2021-42574) ներկայացված է Trojan Source անունով և հիմնված է տեքստի ձևավորման վրա, որը տարբեր տեսք ունի կոմպիլյատորի/թարգմանչի և կոդը դիտող անձի համար: Մեթոդի օրինակները ցուցադրվում են C, C++ (gcc և clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go և Python-ի համար տրամադրված տարբեր կոմպիլյատորների և թարգմանիչների համար:
Մեթոդը հիմնված է կոդի մեկնաբանություններում հատուկ Յունիկոդ նիշերի օգտագործման վրա, որոնք փոխում են երկկողմանի տեքստի ցուցադրման կարգը: Նման կառավարման նիշերի օգնությամբ տեքստի որոշ հատվածներ կարող են ցուցադրվել ձախից աջ, իսկ մյուսները՝ աջից ձախ: Առօրյա պրակտիկայում նման հսկիչ նիշերը կարող են օգտագործվել, օրինակ, ֆայլի մեջ եբրայերեն կամ արաբերեն կոդերի տողեր մտցնելու համար: Բայց եթե դուք միավորում եք տողերը տարբեր տեքստային ուղղություններով մեկ տողում, օգտագործելով նշված նիշերը, աջից ձախ ցուցադրվող տեքստի հատվածները կարող են համընկնել ձախից աջ ցուցադրվող գոյություն ունեցող սովորական տեքստի հետ:
Օգտագործելով այս մեթոդը, դուք կարող եք կոդի մեջ ավելացնել վնասակար կառուցվածք, բայց այնուհետև այս կառուցվածքով տեքստը դարձնել անտեսանելի, երբ դիտել եք կոդը՝ ավելացնելով հետևյալ մեկնաբանությունում կամ աջից ձախ ցույց տված բառացի նիշերի ներսում, ինչը կհանգեցնի ամբողջությամբ. վնասակար ներդիրի վրա տեղադրվում են տարբեր նիշեր: Նման ծածկագիրը իմաստային առումով ճիշտ կմնա, բայց կմեկնաբանվի և կցուցադրվի այլ կերպ:
Կոդի վերանայման ընթացքում մշակողը կբախվի նիշերի տեսողական կարգին և կտեսնի ոչ կասկածելի մեկնաբանություն ժամանակակից տեքստային խմբագրիչում, վեբ ինտերֆեյսում կամ 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»): Նմանատիպ նիշերը կարող են օգտագործվել որոշ լեզուներում գործառույթների և փոփոխականների անուններով՝ ծրագրավորողներին մոլորեցնելու համար: Օրինակ, կարող են սահմանվել անտարբեր անուններով երկու ֆունկցիա, որոնք կատարում են տարբեր գործողություններ: Առանց մանրամասն վերլուծության, անմիջապես պարզ չէ, թե այս երկու գործառույթներից որն է կոչվում կոնկրետ վայրում:
Որպես անվտանգության միջոց, խորհուրդ է տրվում, որ կոմպիլյատորները, թարգմանիչները և հավաքման գործիքները, որոնք ապահովում են 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): Նման նիշերը պետք է նաև բացահայտորեն արգելված լինեն ծրագրավորման լեզվի բնութագրերում և պետք է հարգվեն կոդերի խմբագրիչներում և պահեստի միջերեսներում:
Հավելված 1. Խոցելիության պատյանները պատրաստվել են GCC, LLVM/Clang, Rust, Go, Python և binutil-ների համար: GitHub-ը, Bitbucket-ը և Jira-ն նույնպես շտկեցին խնդիրը: GitLab-ի ուղղումը ընթացքի մեջ է: Խնդրահարույց կոդը բացահայտելու համար առաջարկվում է օգտագործել հրամանը՝ grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069\uXNUMX/uXNUMX/uXNUMX\uXNUMX/' աղբյուր
Հավելված 2. Ռաս Քոքսը, Plan 9 OS-ի և Go ծրագրավորման լեզվի մշակողներից մեկը, քննադատեց չափազանց մեծ ուշադրությունը նկարագրված հարձակման մեթոդի նկատմամբ, որը վաղուց հայտնի էր (Go, Rust, C++, Ruby) և լուրջ չէր ընդունվում: . Ըստ Քոքսի, խնդիրը հիմնականում վերաբերում է կոդերի խմբագրիչներում և վեբ ինտերֆեյսներում տեղեկատվության ճիշտ ցուցադրմանը, որը կարելի է լուծել՝ օգտագործելով ճիշտ գործիքներն ու կոդերի անալիզատորները վերանայման ժամանակ։ Հետևաբար, սպեկուլյատիվ հարձակումների վրա ուշադրություն հրավիրելու փոխարեն, ավելի նպատակահարմար կլինի կենտրոնանալ կոդի և կախվածության վերանայման գործընթացների բարելավման վրա:
Ռաս Քոքսը նաև կարծում է, որ կոմպիլյատորները ճիշտ տեղը չեն խնդիրը շտկելու համար, քանի որ, արգելելով վտանգավոր սիմվոլները կոմպիլյատորների մակարդակով, մնում է գործիքների հսկայական շերտ, որոնցում այդ նշանների օգտագործումը մնում է ընդունելի, օրինակ՝ կառուցման համակարգեր, հավաքիչներ, փաթեթների կառավարիչներ և տարբեր կոնֆիգուրացիայի վերլուծիչներ և տվյալներ: Որպես օրինակ՝ տրված է Rust նախագիծը, որն արգելում էր LTR/RTL կոդի մշակումը կոմպիլյատորում, բայց չի ավելացնում ֆիքս Cargo փաթեթի կառավարիչին, որը թույլ է տալիս նմանատիպ հարձակում Cargo.toml ֆայլի միջոցով։ Նմանապես, BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml և customers.txt ֆայլերը կարող են դառնալ գրոհների աղբյուր:
Source: opennet.ru