Peter Ullrich

يحدث حقن XML في مشفر XML Saxy لأن الدالة `Saxy.Encoder.cdata/1` تقوم بتسلسل عقد `{:cdata, characters}` عن طريق تغليف الأحرف بين `<![CDATA[` و `]]>` دون تحييد الحمولة. بينما تقوم المسارات الأخرى بترميز رموز XML الخاصة، فإن مسار CDATA لا يعالج السلسلة النصية `]]>`، وهي الطريقة الوحيدة لإنهاء قسم CDATA. يمكن للمهاجم تقديم نص غير موثوق يحتوي على `]]>` لإنهاء القسم قبل أوانه، مما يسمح بتحليل المدخلات اللاحقة كعلامات XML. يتيح ذلك حقن عناصر وسمات شقيقة عشوائية في بنية المستند. يؤثر هذا الخلل على الخدمات التي تنشئ أغلفة SOAP، أو خلاصات RSS أو Atom، أو خرائط المواقع، أو SVG، أو تصديرات XML من محتوى يقدمه المستخدم. يتم تفعيل هذه الثغرة عند استخدام `Saxy.XML.cdata/1` بالتزامن مع `Saxy.encode!/2` أو `Saxy.encode to iodata!/2`.

يفشل مشفر XML في التحقق من صحة أو هروب الهدف ومحتوى تعليمات المعالجة، حيث يقوم بكتابتها حرفياً في المستند الناتج. نظرًا لأن التسلسل `?>` ينهي تعليمات المعالجة، يمكن للمهاجم استخدام هذا التسلسل لإغلاق البنية مبكرًا وحقن عناصر وعناصر تحكم وتعليمات معالجة إضافية تعسفية في المستند المتسلسل. يحدث هذا لأن المشفر يدمج الحقول دون التحقق منها وفقًا لقيود مواصفات XML. تعد الدالة `Saxy.XML.processing instruction/2` منشئًا عامًا يسمح بتوريث هذا الخلل. يمكن أن يؤدي ذلك إلى حقن XML، مما ينتج عنه سجلات مزورة أو أوراق أنماط محقونة أو محتوى نشط عندما يتم معالجة المخرجات بواسطة محلل لاحق أو متصفح. يتم تفعيل هذه المشكلة عندما يتم تمرير عقدة `{:processing instruction, name, content}` إلى `Saxy.encode!/2` أو `Saxy.encode to iodata!/2` باستخدام مدخلات غير موثوقة.

توجد ثغرة حقن XML في مشفر Saxy. يفشل `Saxy.Encoder` في تحييد تسلسل `--` في محتوى تعليق XML لأن الدالة `escape comment/2` تعيد الثنائي الخاص بالتعليق دون تغيير في كل بند وتضيف مسافة فقط عندما ينتهي التعليق بـ `-` واحدة. وبناءً على ذلك، لا يتم هروب أو رفض `--` الداخلية أو `-->` الكاملة قبل أن يقوم المشفر بتغليف المحتوى بالمحددات. عندما تقوم إحدى التطبيقات بتسلسل نص يتحكم فيه المهاجم كتعليق من خلال `Saxy.XML.comment/1` أو عنصر نموذج بسيط خام `{:comment, text}`، يمكن للمهاجم إغلاق التعليق مبكرًا باستخدام `-->` وحقن علامات شقيقة تعسفية في المستند المتسلسل. يؤدي ذلك إلى تنفيذ نص برمجي عابر للمواقع (XSS) مخزن عندما يتم عرض المستند كـ HTML أو SVG، أو تزوير البيانات عندما يتم استهلاكها بواسطة معالج XML آخر. تؤثر هذه المشكلة فقط على التطبيقات التي تقوم بتسلسل نصوص غير موثوقة باستخدام `Saxy.encode!/2` أو `Saxy.encode to iodata!/2`.

يسمح التحقق غير السليم من الكمية المحددة في الإدخال ضمن وحدة `JSON` في مكتبة Elixir القياسية لمهاجم غير مصرح له بالتسبب في حالة رفض الخدمة من خلال استنفاد وحدة المعالجة المركزية والذاكرة عن طريق تقديم مستند JSON مصمم خصيصًا. تقوم الدالتان `JSON.decode/1` و `JSON.decode!/1` بتحويل الثوابت الصحيحة باستخدام `erlang:binary to integer/1` دون تقييد طولها. ونتيجة لذلك، فإن الثابت الصحيح الذي يحتوي على مليون رقم يستهلك من 100 إلى 300 ضعف وحدة المعالجة المركزية مقارنة بسلسلة نصية من نفس الطول، وتؤدي الثوابت التي تتجاوز حوالي 1.29 مليون رقم إلى إثارة `SystemLimitError`. وتعتبر التطبيقات التي يتم إنشاؤها بواسطة `phx.new` عرضة لهذا الخطر بشكل خاص لأنها تقوم بفك تشفير أجسام الطلبات باستخدام `Plug.Parsers` قبل عملية التوجيه والمصادقة.

