نشر باحثون من جامعة كامبريدج تقنية لإدراج تعليمات برمجية ضارة بصمت في التعليمات البرمجية المصدر التي يراجعها النظراء. يتم تقديم طريقة الهجوم المعدة (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” { // تحقق مما إذا كان admin
بالإضافة إلى ذلك، تم اقتراح متغير آخر للهجوم (CVE-2021-42694)، مرتبط باستخدام الحروف المتجانسة، وهي أحرف متشابهة في المظهر، ولكنها تختلف في المعنى ولها رموز يونيكود مختلفة (على سبيل المثال، الحرف "ɑ" يشبه " أ"، "ɡ" - "ز"، "ɩ" - "ل"). يمكن استخدام أحرف مشابهة في بعض اللغات في أسماء الدوال والمتغيرات لتضليل المطورين. على سبيل المثال، قد يتم تعريف وظيفتين بأسماء لا يمكن تمييزها وتؤديان إجراءات مختلفة. بدون تحليل مفصل، ليس من الواضح على الفور أي من هاتين الوظيفتين يتم استدعاؤهما في مكان معين.
كإجراء أمني، يوصى بأن تقوم المترجمات والمترجمات الفورية وأدوات التجميع التي تدعم أحرف 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: تم إعداد تصحيحات الثغرات الأمنية لـGC وLLVM/Clang وRust وGo وPython وbinutils. كما قام GitHub وBitbucket وJira بإصلاح المشكلة. إصلاح GitLab قيد التقدم. لتحديد التعليمات البرمجية التي بها مشكلات، يُقترح استخدام الأمر: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/ مصدر
إضافة 2: انتقد روس كوكس، أحد مطوري نظام التشغيل Plan 9 ولغة البرمجة 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 وrequirements.txt مصادر للهجمات.
المصدر: opennet.ru