ഡവലപ്പർക്ക് അദൃശ്യമായ കോഡിൽ മാറ്റങ്ങൾ അവതരിപ്പിക്കാൻ ട്രോജൻ ഉറവിട ആക്രമണം

കേംബ്രിഡ്ജ് സർവ്വകലാശാലയിലെ ഗവേഷകർ പിയർ റിവ്യൂ ചെയ്ത സോഴ്സ് കോഡിലേക്ക് നിശ്ശബ്ദമായി ക്ഷുദ്ര കോഡ് ചേർക്കുന്നതിനുള്ള ഒരു സാങ്കേതികത പ്രസിദ്ധീകരിച്ചു. തയ്യാറാക്കിയ ആക്രമണ രീതി (CVE-2021-42574) ട്രോജൻ ഉറവിടം എന്ന പേരിൽ അവതരിപ്പിച്ചിരിക്കുന്നു, ഇത് കംപൈലർ/വ്യാഖ്യാതാവിനും കോഡ് കാണുന്ന വ്യക്തിക്കും വ്യത്യസ്തമായി തോന്നുന്ന വാചകത്തിന്റെ രൂപീകരണത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്. C, C++ (gcc, clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go, Python എന്നിവയ്‌ക്കായി വിതരണം ചെയ്യുന്ന വിവിധ കംപൈലറുകൾക്കും വ്യാഖ്യാതാക്കൾക്കുമായി ഈ രീതിയുടെ ഉദാഹരണങ്ങൾ പ്രദർശിപ്പിച്ചിരിക്കുന്നു.

ദ്വിദിശ വാചകത്തിന്റെ പ്രദർശന ക്രമം മാറ്റുന്ന കോഡ് കമന്റുകളിൽ പ്രത്യേക യൂണികോഡ് പ്രതീകങ്ങൾ ഉപയോഗിക്കുന്നതിനെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് ഈ രീതി. അത്തരം നിയന്ത്രണ പ്രതീകങ്ങളുടെ സഹായത്തോടെ, വാചകത്തിന്റെ ചില ഭാഗങ്ങൾ ഇടത്തുനിന്ന് വലത്തോട്ട് പ്രദർശിപ്പിക്കാൻ കഴിയും, മറ്റുള്ളവ - വലത്തുനിന്ന് ഇടത്തേക്ക്. ദൈനംദിന പ്രയോഗത്തിൽ, അത്തരം നിയന്ത്രണ പ്രതീകങ്ങൾ ഉപയോഗിക്കാം, ഉദാഹരണത്തിന്, ഹീബ്രുവിലോ അറബിയിലോ ഉള്ള കോഡ് ലൈനുകൾ ഒരു ഫയലിലേക്ക് തിരുകാൻ. എന്നാൽ നിങ്ങൾ ഒരു വരിയിൽ വ്യത്യസ്‌ത ടെക്‌സ്‌റ്റ് ദിശകളുള്ള ലൈനുകൾ സംയോജിപ്പിച്ചാൽ, നിർദ്ദിഷ്ട പ്രതീകങ്ങൾ ഉപയോഗിച്ച്, വലത്തുനിന്ന് ഇടത്തോട്ട് പ്രദർശിപ്പിക്കുന്ന വാചകത്തിന്റെ ഭാഗങ്ങൾ ഇടത്തുനിന്ന് വലത്തോട്ട് പ്രദർശിപ്പിച്ചിരിക്കുന്ന നിലവിലുള്ള സാധാരണ ടെക്‌സ്‌റ്റിനെ ഓവർലാപ്പ് ചെയ്യും.

ഈ രീതി ഉപയോഗിച്ച്, നിങ്ങൾക്ക് കോഡിലേക്ക് ക്ഷുദ്രകരമായ ഒരു നിർമ്മാണം ചേർക്കാൻ കഴിയും, എന്നാൽ കോഡ് കാണുമ്പോൾ ഈ നിർമ്മിതിയുള്ള വാചകം അദൃശ്യമാക്കുക, ഇനിപ്പറയുന്ന കമന്റിലോ വലത്തുനിന്ന് ഇടത്തോട്ട് കാണിക്കുന്ന അക്ഷരങ്ങൾക്കുള്ളിലോ ചേർക്കുക, ഇത് പൂർണ്ണമായും നയിക്കും. ക്ഷുദ്രകരമായ ഉൾപ്പെടുത്തലിൽ വ്യത്യസ്ത പ്രതീകങ്ങൾ സൂപ്പർഇമ്പോസ് ചെയ്യുന്നു. അത്തരം കോഡ് അർത്ഥപരമായി ശരിയായി തുടരും, പക്ഷേ വ്യത്യസ്തമായി വ്യാഖ്യാനിക്കുകയും പ്രദർശിപ്പിക്കുകയും ചെയ്യും.

കോഡ് അവലോകനം ചെയ്യുമ്പോൾ, ഒരു ഡവലപ്പർ പ്രതീകങ്ങളുടെ ദൃശ്യ ക്രമത്തെ അഭിമുഖീകരിക്കുകയും ആധുനിക ടെക്സ്റ്റ് എഡിറ്ററിലോ വെബ് ഇന്റർഫേസിലോ IDEയിലോ സംശയാസ്പദമല്ലാത്ത ഒരു അഭിപ്രായം കാണുകയും ചെയ്യും, എന്നാൽ കംപൈലറും ഇന്റർപ്രെറ്ററും പ്രതീകങ്ങളുടെ ലോജിക്കൽ ക്രമം ഉപയോഗിക്കും. കമന്റുകളിലെ ദ്വിദിശ വാചകം ശ്രദ്ധിക്കാതെ, ക്ഷുദ്രകരമായ ഉൾപ്പെടുത്തൽ അതേപടി പ്രോസസ്സ് ചെയ്യുക. പ്രശ്‌നം വിവിധ ജനപ്രിയ കോഡ് എഡിറ്റർമാരെയും (VS കോഡ്, ഇമാക്സ്, ആറ്റം) ശേഖരണങ്ങളിൽ (GitHub, Gitlab, BitBucket, എല്ലാ അറ്റ്‌ലേഷ്യൻ ഉൽപ്പന്നങ്ങൾ) കോഡ് കാണുന്നതിനുള്ള ഇന്റർഫേസുകളെയും ബാധിക്കുന്നു.

ക്ഷുദ്രകരമായ പ്രവർത്തനങ്ങൾ നടപ്പിലാക്കാൻ രീതി ഉപയോഗിക്കുന്നതിന് നിരവധി മാർഗങ്ങളുണ്ട്: ഒരു മറഞ്ഞിരിക്കുന്ന "റിട്ടേൺ" എക്സ്പ്രഷൻ ചേർക്കുന്നു, അത് സമയത്തിന് മുമ്പായി ഫംഗ്ഷൻ പൂർത്തീകരിക്കുന്നതിലേക്ക് നയിക്കുന്നു; സാധുവായ നിർമ്മിതികളായി സാധാരണയായി ദൃശ്യമാകുന്ന എക്സ്പ്രഷനുകൾ അഭിപ്രായമിടുന്നു (ഉദാഹരണത്തിന്, പ്രധാനപ്പെട്ട പരിശോധനകൾ പ്രവർത്തനരഹിതമാക്കുന്നതിന്); സ്ട്രിംഗ് മൂല്യനിർണ്ണയ പരാജയങ്ങളിലേക്ക് നയിക്കുന്ന മറ്റ് സ്ട്രിംഗ് മൂല്യങ്ങൾ നൽകുന്നു.

ഉദാഹരണത്തിന്, ആക്സസ്സ്_ലെവൽ != "ഉപയോക്താവ്{U+202E} {U+2066}// അഡ്‌മിൻ ആണോ എന്ന് പരിശോധിക്കുക{U+2069} {U+2066}" {XNUMX}ആക്രമി ഈ വരി ഉൾപ്പെടുന്ന ഒരു മാറ്റം നിർദ്ദേശിച്ചേക്കാം.

ആക്സസ്_ലെവൽ != “ഉപയോക്താവ്” { // അഡ്‌മിൻ ആണോ എന്ന് പരിശോധിക്കുക

കൂടാതെ, മറ്റൊരു ആക്രമണ വേരിയന്റ് നിർദ്ദേശിക്കപ്പെട്ടിട്ടുണ്ട് (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]' ഉറവിടം

അനുബന്ധം 2: പ്ലാൻ 9 ഒഎസിന്റെയും ഗോ പ്രോഗ്രാമിംഗ് ഭാഷയുടെയും ഡെവലപ്പർമാരിൽ ഒരാളായ റസ് കോക്സ് വിവരിച്ച ആക്രമണ രീതിയിലേക്കുള്ള അമിതമായ ശ്രദ്ധയെ വിമർശിച്ചു, അത് വളരെക്കാലമായി അറിയപ്പെടുന്നു (ഗോ, റസ്റ്റ്, സി ++, റൂബി) അത് ഗൗരവമായി എടുത്തിട്ടില്ല. . കോക്‌സിന്റെ അഭിപ്രായത്തിൽ, കോഡ് എഡിറ്ററുകളിലും വെബ് ഇന്റർഫേസുകളിലും വിവരങ്ങളുടെ ശരിയായ പ്രദർശനത്തെയാണ് പ്രശ്നം പ്രധാനമായും ബാധിക്കുന്നത്, അവലോകന സമയത്ത് ശരിയായ ടൂളുകളും കോഡ് അനലൈസറുകളും ഉപയോഗിച്ച് ഇത് പരിഹരിക്കാനാകും. അതിനാൽ, ഊഹക്കച്ചവട ആക്രമണങ്ങളിലേക്ക് ശ്രദ്ധ ആകർഷിക്കുന്നതിനുപകരം, കോഡ് മെച്ചപ്പെടുത്തുന്നതിലും ആശ്രിത അവലോകന പ്രക്രിയകളിലും ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നതാണ് കൂടുതൽ ഉചിതം.

കംപൈലർ തലത്തിൽ അപകടകരമായ ചിഹ്നങ്ങൾ നിരോധിക്കുന്നതിലൂടെ, ബിൽഡ് സിസ്റ്റങ്ങൾ, അസംബ്ലറുകൾ, ഈ ചിഹ്നങ്ങളുടെ ഉപയോഗം സ്വീകാര്യമായി തുടരുന്ന ഉപകരണങ്ങളുടെ ഒരു വലിയ പാളി അവശേഷിക്കുന്നതിനാൽ, പ്രശ്നം പരിഹരിക്കാൻ കംപൈലറുകൾ ശരിയായ സ്ഥലമല്ലെന്ന് റാസ് കോക്സ് വിശ്വസിക്കുന്നു. പാക്കേജ് മാനേജർമാരും വിവിധ കോൺഫിഗറേഷൻ പാർസറുകളും ഡാറ്റയും. ഒരു ഉദാഹരണമായി, റസ്റ്റ് പ്രോജക്റ്റ് നൽകിയിരിക്കുന്നു, ഇത് കംപൈലറിൽ LTR/RTL കോഡ് പ്രോസസ്സ് ചെയ്യുന്നത് നിരോധിച്ചിരിക്കുന്നു, എന്നാൽ Cargo.toml ഫയലിലൂടെ സമാനമായ ആക്രമണം അനുവദിക്കുന്ന കാർഗോ പാക്കേജ് മാനേജറിലേക്ക് ഒരു പരിഹാരം ചേർത്തില്ല. അതുപോലെ, BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml, requirements.txt തുടങ്ങിയ ഫയലുകൾ ആക്രമണങ്ങളുടെ ഉറവിടങ്ങളാകാം.

അവലംബം: opennet.ru