يمكن لمهاجم عن بُعد غير مصرح له استنفاد ذاكرة الخادم عن طريق إرسال جسم طلب يتكون من العديد من إطارات DATA بحجم 1 بايت. تحدث المشكلة في قارئ جسم طلب HTTP/2 حيث تقوم الدالة `do read data/5` في `lib/bandit/http2/stream.ex` بتخزين كل حمولة إطار DATA كعنصر قائمة فردي حتى تنتهي عملية القراءة. نظرًا لأن خيار `:length` في `read body/2` يتتبع إجمالي عدد البايتات وليس عدد الإطارات، فإن الحجم الكبير من الإطارات الصغيرة يتسبب في استهلاك كبير للذاكرة لكل بايت. يتفاقم هذا التأثير عند تداخل الإطارات عبر ما يصل إلى 500 تدفق (stream) متزامن لكل اتصال. تؤثر هذه المشكلة على أي مسار يقوم فيه Plug بقراءة جسم الطلب، بما في ذلك المسارات التي تستخدم `Plug.Parsers` لطلبات POST و PUT و PATCH.

تسمح مشكلة في التعقيد الخوارزمي غير الفعال في تنفيذ HTTP/2 لمهاجم عن بُعد غير مصرح له باستنفاد موارد وحدة المعالجة المركزية (CPU) للخادم. من خلال فتح آلاف التدفقات التي تحظر نافذة إرسال الاتصال، ثم إرسال إطارات SETTINGS صغيرة أو إطارات WINDOW UPDATE على مستوى الاتصال، يمكن للمهاجم إجبار الخادم على إجراء عمليات قائمة تربيعية O(n²). يحدث هذا لأن الدالة `do pending sends/2` في `lib/bandit/http2/connection.ex` تعيد محاولة كل إرسال في الانتظار وتزيل الإدخالات باستخدام `List.delete/2` مما يجعل الخادم يمر عبر قائمة الإرسالات المحظورة بالكامل لكل إطار. يتفاقم هذا التأثير لأن القيمة الافتراضية لـ `max concurrent streams` هي `:infinity` مما يسمح للمهاجم بالتحكم في عدد التدفقات المحظورة.

يوجد تفسير غير متسق لطلبات HTTP، والمعروف باسم (HTTP Request/Response Smuggling)، في قارئ الجسم المجزأ (chunked body reader) لبروتوكول HTTP/1.1. يسمح هذا لمهاجم عن بُعد غير مصرح له بتهريب طلب ثانٍ عبر وكيل أمامي (front-end proxy) من خلال ملحق مجزأ يحتوي على LF (تغذية سطر) بسيطة. تحدث المشكلة في الملف `lib/bandit/http1/socket.ex` حيث يقبل قارئ الأجزاء سطر حجم الجزء حتى أول CRLF ويتجاهل كل ما بعد الفاصلة المنقوطة `;` دون التحقق منه وفقًا لقواعد `chunk-ext` في RFC 9112. وبناءً على ذلك، يتم السماح بمرور بايتات التحكم مثل LF و CR البسيطة. إذا كان الوكيل الأمامي يعتبر LF البسيطة نهاية للسطر، فقد يقرأ التدفق كطلب واحد، بينما يعتبره Bandit طلبًا منفصلاً (pipelined request)، مما قد يؤدي إلى تجاوز ضوابط الوصول الخاصة بالوكيل. تؤثر هذه المشكلة فقط على عمليات النشر التي تستخدم وكيلًا أماميًا يتعامل مع LF البسيطة كنهاية للسطر ويقوم بتمرير الأجسام المجزأة دون تغيير.

تسمح ثغرة قناة جانبية زمنية في نظام التراجع 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 (بت بت)، مما يؤدي إلى انتهاك سرية وموثوقية البيانات.

يسمح التعامل غير السليم مع البيانات عالية الضغط، والمعروف بتضخيم البيانات، لمهاجم عن بُعد باستنفاد ذاكرة العقدة باستخدام رمز 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 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.

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

