Andrew Bennett

يقوم نظام التراجع (fallback) الخاص بـ AES-GCM المكتوب بلغة Erlang النقية في `jose jwa aes` باشتقاق عدد بتات علامة المصادقة التي يتم التحقق منها من العلامة التي يوفرها المهاجم نفسه. في بند `{aes gcm, Bits}` ضمن الدالة `block decrypt/4` يتم حماية العلامة الواردة فقط بواسطة `is binary/1` دون التحقق من طولها. بعد ذلك، تقوم الدالة `gcm block decrypt/6` بحساب `TBits = bit size(T)` ومقارنة تلك البتات فقط مع العلامة الحقيقية المكونة من 128 بت. يمكن للمهاجم الذي يتحكم في رمز JWE تقصير علامة المصادقة إلى 8 بتات فقط، مما يقلل من مقاومة التزوير من 2^-128 إلى 2^-8. يؤدي هذا إلى قبول النص المشفر المزور كأصيل في غضون 256 محاولة دون معرفة المفتاح، مما يتسبب في تزوير علامة المصادقة وتجاوز سلامة البيانات. بالإضافة إلى ذلك، فإن تقديم علامة تزيد عن 128 بت يتسبب في حدوث `badmatch` يؤدي إلى تعطل عملية فك التشفير. تظهر هذه المشكلة عندما لا يتم توفير AES-GCM بواسطة NIF (وظيفة منفذة أصلياً) للتشفير، كما هو الحال في إصدارات FIPS أو الإصدارات المجردة (stripped) أو إصدارات OTP القديمة.

يحتوي موديول `jose jwa pkcs1` على ثغرة Bleichenbacher padding oracle في عملية فك تشفير RSAES-PKCS1-v1 5 المكتوبة بلغة pure-Erlang. تقوم الدالة `eme pkcs1 decode/2` بإرجاع الرسالة المستردة عندما يكون حشو PKCS#1 v1.5 صالحاً، وإلا فإنها تعيد نتيجة خطأ متميزة. بالإضافة إلى ذلك، تعيد الدالة `rsaes pkcs1 decrypt/2` القيمة `{error, {badsize, }}` عند فشل التحقق من الحجم. تفتقر عملية التنفيذ إلى تدابير رفض ضمنية، حيث لا يتم استبدال النص الصريح بنص عشوائي زائف محدد عند فشل الحشو، مما يؤدي إلى تسريب إشارة مطابقة الحشو. علاوة على ذلك، فإن استخدام `crypto:mod pow/3` غير المعمى في الدالة `dp/2` يجعل التحقق من الحشو قابلاً للتمييز من خلال هجمات التوقيت، حتى لو تم توحيد قيم الخطأ. يمكن لمهاجم غير مصرح له يمتلك مفتاح RSA العام إرسال نصوص مشفرة إلى نقطة نهاية فك التشفير التي تفك تغليف مفاتيح JWE RSA1 5 أو تستدعي `decrypt private/3` مع `rsa pkcs1 padding` لاستعادة النص الصريح، مثل مفاتيح تشفير المحتوى، أو تزوير التواقيع من خلال استعلامات النصوص المشفرة المختارة التكيفية. تظهر هذه المشكلة فقط عند تفعيل خيار `crypto fallback` وعدم توفر فك تشفير RSA1 5 أصلي في بيئة تشغيل OTP.

يسمح التعامل غير السليم مع البيانات عالية الضغط، والمعروف بتضخيم البيانات، لمهاجم عن بُعد باستنفاد ذاكرة العقدة باستخدام رمز JWE صغير ومصمم خصيصاً. تقوم الدالة `jose jwe zip:uncompress/2` في `src/jwe/jose jwe zip.erl` بفك ضغط النص الواضح المضغوط بتقنية DEFLATE لرمز JWE يحمل رأس `zip: DEF` عن طريق استدعاء `zlib:inflate/2` على التدفق الذي يتحكم فيه المهاجم، دون وجود حدود لحجم المخرجات أو نسبة التضخم. يمكن أن يؤدي ذلك إلى تضخم رمز بحجم بضعة كيلوبايتات إلى مئات الميجابايت أو الجيجابايت. تتم عملية فك الضغط تلقائياً أثناء فك التشفير عبر `jose jwe:block decrypt/2` (أو `JOSE.JWE.block decrypt/2` في Elixir) قبل فحص الحمولة. باستخدام خوارزميات إدارة المفاتيح غير المتماثلة مثل RSA-OAEP أو ECDH-ES، يحتاج المهاجم فقط إلى المفتاح العام للمستلم لإنشاء هذا الرمز، دون الحاجة إلى مصادقة. يمكن أن يؤدي ذلك إلى تعطل BEAM وتسبب في حجب الخدمة.

تُستخدم الدالة `jose jwk:shared secret/2` (المتاحة في Elixir باسم `JOSE.JWK.shared secret/2`) لاشتقاق سر مشترك ECDH من مفتاحي JSON Web Keys (JWKs). يوجد خلل حيث تتطابق الدالة فقط عندما يكون لكلا مفتاحي JWK نفس وحدة نوع المفتاح (`kty`). إذا اختلفت أنواع المفاتيح، مثل مفتاح EC ومفتاح RSA، فإن بند التراجع يعيد استدعاء الدالة بنفس الوسائط، مما يؤدي إلى حلقة تكرارية ذات ذيل غير محدودة. تستهلك هذه الحلقة 100% من وحدة معالجة المركزية لمجدول Erlang. يمكن للمهاجم الذي يقدم مفتاح JWK مصمم خصيصاً تحفيز هذا السلوك، ويمكن أن تؤدي الطلبات المتكررة إلى استنفاد جميع المجدولين المتاحين، مما يؤدي إلى حجب الخدمة.

