لقد اكتشفنا سابقًا ثغرة خطيرة في Aptos Moveevm، وبعد دراسة متعمقة، اكتشفنا ثغرة جديدة تتعلق بتجاوز الأعداد الصحيحة. كانت عملية تفعيل هذه الثغرة أكثر إثارة للاهتمام، وسنقوم أدناه بتحليل هذه الثغرة بعمق، بينما نقدم بعض المعلومات الخلفية عن لغة Move. نعتقد أنه من خلال الشرح في هذا المقال، ستحصل على فهم أعمق للغة Move.
من المعروف أن لغة Move تتحقق من وحدات التعليمات البرمجية قبل تنفيذ الشيفرة الثنائية. تتكون عملية التحقق من 4 خطوات، وتظهر هذه الثغرة في خطوة الأمان المرجعي.
يحدد نموذج reference_safety دالة النقل للتحقق من سلامة الإشارات للموضوعات في عملية التحقق. تشمل الفحوصات التحقق من عدم وجود إشارات معلقة، وما إذا كان الوصول إلى الإشارات المتغيرة آمنًا، وما إذا كان الوصول إلى إشارات التخزين العالمية آمنًا، وغيرها.
ستقوم دالة الإدخال للتحقق من الأمان باستدعاء analyze_function. في analyze_function، ستقوم الدالة بالتحقق من كل كتلة أساسية. الكتلة الأساسية تشير إلى تسلسل التعليمات البرمجية الذي لا يحتوي على تعليمات فرعية باستثناء المدخلات والمخرجات.
تحدد لغة Move الكتل الأساسية من خلال استعراض التعليمات البرمجية البايتية، والبحث عن جميع التعليمات الفرعية وتسلسل التعليمات الحلقية. قد يحتوي مثال نموذجي لكتلة كود Move IR على 3 كتل أساسية، يتم تحديدها بواسطة تعليمات BrTrue وBranch وRet.
الأمان في الاقتباسات في Move
استنادًا إلى فكرة لغة Rust، يدعم Move نوعين من المراجع: المراجع غير القابلة للتغيير (&) والمراجع القابلة للتغيير (&mut). تُستخدم المراجع غير القابلة للتغيير لقراءة البيانات من البنية، بينما تُستخدم المراجع القابلة للتغيير لتعديل البيانات. الاستخدام المعقول لأنواع المراجع يساعد في الحفاظ على الأمان والتعرف على وحدات القراءة.
تقوم وحدة أمان الاقتباس في Move بمسح تعليمات بايت الكتل الأساسية في الدوال ، والتحقق من صحة جميع عمليات الاقتباس. تتضمن عملية التحقق بشكل أساسي هيكل AbstractState ، الذي يحتوي على رسم الاقتباس والمحليين ، لضمان أمان الاقتباسات في الدالة.
ستقوم عملية التحقق بمقارنة الحالة قبل وبعد تنفيذ الكتلة الأساسية، ودمج النتائج لتحديث حالة الكتلة، وفي الوقت نفسه نشر الشروط اللاحقة لهذه الكتلة إلى الكتل اللاحقة. هذه العملية مشابهة لفكرة Sea of Nodes في V8 turbofan.
ستقوم الحلقة الرئيسية بتنفيذ كتلة من التعليمات البرمجية، ثم تحاول دمج الحالة السابقة والحالة اللاحقة. إذا تغيرت الحالة وكان هناك حافة خلفية تشير إلى نفسها (، فهذا يعني وجود حلقة )، ستعود إلى بداية الحلقة وتواصل تنفيذ هذه الكتلة الأساسية، حتى تصبح الحالة اللاحقة مساوية للحالة السابقة أو تتوقف بسبب خطأ.
تحليل الثغرات
ظهرت الثغرة في عملية判断 ما إذا كانت نتيجة الانضمام قد تغيرت. تُستخدم دالة join_ لتحديث المتغيرات المحلية ورسم علاقة الاقتراض. عندما يتجاوز طول معلمات الدالة وطول المتغيرات المحلية 256، يحدث تجاوز أثناء المرور عبر المتغيرات المحلية لأن المتغيرات المحلية من نوع u8.
على الرغم من أن Move لديه عملية التحقق من عدد locals، إلا أن وحدة check bounds تتحقق فقط من locals، دون تضمين طول المعاملات. يبدو أن المطورين أدركوا الحاجة إلى التحقق من المجموع الكلي للمعاملات والقيم المحلية، لكن الشيفرة في الواقع تتحقق فقط من عدد المتغيرات المحلية.
من تجاوز سعة النوع الصحيح إلى هجوم DoS
ستقوم الحلقة الرئيسية بمسح كتل الشيفرة واستدعاء دالة execute_block، ثم دمج الحالة قبل وبعد التنفيذ. عندما تحتوي الشيفرة على حلقة، ستنتقل إلى بداية كتلة الشيفرة وتعيد التنفيذ مرة أخرى.
إذا قمنا بإنشاء كتلة كود حلقية واستخدمنا تجاوز السعة لتغيير حالة الكتلة، مما يجعل خريطة locals الجديدة تختلف عن السابقة، فعند تنفيذ execute_block مرة أخرى، سيؤدي تحليل سلسلة التعليمات في الكتلة الأساسية إلى الوصول إلى خريطة locals الجديدة. في هذه الحالة، إذا كان المؤشر الذي تحتاج التعليمات للوصول إليه غير موجود في الخريطة الجديدة، فسوف يؤدي ذلك إلى DoS.
في وحدة reference safety، يمكن أن تحقق تعليمات MoveLoc/CopyLoc/FreeRef هذا الهدف. على سبيل المثال، فإن دالة copy_loc ستحاول الحصول على القيمة المحلية من خلال LocalIndex، وإذا لم يكن LocalIndex موجودًا، فسيتسبب ذلك في panic، مما يؤدي إلى انهيار العقدة بأكملها.
عرض PoC
يمكننا إنشاء كتلة أساسية تحتوي على تعليمات فرعية غير مشروطة، مما يجعلها تستدعي دالة execute_block و join عدة مرات. من خلال تعيين المعلمات المناسبة وعدد المتغيرات المحلية، يمكن تقليل طول خريطة locals الجديدة إلى 8 بعد التنفيذ الأول.
عند التنفيذ الثاني، فإن محاولة الوصول إلى offset غير موجود ستؤدي إلى panic، مما يؤدي إلى تفعيل DoS.
ملخص
توضح هذه الثغرة أنه حتى لغة Move التي تم التحقق منها بدقة يمكن أن تحتوي على مخاطر أمان. يمكن أن تتجاوز ثغرات الفائض التحقق من الحدود، مما يبرز أهمية تدقيق الشفرة.
بصفتنا رواد البحث في أمان لغة Move، نقترح على مصممي اللغة إضافة المزيد من كود التحقق في وقت تشغيل Move، لمنع حدوث حالات غير متوقعة. حاليًا، يتم إجراء فحوصات الأمان بشكل رئيسي في مرحلة التحقق، لكن مرحلة التشغيل تفتقر إلى تعزيز الأمان الكافي، مما قد يؤدي إلى مشاكل أكثر خطورة.
لقد اكتشفنا ثغرة أخرى في لغة Move، وسنشاركها معكم لاحقًا.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تحليل ثغرة تجاوز السعة الجديدة في لغة Move: من أمان الاستدعاء إلى هجوم DoS
تحليل عميق لثغرة خطيرة أخرى في لغة Move
لقد اكتشفنا سابقًا ثغرة خطيرة في Aptos Moveevm، وبعد دراسة متعمقة، اكتشفنا ثغرة جديدة تتعلق بتجاوز الأعداد الصحيحة. كانت عملية تفعيل هذه الثغرة أكثر إثارة للاهتمام، وسنقوم أدناه بتحليل هذه الثغرة بعمق، بينما نقدم بعض المعلومات الخلفية عن لغة Move. نعتقد أنه من خلال الشرح في هذا المقال، ستحصل على فهم أعمق للغة Move.
من المعروف أن لغة Move تتحقق من وحدات التعليمات البرمجية قبل تنفيذ الشيفرة الثنائية. تتكون عملية التحقق من 4 خطوات، وتظهر هذه الثغرة في خطوة الأمان المرجعي.
يحدد نموذج reference_safety دالة النقل للتحقق من سلامة الإشارات للموضوعات في عملية التحقق. تشمل الفحوصات التحقق من عدم وجود إشارات معلقة، وما إذا كان الوصول إلى الإشارات المتغيرة آمنًا، وما إذا كان الوصول إلى إشارات التخزين العالمية آمنًا، وغيرها.
ستقوم دالة الإدخال للتحقق من الأمان باستدعاء analyze_function. في analyze_function، ستقوم الدالة بالتحقق من كل كتلة أساسية. الكتلة الأساسية تشير إلى تسلسل التعليمات البرمجية الذي لا يحتوي على تعليمات فرعية باستثناء المدخلات والمخرجات.
تحدد لغة Move الكتل الأساسية من خلال استعراض التعليمات البرمجية البايتية، والبحث عن جميع التعليمات الفرعية وتسلسل التعليمات الحلقية. قد يحتوي مثال نموذجي لكتلة كود Move IR على 3 كتل أساسية، يتم تحديدها بواسطة تعليمات BrTrue وBranch وRet.
الأمان في الاقتباسات في Move
استنادًا إلى فكرة لغة Rust، يدعم Move نوعين من المراجع: المراجع غير القابلة للتغيير (&) والمراجع القابلة للتغيير (&mut). تُستخدم المراجع غير القابلة للتغيير لقراءة البيانات من البنية، بينما تُستخدم المراجع القابلة للتغيير لتعديل البيانات. الاستخدام المعقول لأنواع المراجع يساعد في الحفاظ على الأمان والتعرف على وحدات القراءة.
تقوم وحدة أمان الاقتباس في Move بمسح تعليمات بايت الكتل الأساسية في الدوال ، والتحقق من صحة جميع عمليات الاقتباس. تتضمن عملية التحقق بشكل أساسي هيكل AbstractState ، الذي يحتوي على رسم الاقتباس والمحليين ، لضمان أمان الاقتباسات في الدالة.
ستقوم عملية التحقق بمقارنة الحالة قبل وبعد تنفيذ الكتلة الأساسية، ودمج النتائج لتحديث حالة الكتلة، وفي الوقت نفسه نشر الشروط اللاحقة لهذه الكتلة إلى الكتل اللاحقة. هذه العملية مشابهة لفكرة Sea of Nodes في V8 turbofan.
ستقوم الحلقة الرئيسية بتنفيذ كتلة من التعليمات البرمجية، ثم تحاول دمج الحالة السابقة والحالة اللاحقة. إذا تغيرت الحالة وكان هناك حافة خلفية تشير إلى نفسها (، فهذا يعني وجود حلقة )، ستعود إلى بداية الحلقة وتواصل تنفيذ هذه الكتلة الأساسية، حتى تصبح الحالة اللاحقة مساوية للحالة السابقة أو تتوقف بسبب خطأ.
تحليل الثغرات
ظهرت الثغرة في عملية判断 ما إذا كانت نتيجة الانضمام قد تغيرت. تُستخدم دالة join_ لتحديث المتغيرات المحلية ورسم علاقة الاقتراض. عندما يتجاوز طول معلمات الدالة وطول المتغيرات المحلية 256، يحدث تجاوز أثناء المرور عبر المتغيرات المحلية لأن المتغيرات المحلية من نوع u8.
على الرغم من أن Move لديه عملية التحقق من عدد locals، إلا أن وحدة check bounds تتحقق فقط من locals، دون تضمين طول المعاملات. يبدو أن المطورين أدركوا الحاجة إلى التحقق من المجموع الكلي للمعاملات والقيم المحلية، لكن الشيفرة في الواقع تتحقق فقط من عدد المتغيرات المحلية.
من تجاوز سعة النوع الصحيح إلى هجوم DoS
ستقوم الحلقة الرئيسية بمسح كتل الشيفرة واستدعاء دالة execute_block، ثم دمج الحالة قبل وبعد التنفيذ. عندما تحتوي الشيفرة على حلقة، ستنتقل إلى بداية كتلة الشيفرة وتعيد التنفيذ مرة أخرى.
إذا قمنا بإنشاء كتلة كود حلقية واستخدمنا تجاوز السعة لتغيير حالة الكتلة، مما يجعل خريطة locals الجديدة تختلف عن السابقة، فعند تنفيذ execute_block مرة أخرى، سيؤدي تحليل سلسلة التعليمات في الكتلة الأساسية إلى الوصول إلى خريطة locals الجديدة. في هذه الحالة، إذا كان المؤشر الذي تحتاج التعليمات للوصول إليه غير موجود في الخريطة الجديدة، فسوف يؤدي ذلك إلى DoS.
في وحدة reference safety، يمكن أن تحقق تعليمات MoveLoc/CopyLoc/FreeRef هذا الهدف. على سبيل المثال، فإن دالة copy_loc ستحاول الحصول على القيمة المحلية من خلال LocalIndex، وإذا لم يكن LocalIndex موجودًا، فسيتسبب ذلك في panic، مما يؤدي إلى انهيار العقدة بأكملها.
عرض PoC
يمكننا إنشاء كتلة أساسية تحتوي على تعليمات فرعية غير مشروطة، مما يجعلها تستدعي دالة execute_block و join عدة مرات. من خلال تعيين المعلمات المناسبة وعدد المتغيرات المحلية، يمكن تقليل طول خريطة locals الجديدة إلى 8 بعد التنفيذ الأول.
عند التنفيذ الثاني، فإن محاولة الوصول إلى offset غير موجود ستؤدي إلى panic، مما يؤدي إلى تفعيل DoS.
ملخص
توضح هذه الثغرة أنه حتى لغة Move التي تم التحقق منها بدقة يمكن أن تحتوي على مخاطر أمان. يمكن أن تتجاوز ثغرات الفائض التحقق من الحدود، مما يبرز أهمية تدقيق الشفرة.
بصفتنا رواد البحث في أمان لغة Move، نقترح على مصممي اللغة إضافة المزيد من كود التحقق في وقت تشغيل Move، لمنع حدوث حالات غير متوقعة. حاليًا، يتم إجراء فحوصات الأمان بشكل رئيسي في مرحلة التحقق، لكن مرحلة التشغيل تفتقر إلى تعزيز الأمان الكافي، مما قد يؤدي إلى مشاكل أكثر خطورة.
لقد اكتشفنا ثغرة أخرى في لغة Move، وسنشاركها معكم لاحقًا.