يمكن لمهاجم عن بُعد غير مصرح له استنفاد ذاكرة الخادم عن طريق إرسال إطارات DATA تتجاوز نافذة الاستقبال المعلن عنها في تنفيذ HTTP/2. يمكن للمهاجم طلب استجابة أكبر من النافذة الأولية البالغة 65,535 بايت وحجب `WINDOW UPDATE` مما يؤدي إلى حظر عملية التدفق أثناء الإرسال والتوقف عن القراءة. بعد ذلك، يؤدي إغراق إطارات DATA صغيرة على هذا التدفق إلى وضع كل إطار في قائمة انتظار صندوق بريد التدفق حتى ينفد نظام BEAM من الذاكرة. يحدث هذا لأن الدالة `Bandit.HTTP2.Connection.handle frame/3` تقوم بتوجيه إطارات DATA إلى عملية التدفق دون مراجعة نافذة الاستقبال، وتقوم الدالة `Bandit.HTTP2.FlowControl.compute recv window/2` بتجديد النافذة عند وصول البيانات بدلاً من استهلاكها، ولا ترسل خطأ `FLOW CONTROL ERROR` عند حدوث انتهاك.

يمكن لمهاجم عن بعد غير مصرح له إبقاء عمليات التدفق (stream processes) مفتوحة إلى أجل غير مسمى في قارئ جسم طلب HTTP/2. يحدث هذا لأن الدالة `do read data/4` في `lib/bandit/http2/stream.ex` تعيد ضبط العد التنازلي لـ `read timeout` كلما تم استلام إطار WINDOW UPDATE أو إطار SETTINGS فارغ. نظرًا لأن هذه الإطارات لا تقدم بيانات الجسم ولكنها تنهي فترة الانتظار، يمكن للعميل إرسال هذه الإطارات المكونة من 9 بايت بشكل متكرر لإبقاء `read body` محظورًا. يتيح ذلك للمهاجم إشغال عملية التدفق وأي موارد تحتفظ بها التطبيق أثناء عملية القراءة عبر تدفقات واتصالات متعددة.

يمكن لمهاجم عن بُعد غير مصرح له التسبب في استنفاد ذاكرة الخادم من خلال مشكلة تضخيم البيانات في تنفيذ HTTP/2. من خلال إرسال كتلة HEADERS صغيرة مضغوطة باستخدام HPACK تخزن قيمة `cookie` كبيرة في جدول HPACK الديناميكي وتشير إليها عشرات الآلاف من المرات، يمكن للمهاجم إجبار الخادم على تخصيص ملف ثنائي ضخم. يحدث هذا لأن `Bandit.HTTP2.Connection` يحدد فقط حجم الكتلة المضغوطة عبر `max header block size` بينما القيمة الافتراضية لإعداد `max header list size` هي `:infinity` مما يؤدي إلى عدم رفض القائمة الموسعة. بعد ذلك، تقوم الدالة `combine cookie crumbs/1` في `lib/bandit/http2/stream.ex` بدمج هذه المراجع في ملف ثنائي واحد كبير. وبما أن `max concurrent streams` لها القيمة الافتراضية `:infinity` أيضاً، يمكن لعدة تدفقات متزامنة مضاعفة استهلاك الذاكرة هذا، مما قد يؤدي إلى تعطل جميع التطبيقات على عقدة BEAM.

يمكن لمهاجم عن بُعد غير مصرح له التسبب في زيادة غير محدودة في استهلاك الذاكرة ووحدة المعالجة المركزية لكل اتصال في تنفيذ HTTP/2. يحدث هذا لأن البرنامج يقوم بتغيير حجم جدول ترميز HPACK بناءً على `SETTINGS HEADER TABLE SIZE` الذي يعلنه العميل دون تطبيق حد أقصى من جانب الخادم، مما يسمح بأحجام تصل إلى 2^32-1 بايت. نظرًا لأن رؤوس الاستجابة ذات القيم المتميزة مثل `date` أو `content-length` يتم فهرستها ولا يتم حذفها، فإن الجدول ينمو مع كل استجابة. نتيجة لذلك، تقوم الدالة `lookup by header` في مكتبة HPAX بفحص الجدول خطيًا، مما يؤدي إلى تكلفة وحدة معالجة مركزية بمقدار O(N²) لتقديم N من الاستجابات في اتصال واحد. تكمن المشكلة في `Bandit.HTTP2.Connection` (`lib/bandit/http2/connection.ex`) حيث يتم تمرير `remote settings.header table size` إلى `HPAX.resize/2` ، وتقوم الدالة `encode headers` بترميز كل رأس استجابة كـ `:store`.

يسمح خلل في معالجة اتصال WebSocket لعميل عن بُعد بالاستمرار في تشغيل كود المعالج بعد أن حاول الخادم إيقاف الاتصال. يحدث هذا لأنه عندما تعيد دالة استدعاء (callback) القيمة `{:stop, ...}`، يدخل عملية `Bandit.WebSocket.Connection` في حالة `:closing` ولكنها تستمر في معالجة إطارات البيانات والرسائل الواردة. لا تتحقق الدوال `handle frame/3` و `handle info/3` من حالة الاتصال، مما يسمح للإطارات بالوصول إلى `handle in/2` والرسائل بالوصول إلى `handle info/2` حتى يرسل العميل إطار Close، أو ينقطع اتصال TCP، أو ينتهي وقت الخمول. يمكن أن يؤدي ذلك إلى تجاوز فحوصات التفويض في `init/1` أو التهرب من إنهاء الجلسات مثل الطرد أو الحظر، مما قد يسمح بالوصول غير المصرح به إلى إجراءات إدارية.

