વિકાસકર્તા માટે અદ્રશ્ય એવા કોડ ફેરફારોને ઇન્જેક્ટ કરવા માટે ટ્રોજન સોર્સ એટેક

યુનિવર્સિટી ઓફ કેમ્બ્રિજના સંશોધકોએ પીઅર-સમીક્ષા કરેલ સોર્સ કોડમાં દૂષિત કોડને શાંતિપૂર્વક દાખલ કરવાની તકનીક પ્રકાશિત કરી છે. તૈયાર હુમલાની પદ્ધતિ (CVE-2021-42574) ટ્રોજન સ્ત્રોત નામ હેઠળ રજૂ કરવામાં આવી છે અને તે લખાણની રચના પર આધારિત છે જે કમ્પાઇલર/દુભાષિયા અને કોડ જોનાર વ્યક્તિ માટે અલગ દેખાય છે. પદ્ધતિ લાગુ કરવાના ઉદાહરણો C, C++ (gcc અને clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go અને Python માટે પૂરા પાડવામાં આવેલ વિવિધ કમ્પાઇલર્સ અને દુભાષિયાઓ માટે દર્શાવવામાં આવ્યા છે.

પદ્ધતિ કોડ ટિપ્પણીઓમાં વિશિષ્ટ યુનિકોડ અક્ષરોના ઉપયોગ પર આધારિત છે જે દ્વિપક્ષીય ટેક્સ્ટ પ્રદર્શિત થાય તે ક્રમમાં ફેરફાર કરે છે. આવા નિયંત્રણ અક્ષરોની મદદથી, ટેક્સ્ટના કેટલાક ભાગોને ડાબેથી જમણે અને અન્યને જમણેથી ડાબે પ્રદર્શિત કરી શકાય છે. રોજિંદા વ્યવહારમાં, આવા નિયંત્રણ અક્ષરોનો ઉપયોગ કરી શકાય છે, ઉદાહરણ તરીકે, ફાઇલમાં હીબ્રુ અથવા અરબીમાં રેખાઓ દાખલ કરવા માટે. પરંતુ જો તમે નિર્દિષ્ટ અક્ષરોનો ઉપયોગ કરીને, એક લીટીમાં વિવિધ ટેક્સ્ટ દિશાઓ સાથે રેખાઓને જોડો છો, તો જમણેથી ડાબે પ્રદર્શિત ટેક્સ્ટના ફકરાઓ ડાબેથી જમણે પ્રદર્શિત વર્તમાન સાદા ટેક્સ્ટને ઓવરલેપ કરી શકે છે.

આ પદ્ધતિનો ઉપયોગ કરીને, તમે કોડમાં દૂષિત રચના ઉમેરી શકો છો, પરંતુ પછી કોડ જોતી વખતે આ રચના સાથેના ટેક્સ્ટને અદ્રશ્ય બનાવી શકો છો, આગલી ટિપ્પણીમાં અથવા શાબ્દિકની અંદર જમણેથી ડાબે પ્રદર્શિત અક્ષરો ઉમેરીને, જે સંપૂર્ણ રીતે દોરી જશે. દૂષિત ઇન્સર્ટ પર વિવિધ પાત્રો સુપરઇમ્પોઝ કરવામાં આવે છે. આવો કોડ સિમેન્ટીકલી સાચો રહેશે, પરંતુ તેનું અર્થઘટન અને અલગ રીતે દર્શાવવામાં આવશે.

કોડ રિવ્યુ પ્રક્રિયા દરમિયાન, ડેવલપર વિઝ્યુઅલ કેરેક્ટર ઓર્ડરનો સામનો કરશે અને આધુનિક ટેક્સ્ટ એડિટરમાં, વેબ ઈન્ટરફેસ અથવા IDEમાં શંકાસ્પદ ટિપ્પણી જોશે, પરંતુ કમ્પાઈલર અને દુભાષિયા લોજિકલ કેરેક્ટર ઓર્ડરનો ઉપયોગ કરશે અને અવગણના કરીને દૂષિત નિવેશની પ્રક્રિયા કરશે. ટિપ્પણીઓમાં દ્વિદિશ ટેક્સ્ટ. સમસ્યા વિવિધ લોકપ્રિય કોડ સંપાદકો (VS કોડ, Emacs, Atom), તેમજ રીપોઝીટરીઝ (GitHub, Gitlab, BitBucket અને તમામ એટલાસિયન ઉત્પાદનો) માં કોડ જોવા માટેના ઇન્ટરફેસને અસર કરે છે.

દૂષિત ક્રિયાઓને અમલમાં મૂકવા માટે પદ્ધતિનો ઉપયોગ કરવાની ઘણી રીતો છે: છુપાયેલા "રીટર્ન" અભિવ્યક્તિને ઉમેરીને, કાર્ય અમલીકરણને સમય પહેલાં પૂર્ણ કરવા તરફ દોરી જાય છે; સામાન્ય રીતે માન્ય રચનાઓ તરીકે જોવામાં આવતા અભિવ્યક્તિઓ પર ટિપ્પણી કરવી (ઉદાહરણ તરીકે, મહત્વપૂર્ણ તપાસને અક્ષમ કરવા માટે); અન્ય સ્ટ્રિંગ મૂલ્યોની સોંપણી, જે સ્ટ્રિંગ માન્યતા નિષ્ફળતા તરફ દોરી જાય છે.

ઉદાહરણ તરીકે, હુમલાખોર ફેરફાર સૂચવી શકે છે જેમાં લીટીનો સમાવેશ થાય છે: if access_level != "user{U+202E} {U+2066}// તપાસો કે એડમિન{U+2069} {U+2066}" {

જે રીવ્યુ ઈન્ટરફેસમાં પ્રદર્શિત થશે as if 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/' સ્ત્રોત

પરિશિષ્ટ 2: Russ Cox, પ્લાન 9 OS અને Go પ્રોગ્રામિંગ લેંગ્વેજના વિકાસકર્તાઓમાંના એક, વર્ણવેલ હુમલો પદ્ધતિ પર વધુ પડતા ધ્યાનની ટીકા કરી, જે લાંબા સમયથી જાણીતી છે (Go, Rust, C++, Ruby) અને ન હતી. ગંભીરતાથી લેવામાં આવે છે. કોક્સના જણાવ્યા મુજબ, સમસ્યા મુખ્યત્વે કોડ એડિટર્સ અને વેબ ઇન્ટરફેસમાં માહિતીના યોગ્ય પ્રદર્શનને લગતી છે, અને સમીક્ષા દરમિયાન યોગ્ય સાધનો અને કોડ વિશ્લેષકોનો ઉપયોગ કરીને ઉકેલી શકાય છે. તેથી, સટ્ટાકીય હુમલાઓ તરફ ધ્યાન દોરવાને બદલે, કોડ સમીક્ષા પ્રક્રિયાઓ અને નિર્ભરતાને સુધારવા પર ધ્યાન કેન્દ્રિત કરવું વધુ યોગ્ય રહેશે.

રાસ કોક્સ એવું પણ માને છે કે કમ્પાઈલર્સ એ સમસ્યાને ઠીક કરવા માટેનું સ્થાન નથી, કારણ કે કમ્પાઈલર સ્તરે ખતરનાક પ્રતીકોને અક્ષમ કરવાથી ટૂલ્સનો વિશાળ સ્તર રહે છે જેમાં આ પ્રતીકોનો ઉપયોગ સ્વીકાર્ય રહે છે, જેમ કે બિલ્ડ સિસ્ટમ્સ, એસેમ્બલર્સ, પેકેજ મેનેજર્સ અને વિવિધ રૂપરેખાંકન પાર્સર્સ અને ડેટા. ઉદાહરણ તરીકે, રસ્ટ પ્રોજેક્ટ આપવામાં આવ્યો છે, જેણે કમ્પાઇલરમાં LTR/RTL કોડની પ્રક્રિયા પર પ્રતિબંધ મૂક્યો હતો, પરંતુ કાર્ગો પેકેજ મેનેજરમાં ફિક્સ ઉમેર્યું નથી, જે Cargo.toml ફાઇલ દ્વારા સમાન હુમલાને મંજૂરી આપે છે. તેવી જ રીતે, BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml અને requirements.txt જેવી ફાઇલો હુમલાના સ્ત્રોત બની શકે છે.

સોર્સ: opennet.ru