إذا تم استغلالها ، يمكن أن تسمح هذه العيوب للمهاجمين بالوصول غير المصرح به إلى المعلومات الحساسة أو التسبب بشكل عام في حدوث مشكلات
تم تحديد ثغرة أمنية (مدرج بالفعل ضمن CVE-2022-37454) en تنفيذ وظيفة تجزئة التشفير SHA-3 (Keccak) ، المقدم في حزمة XKCP (حزمة كود Keccak الموسعة).
الضعف المحدد يمكن أن يسبب تجاوز سعة المخزن المؤقت أثناء معالجة البيانات المشكلة. ترجع المشكلة إلى خطأ في رمز تنفيذ معين لـ SHA-3 ، وليس ثغرة أمنية في الخوارزمية نفسها.
باكيت XKCP يوصف بأنه التنفيذ الرسمي لـ SHA-3 ، الذي تم تطويره بمساعدة فريق تطوير Keccak ، و تستخدم كأساس للوظائف للعمل مع SHA-3 بلغات البرمجة المختلفة (على سبيل المثال ، يتم استخدام كود XKCP في وحدة Python hashlib ، وحزمة Ruby Digest-sha3 ، و PHP hash_ *).
وبحسب الباحث الذي حدد المشكلة ، قد تستخدم الثغرة الأمنية لانتهاك خصائص التشفير من دالة التجزئة والعثور على الصور الأولية الأولى والثانية ، وكذلك تحديد الاصطدامات.
سبب خطأ التجزئة هو أن البرامج النصية ستحاول كتابة المزيد من البيانات إلى المخزن المؤقت أكثر مما يمكن أن يحتويه. تُعرف مثل هذه الثغرة الأمنية باسم تجاوز سعة المخزن المؤقت ، والذي يصفه OWASP بأنه "ربما يكون الشكل الأكثر شهرة من الثغرات الأمنية للبرامج."
سيتسبب متغير صغير من الكود في حدوث حلقة لا نهائية: فقط استبدل 4294967295 بـ 4294967296. لاحظ التشابه مع CVE-2019-8741 ، وهي ثغرة أخرى اكتشفتها أثرت على البرامج الثابتة لأكثر من 1.400 مليار جهاز Apple ، والتي تسببت أيضًا في حلقة لا نهائية.
أيضا، تم الإعلان عن إنشاء نموذج أولي لاستغلال ، quيسمح e بتحقيق تنفيذ الكود عند حساب التجزئة من ملف مصمم خصيصًا. يمكن أيضًا استخدام الثغرة الأمنية لمهاجمة خوارزميات التحقق من التوقيع الرقمي باستخدام SHA-3 (على سبيل المثال ، Ed448). من المتوقع نشر تفاصيل طرق الهجوم في وقت لاحق ، بعد إزالة الثغرة الأمنية بشكل عام.
لا يُفترض أن يحدث هذا النوع من السلوك في لغات "آمنة" مثل Python و PHP ، نظرًا لأنها تتحقق من أن جميع عمليات القراءة والكتابة تقع ضمن حدود المخزن المؤقت. ومع ذلك ، فإن المشكلة تكمن في أن الثغرة موجودة في لغة C الأساسية "غير الآمنة" ...
بعد من غير الواضح كيف تؤثر الثغرة الأمنية على التطبيقات الحالية في الممارسة العملية، نظرًا لظهور المشكلة في الكود ، يجب استخدام حساب التجزئة الدوري على الكتل ، ويجب أن يكون حجم إحدى الكتل المعالجة حوالي 4 غيغابايت (على الأقل 2 ^ 32 - 200 بايت).
عند معالجة بيانات الإدخال دفعة واحدة (بدون الحساب المتسلسل للتجزئة حسب الأجزاء) ، لا تظهر المشكلة. كطريقة حماية أبسط ، يُقترح تحديد الحجم الأقصى للبيانات المتضمنة في تكرار واحد لحساب التجزئة.
تم نشر الكود الضعيف في يناير 2011 ، لذلك استغرق الأمر أكثر من عقد للعثور على هذه الثغرة الأمنية. يبدو أنه من الصعب العثور على الثغرات الأمنية في تطبيقات التشفير ، على الرغم من أنها تلعب دورًا مهمًا في الأمن العام للنظام. (ربما لا يبحث الأشخاص حتى عن مثل هذه الثغرات الأمنية ، حيث لا تكون هذه الثغرة الأمنية في XKCP ولا ثغرة Apple المذكورة أعلاه مؤهلين لأي من برامج مكافآت الأخطاء!)
عالي التأثر يرجع إلى خطأ في كتلة معالجة بيانات الإدخال. نظرًا للمقارنة غير الصحيحة للقيم مع النوع "int" ، يتم تحديد حجم غير صحيح للبيانات المعلقة ، مما يؤدي إلى كتابة قائمة الانتظار خارج المخزن المؤقت المخصص.
ويذكر على وجه الخصوص أنه عند المقارنة ، فإن عبارة «partBlock + مثيل-> مؤشر بايت«، والتي أدت ، مع القيم الكبيرة للأجزاء المكونة ، إلى تجاوز عدد صحيح. أيضًا ، كان هناك نوع غير صحيح من النوع "(int) (dataByteLen - i)" غير صحيح في الكود ، مما تسبب في تجاوز سعة الأنظمة من النوع size_t 64 بت.
أخيرا إذا كنت مهتمًا بمعرفة المزيد عنها، يمكنك التحقق من التفاصيل في الرابط التالي.