تستخدم المكتبة تجزئة كلمة مرور بجهد حسابي غير كافٍ عند تصدير المفاتيح الخاصة المشفرة بكلمة مرور. وتحديداً، تستخدم الدالة `jose jwk:to der/2` (`JOSE.JWK.to der/2`) الدالة `jose jwk der:to binary/3` لتسلسل المفاتيح كـ PKCS#8 EncryptedPrivateKeyInfo باستخدام مخطط PBES2. تعتمد هذه العملية على معاملات اشتقاق مفاتيح ثابتة: PBKDF2-HMAC-SHA256 مع 2048 تكراراً وملح عشوائي بطول 8 بايت، وكلاهما أقل بكثير من المعايير الصناعية. تسمح هذه الثغرة للمهاجم الذي يحصل على كتلة مشفرة مصدرة بتنفيذ هجوم قاموس دون اتصال أو هجوم القوة الغاشمة لاستعادة المفتاح الخاص.

تسمح ثغرة قناة جانبية زمنية في نظام التراجع Curve25519 المكتوب بلغة Erlang النقية باستعادة المفتاح الخاص X25519 طويل الأمد. يستخدم التنفيذ سلم مونتغمري تكراري في الدالة `jose jwa x25519:curve25519/2` حيث تعتمد العمليات مثل `jose jwa x25519:montgomery add/3` و `jose jwa x25519:montgomery double/1` على حسابات bignum في Erlang تعتمد على القيمة. وبناءً على ذلك، فإن وقت تنفيذ نقاط الدخول العامة بما في ذلك `jose jwa x25519:scalarmult/2` و `jose jwa x25519:x25519/2` و `jose jwa x25519:x25519 base/1` و `jose jwa x25519:sk to pk/1` يتغير بناءً على المفتاح الخاص. يمكن استغلال ذلك عندما تقوم خدمة بفك تشفير رسائل ECDH-ES (JWE) يرسلها المهاجم عبر `JOSE.JWK.box decrypt ecdh es/2` والتي تستدعي `jose jwa curve25519:x25519 shared secret/2`. يمكن للمهاجم الذي يقيس توقيت فك التشفير استعادة المفتاح الخاص بت gradually (بت بت)، مما يؤدي إلى انتهاك سرية وموثوقية البيانات.

تسمح التعقيدات الخوارزمية غير الفعالة لمهاجم عن بعد غير مصرح له بالتسبب في حالة رفض الخدمة نتيجة استنفاد وحدة المعالجة المركزية (CPU) عن طريق إرسال مفتاح ويب JSON (JWK) من نوع RSA تم التلاعب به. عندما يقوم التطبيق بتحليل JWK غير موثوق من خلال واجهة برمجة التطبيقات `jose jwk:from binary/1` أو `jose jwk:from map/1` (أو أغلفة Elixir وهي `JOSE.JWK.from binary/1` و `JOSE.JWK.from map/1`)، يتم توجيه مفتاح RSA الخاص الذي يوفر `d` و `e` و `n` ولكن يغفل معلمات نظرية الباقي الصينية (`p` و `q` و `dp` و `dq` و `qi`) إلى `convert sfm to crt/1`. تحاول هذه الدالة استعادة الأعداد الأولية المفقودة عن طريق تحليل المقياس (modulus)، والذي يتم قراءته مباشرة من مدخلات base64url دون التحقق من صحته. عندما لا يمكن تقسيم المقياس إلى عاملين، تقوم حلقة البحث `convert sfm to crt find p/6` بإجراء رفع أسّي نمطي بشكل مستمر، مما يستهلك موارد وحدة المعالجة المركزية بشكل كبير. يمكن أن يؤدي إغراق النظام بهذه الطلبات إلى إشغال جميع المجدولين وتعطيل الخدمة.

تقبل المكتبة توقيعات JWS من نوع ECDSA (ES256, ES256K, ES384, ES512) بطول غير قياسي. أثناء عملية التحقق، تقوم الدالة `jose jwk kty ec:verify/4` في الملف `src/jwk/jose jwk kty ec.erl` بتقسيم التوقيع الخام بناءً على طول البايت الفعلي باستخدام `split binary(Signature, byte size(Signature) div 2)` بدلاً من فرض الطول الثابت المطلوب في RFC 7518 §3.4. بعد ذلك، يتم فك تشفير كل نصف باستخدام `crypto:bytes to integer/1` التي تتجاهل بايتات الصفر الرائدة. يؤدي ذلك إلى قابلية تغيير التوقيع (signature malleability)، حيث يمكن للمهاجم الذي يمتلك رمزاً صالحاً إضافة بايتات صفر رائدة إلى نصفي R و S لإنشاء سلاسل بايتات توقيع متعددة ومتميزة يتم التحقق منها مقابل نفس المفتاح. لا يسمح هذا بتزوير البيانات أو انتحال صفة الموقع، ولكنه يعطل ضوابط الأمان التي تفترض أن التوقيع فريد، مثل إلغاء الرمز عن طريق التجزئة (token-revocation-by-hash)، أو منطق إلغاء التكرار، أو ذاكرة التخزين المؤقت لإعادة التشغيل والجمود.