CVE-2025-69418 in OpenSSL
الملخص
بحسب VulDB • 28/06/2026
ملخص المشكلة: عند استخدام واجهة برمجة التطبيقات (API) الخاصة بـ OCB على المستوى المنخفض مباشرةً مع AES-NI أو<br>مسارات تنفيذ أخرى مسرعة بالأجهزة، قد يؤدي إدخال يكون طوله غير مضاعف لـ 16 بايت إلى ترك الكتلة الجزئية الأخيرة دون تشفير ودون مصادقة.<br><br>ملخص الأثر: قد يتم كشف الباقي من 1-15 بايت في نهاية الرسالة كنص واضح أثناء التشفير، ولا تكون مشمولة بعلامة المصادقة (authentication tag)، مما يسمح للمهاجم بقراءة أو العبث بهذه البايتات دون اكتشاف ذلك.<br><br>تعالج روتينات تشفير وفك التشفير الخاصة بـ OCB على المستوى المنخفض في مسار التدفق المسرع بالأجهزة كتلاً كاملة بحجم 16 بايت، لكنها لا تقوم بتحديث مؤشرات الإدخال/الإخراج. ثم تعمل شفرة التعامل مع الذيل اللاحقة على المؤشرات الأساسية الأصلية، مما يؤدي فعلياً إلى إعادة معالجة بداية المخزن المؤقت (buffer) بينما تترك البايتات النهائية الفعلية دون معالجة. كما يستبعد مجموع التحقق من المصادقة (authentication checksum) بايتات الذيل الحقيقية.<br><br>ومع ذلك، فإن المستهلكين المعتادين لـ OpenSSL الذين يستخدمون EVP غير متأثرين لأن تطبيقات OCB على المستوى الأعلى في EVP والمزود (provider) تقسم المدخلات بحيث تتم معالجة الكتل الكاملة والكتل الجزئية المتبقية في مكالمات منفصلة، مما يتجنب مسار الشفرة المشكل. بالإضافة إلى ذلك، لا تستخدم بروتوكول TLS مجموعات خوارزميات تشفير OCB. تؤثر الثغرة فقط على التطبيقات التي تستدعي الدوال CRYPTO_ocb128_encrypt() أو CRYPTO_ocb128_decrypt() مباشرةً باستخدام أطوال غير متوافقة مع حجم الكتلة في مكالمة واحدة، وذلك في الإصدارات المسرعة بالأجهزة.<br><br>لهذه الأسباب، تم تقييم مستوى الخطورة على أنه منخفض.<br><br>وحدات FIPS في الإصدارات 3.6 و3.5 و3.4 و3.3 و3.2 و3.1 و3.0 غير متأثرة بهذه المشكلة، حيث أن وضع OCB ليس خوارزمية معتمدة من قبل FIPS.<br><br>الإصدارات OpenSSL 3.6 و3.5 و3.4 و3.3 و3.0 و1.1.1 عرضة لهذه المشكلة.<br><br>الإصدار OpenSSL 1.0.2 غير متأثر بهذه المشكلة.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.