یونیورسٹی آف کیمبرج کے محققین نے ہم مرتبہ نظرثانی شدہ سورس کوڈ میں خاموشی سے نقصان دہ کوڈ داخل کرنے کی ایک تکنیک شائع کی ہے۔ حملے کا تیار کردہ طریقہ (CVE-2021-42574) ٹروجن سورس کے نام سے پیش کیا گیا ہے اور یہ متن کی تشکیل پر مبنی ہے جو مرتب کرنے والے/مترجم اور کوڈ کو دیکھنے والے شخص کے لیے مختلف نظر آتا ہے۔ طریقہ کار کی مثالیں 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 != "صارف{U+202E} {U+2066}// چیک کریں کہ آیا منتظم{U+2069} {U+2066}" {
جو ریویو انٹرفیس میں اس طرح دکھایا جائے گا جیسے access_level != "صارف" { // چیک کریں کہ آیا منتظم
مزید برآں، ایک اور اٹیک ویرینٹ (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) اور اسے سنجیدگی سے نہیں لیا گیا۔ . Cox کے مطابق، مسئلہ بنیادی طور پر کوڈ ایڈیٹرز اور ویب انٹرفیس میں معلومات کے درست ڈسپلے سے متعلق ہے، جسے جائزے کے دوران درست ٹولز اور کوڈ اینالائزرز کے استعمال سے حل کیا جا سکتا ہے۔ لہٰذا، قیاس آرائی پر مبنی حملوں کی طرف توجہ مبذول کرنے کے بجائے، کوڈ اور انحصار کے جائزے کے عمل کو بہتر بنانے پر توجہ مرکوز کرنا زیادہ مناسب ہوگا۔
راس کوکس کا یہ بھی ماننا ہے کہ کمپائلر مسئلے کو حل کرنے کے لیے صحیح جگہ نہیں ہیں، کیونکہ کمپائلر کی سطح پر خطرناک علامتوں پر پابندی لگانے سے، ٹولز کی ایک بہت بڑی تہہ باقی رہ جاتی ہے جس میں ان علامتوں کا استعمال قابل قبول رہتا ہے، جیسے کہ بلڈ سسٹم، اسمبلرز، پیکیج مینیجرز اور مختلف کنفیگریشن پارسرز اور ڈیٹا۔ مثال کے طور پر، Rust پروجیکٹ دیا گیا ہے، جس نے کمپائلر میں LTR/RTL کوڈ کی پروسیسنگ کو ممنوع قرار دیا، لیکن کارگو پیکج مینیجر میں کوئی فکس شامل نہیں کیا، جو Cargo.toml فائل کے ذریعے اسی طرح کے حملے کی اجازت دیتا ہے۔ اسی طرح BUILD.bazel، CMakefile، Cargo.toml، Dockerfile، GNUmakefile، Makefile، go.mod، package.json، pom.xml اور requirements.txt جیسی فائلیں حملوں کا ذریعہ بن سکتی ہیں۔
ماخذ: opennet.ru