أمان جاد: GnuTLS يتبع OpenSSL ، ويصلح خطأ هجوم التوقيت

في الأسبوع الماضي ، كتبنا عن مجموعة من أخطاء إدارة الذاكرة التي تم إصلاحها في آخر تحديث أمني لمكتبة تشفير OpenSSL الشهيرة.

إلى جانب تلك الأخطاء في الذاكرة ، أبلغنا أيضًا عن خطأ مدبلج CVE-2022-4304: توقيت Oracle في فك تشفير RSA.

في هذا الخطأ ، يتم إطلاق نفس الرسالة المشفرة مرارًا وتكرارًا على الخادم ، مع تعديل المساحة المتروكة في نهاية البيانات لجعل البيانات غير صالحة ، وبالتالي إثارة نوع من السلوك غير المتوقع ...

... لن يستغرق وقتًا ثابتًا ، بافتراض أنك كنت قريبًا من الهدف على الشبكة بحيث يمكنك تخمين المدة التي سيستغرقها جزء نقل البيانات من العملية بشكل موثوق.

لم تتم معالجة جميع البيانات على قدم المساواة

إذا قمت بإطلاق طلب ، والوقت الذي تستغرقه الإجابة ، وطرح الوقت المستغرق في الإرسال والاستلام منخفض المستوى لبيانات الشبكة ، فأنت تعرف المدة التي استغرقها الخادم لإجراء العمليات الحسابية الداخلية لمعالجة الطلب .

حتى إذا لم تكن متأكدًا من مقدار الوقت المستنفد في الشبكة ، يمكنك البحث عن الاختلافات في أوقات الذهاب والإياب من خلال إطلاق الكثير من الطلبات وجمع كميات كبيرة من العينات.

إذا كانت الشبكة موثوقة بما يكفي لافتراض أن عبء الشبكة ثابت إلى حد كبير ، فقد تتمكن من استخدام الأساليب الإحصائية لاستنتاج أي نوع من تعديل البيانات يسبب أي نوع من تأخير المعالجة الإضافي.

من هذا ، يمكنك أن تستنتج شيئًا ما عن بنية ، أو حتى محتوى ، البيانات الأصلية غير المشفرة التي من المفترض أن تظل سرية داخل كل طلب متكرر.

حتى لو كان بإمكانك فقط استخراج بايت واحد من النص العادي ، حسنًا ، هذا ليس من المفترض أن يحدث.

ما يسمى هجمات التوقيت من هذا النوع دائمًا ما يكون مزعجًا ، حتى إذا كنت قد تحتاج إلى إرسال الملايين من الحزم المزيفة والوقت لهم جميعًا للحصول على أي فرصة لاستعادة بايت واحد فقط من بيانات النص العادي ...

... لأن الشبكات أسرع وأكثر قابلية للتنبؤ بها وقادرة على التعامل مع حمولات أكثر بكثير مما كانت عليه قبل بضع سنوات فقط.

قد تعتقد أن الملايين من الحزم الغادرة قد تم إرسال بريد عشوائي إليك في ، على سبيل المثال ، الساعة التالية ستبرز مثل نوع الإبهام.

لكن "مليون عبوة في الساعة أكثر أو أقل من المعتاد" ببساطة لم يعد اختلافًا كبيرًا بشكل خاص.

خطأ "oracle" مماثل في GnuTLS

حسنًا ، نفس الشخص الذي أبلغ عن خطأ توقيت الخطأ الثابت في OpenSSL أبلغ أيضًا عن ملف خطأ مماثل في GnuTLS في نفس الوقت تقريبا.

هذا واحد لديه معرف الخطأ CVE-2023-0361.

على الرغم من أن GnuTLS ليس شائعًا أو شائع الاستخدام مثل OpenSSL ، فمن المحتمل أن يكون لديك عدد من البرامج في ملكية تقنية المعلومات الخاصة بك ، أو حتى على جهاز الكمبيوتر الخاص بك ، والتي تستخدمه أو تتضمنه ، بما في ذلك FFmpeg ، و GnuPG ، و Mplayer ، و QEMU و Rdesktop و Samba و Wget و Wireshark.

ومن المفارقات أن عيب التوقيت في GnuTLS ظهر في الكود الذي كان من المفترض أن يسجل أخطاء هجوم التوقيت في المقام الأول.