يمكن لمهاجم عن بُعد غير مصرح له استنفاد ذاكرة وخادم وحدة المعالجة المركزية (CPU) عن طريق إرسال جسم طلب يتكون من العديد من الأجزاء (chunks) بحجم 1 بايت. تكمن المشكلة في قارئ الجسم المجزأ HTTP/1.1 في `lib/bandit/http1/socket.ex` الذي يحتفظ بكل جزء كخلية قائمة ومصطلح ثنائي خاص به حتى يتم دمجهم بواسطة الدالة `IO.iodata to binary/1`. نظرًا لأن خيار `:length` في الدالة `read body/2` يحسب بايتات البيانات فقط ولا يضع حدًا لعدد الأجزاء، فإن الأجزاء الصغيرة تستهلك ذاكرة أكبر بكثير من حمولتها الفعلية. يمكن أن يحدث هذا حتى لو لم تكن المسار بحاجة إلى قراءة الجسم، لأن الدالة `ensure completed/1` تقوم بتفريغ الأجسام غير المقروءة في اتصالات keep-alive.

تسمح عملية تنظيف غير صحيحة عند حدوث استثناءات في معالج HTTP/2 لمهاجم عن بُعد غير مصرح له بتجاوز حدود الموارد لكل اتصال. عندما يتسبب إطار في حدوث `StreamError` أثناء معالجة قطعة TCP، تقوم الدالة `handle data/3` في `Bandit.HTTP2.Handler` بإرسال RST STREAM وإعادة حالة الاتصال إلى ما كانت عليه قبل معالجة القطعة. وبينما تستمر التدفقات التي تم فتحها بواسطة إطارات سابقة في القطعة في تنفيذ استدعاءات Plug الخاصة بها، يتم التراجع عن السجلات الداخلية — بما في ذلك تعدادات التدفق، و `last stream id` ، وطوابع rapid-reset الزمنية، وحالة فك ترميز HPACK. نتيجة لذلك، تفشل `max concurrent streams` و `max requests` ومحدد rapid-reset في حساب هذه التدفقات النشطة، مما يسمح للعميل بتجاوز حدود التزامن المكونة واستنزاف موارد وحدة المعالجة المركزية والذاكرة في الخادم.

يمكن لمهاجم عن بُعد غير مصرح له التسبب في استهلاك مفرط لوحدة المعالجة المركزية (CPU) للخادم بسبب تعقيد خوارزمي غير فعال في محلل أعداد الصحيحة للترويسة. تقوم الدالة `Bandit.Headers.parse integer/2` في `lib/bandit/headers.ex` بمعالجة الأرقام رقمًا تلو الآخر دون حد لعدد الأرقام، مع تخصيص bignum جديد في كل خطوة. يؤدي ذلك إلى وقت معالجة تربيعي بالنسبة لطول المدخلات. يتم تحفيز هذه المشكلة من خلال تقديم قيمة `content-length` أو منفذ `Host` أو `:authority` يتكون من آلاف الأرقام. يحدث هذا عند معالجة مدخلات الطلب الخام عبر HTTP/1 و HTTP/2 قبل إجراء أي فحص للنطاق. في بيئات HTTP/2، يمكن للمهاجم استخدام تخزين جدول HPACK الديناميكي لتضخيم التأثير، حيث يتم إرسال قيمة كبيرة مرة واحدة ثم الإشارة إليها في التدفقات اللاحقة لإبقاء الخادم مشغولاً بأقل قدر من حركة المرور.

يمكن لمهاجم عن بُعد غير مصرح له استنفاد ذاكرة الخادم من خلال عملية إعادة تجميع أجزاء WebSocket. تقوم الدالة `Bandit.WebSocket.Connection` بالتحقق من المتغير `max fragmented message size` مقابل بايتات الحمولة المستلمة، ولكنها لا تضع حداً لعدد الأجزاء الإجمالي. من خلال إرسال رسالة مجزأة تتكون من العديد من إطارات الاستمرار بحجم 1 بايت، يمكن للمهاجم استهلاك ذاكرة أكبر بكثير من الحد المكون. على سبيل المثال، يتطلب الجزء الذي حجمه 1 بايت حوالي 150 إلى 170 بايت من ذاكرة الخادم. بالإضافة إلى ذلك، فإن إرسال إطارات Ping بين الأجزاء يسمح للاتصال بالبقاء نشطاً بعد انتهاء مهلة الخمول.