كما ترى من اختلاف الكود (فرق) أدناه ، كان المبرمج على علم بأن أي شرط (if ... then) العملية المستخدمة في التحقق من خطأ فك التشفير والتعامل معه قد ينتج عنه اختلافات في التوقيت ، لأن وحدات المعالجة المركزية عمومًا تستغرق وقتًا مختلفًا اعتمادًا على الطريقة التي تتبعها التعليمات البرمجية الخاصة بك بعد تعليمات "الفرع".

(هذا صحيح بشكل خاص بالنسبة للفرع الذي غالبًا ما يسير في اتجاه ما ونادرًا ما يسير في الاتجاه الآخر ، لأن وحدات المعالجة المركزية تميل إلى تذكر أو تخزين الكود الذي يتم تشغيله بشكل متكرر من أجل تحسين الأداء ، مما يجعل الشفرة التي يتم أخذها بشكل غير متكرر تعمل بشكل أبطأ بشكل ملحوظ).

لكن المبرمج ما زال يريد تسجيل وقوع هجوم ، وهو ما يحدث إذا كان ملف if (ok) فشل الاختبار أعلاه ويتفرع إلى else { ... } والقسم الخاص به.

في هذه المرحلة ، يستدعي الرمز _gnutls_debug_log() وظيفة ، والتي قد تستغرق وقتًا طويلاً للقيام بعملها.

لذلك أدخل المبرمج دعوة متعمدة إلى _gnutls_no_log() في ال then { ... } جزء من الكود ، والذي يتظاهر بتسجيل "هجوم" عندما لا يكون هناك هجوم ، وذلك لمحاولة زيادة الوقت الذي يقضيه الرمز في أي اتجاه if (ok) يمكن أن تأخذ تعليمات الفرع.

على ما يبدو ، مع ذلك ، لم يكن مساران الشفرات متشابهين بدرجة كافية في الوقت الذي استخدموا فيه (أو ربما ملف _gnutls_debug_log() وظيفة من تلقاء نفسها غير متسقة بشكل كافٍ في التعامل مع أنواع مختلفة من الأخطاء) ، ويمكن للمهاجم أن يبدأ في التمييز بين حكايات فك التشفير بعد مليون محاولة أو نحو ذلك.

ماذا ستفعلين.. إذًا؟

إذا كنت مبرمجًا: كان إصلاح الخطأ هنا بسيطًا ، واتبع مبدأ "الأقل هو الأكثر".

تم حذف الكود باللون الوردي أعلاه ، والذي اعتبر أنه لا يعطي بيانات مفيدة للغاية لاكتشاف الهجمات على أي حال ، ببساطة ، على أساس أن الكود غير الموجود لا يمكن تجميعه عن طريق الخطأ ، بغض النظر عن إعدادات البناء الخاصة بك ...

... والشفرة التي لم يتم تجميعها لا يمكن تشغيلها مطلقًا ، سواء عن طريق الصدفة أو التصميم.

إذا كنت من مستخدمي GnuTLS: النسخة التي تم إصدارها مؤخرًا 3.7.9 و "نكهة المنتج الجديد" 3.8.0 لديك هذا الإصلاح ، جنبًا إلى جنب مع العديد من الميزات الأخرى المضمنة.

إذا كنت تقوم بتشغيل توزيعة Linux ، فتحقق من وجود تحديثات لأي إصدار مكتبة مشتركة مُدارة مركزيًا من GnuTLS لديك ، وكذلك للتطبيقات التي تجلب نسختها الخاصة.

في Linux ، ابحث عن الملفات التي تحمل الاسم libgnutls*.so للعثور على أي مكتبات مشتركة موجودة ، والبحث عنها gnutls-cli للعثور على أي نسخ من الأداة المساعدة لسطر الأوامر والتي غالبًا ما تكون مضمنة في المكتبة.

يمكنك الجري gnutls-cli -vv لمعرفة أي إصدار من libgnutls إنه مرتبط ديناميكيًا بـ:

 $ gnutls-cli -vv gnutls-cli 3.7.9 <- حصلت توزيعة Linux الخاصة بي على التحديث يوم الجمعة الماضي (2023-02-10)

---

• محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
• بلاتوبلوكشين. Web3 Metaverse Intelligence. تضخيم المعرفة. الوصول هنا.
• المصدر https://nakedsecurity.sophos.com/2023/02/13/serious-security-gnutls-follows-openssl-fixes-timing-attack-bug/