Mat Trudel

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

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

تسمح مشكلة في التعقيد الخوارزمي غير الفعال في تنفيذ 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/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.

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

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

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

يوجد تفسير غير متسق لطلبات 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 البسيطة كنهاية للسطر ويقوم بتمرير الأجسام المجزأة دون تغيير.

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

يمكن لمهاجم عن بُعد غير مصرح له تعيين `conn.host` و `conn.port` بقيم تخالف قواعد مضيف RFC 3986 من خلال سلطة هدف طلب HTTP/1 ذو النموذج المطلق أو نموذج السلطة. بينما يقوم البرنامج بالتحقق من صحة ترويسة `Host` ويرد بخطأ 400 عندما تكون مشوهة، فإن السلطة الموجودة في هدف الطلب لها الأولوية وفقًا لـ RFC 9112. وتقوم الدالة `determine host and port!/4` في `lib/bandit/pipeline.ex` بتمرير هذه السلطة إلى التطبيق دون فحص. يسمح هذا بإدخال بايتات NUL و DEL وبايتات غير ASCII، وعناوين IP غير صالحة، ومنافذ خارج النطاق 1..65535. التطبيقات التي تبني روابط URL مطلقة من `conn.host` ، مثل تلك التي تستخدم `Plug.Conn.request url/1` أو مساعدات URL الخاصة بـ Phoenix، قد تصدر روابط تتحكم السلطة فيها بواسطة المهاجم. بالنسبة لطلبات `CONNECT` ، يتم وضع سلسلة المنفذ غير المحللة في `conn.port` ، مما قد يؤدي إلى حدوث خطأ في `Plug.Conn.request url/1` لأن `Plug.Conn.port number/0` يتوقع عددًا صحيحًا.

يسمح استهلاك الموارد غير المنضبط لمهاجم عن بُعد غير مصرح له بتثبيت عمليات تدفق HTTP/2 إلى أجل غير مسمى. من خلال إرسال تدفق من إطارات `WINDOW UPDATE` صغيرة أو إطارات `SETTINGS` فارغة، يمكن للمهاجم إعادة تعيين الموعد النهائي البالغ 15 ثانية لعمليات التدفق المحجوبة. يحدث هذا من خلال مسارين مستقلين: أحدهما حيث تقوم `Bandit.HTTP2.Connection.finish data/5` بإعادة جدولة عمليات الإرسال المتقدمة جزئيًا في `pending sends` بطابع زمني `expires at` جديد، والآخر حيث تقوم `Bandit.HTTP2.Stream.send data/3` بالتكرار عند كل `WINDOW UPDATE` للتدفق وإعادة ضبط `read timeout` جديد. يحافظ هذا السلوك على بقاء عملية التدفق المحجوبة وحالة Plug والموارد المرتبطة بها نشطة، مما قد يؤدي إلى استنفاد عمليات الخادم والذاكرة.

تؤدي المعالجة غير الصحيحة لتسلسلات CRLF إلى تمكين مهاجم بعيد غير مصادق عليه من تهريب أحرف «العودة إلى السطر» (CR) أو «تغذية السطر» (LF) أو «الصفر» (NUL) إلى رؤوس الطلبات المرئية للتطبيق عبر HTTP/2. تقوم الدالة `Bandit.HTTP2.Stream.read headers/1` بالتحقق من موضع الرؤوس الزائفة، وتفردها، وحالة الأحرف في أسماء الرؤوس، والرؤوس الخاصة بالاتصال، وقيمة `te`، و`content-length`، لكنها تفشل في التحقق من قيم الحقول. نظرًا لأن HPACK ينقل بايتات عشوائية، فإن كتلة HEADERS التي تحتوي على `r` أو ` ` أو `0` يتم فك تشفيرها دون أخطاء، ويتم وضع هذه القيم في `conn.req headers` دون تغيير. في حين أن مسار HTTP/1 يرفض هذه البايتات، فإن مسار HTTP/2 لا يرفضها. يحدث الخطر عندما يستهلك تطبيق في اتجاه التدفق (downstream) قيم الرؤوس هذه، مثل إلحاقها بسجل نص عادي أو ربطها في طلب في اتجاه التدفق (upstream). بالإضافة إلى ذلك، قد يتم قبول رأس زائف مكرر `:authority`، حيث تُستخدم الحالة الأولى كـ `conn.host` بينما تظل القيمة المتعارضة مرئية للتطبيق.

يمكن لمهاجم عن بُعد غير مصدق أن يثبت عددًا غير محدود من عمليات تدفق HTTP/2 إلى أجل غير مسمى من خلال استغلال التحكم في التدفق على مستوى الاتصال. عندما يتجاوز نص استجابة التدفق نافذة الإرسال على مستوى اتصال HTTP/2، يقوم `Bandit.HTTP2.Connection` بوضع البايتات المتبقية وإغلاق الرد في قائمة الانتظار `pending sends`، مما يتسبب في حظر عملية التدفق إلى الأبد أثناء استدعاء متزامن لعملية الاتصال. ونظرًا لعدم وجود حد لهذا الانتظار وعدم مسح قائمة الانتظار، لا تُقرأ طلبات `RST STREAM` الصادرة عن العميل أبدًا، كما تمنع إطارات PING الدورية تشغيل مهلة القراءة على مستوى النقل. وهذا يسمح للمهاجم بتثبيت العمليات وحالة المكون الإضافي (Plug) والموارد المرتبطة بها، مثل الاتصالات الصاعدة المجمعة في مكون إضافي للوكيل العكسي (reverse-proxy Plug)، من خلال استهداف نقاط النهاية باستجابات أكبر من نافذة الاتصال والحفاظ على الاتصال باستخدام إشارات PING.

تسمح مشكلة تتعلق بعدم كفاءة التعقيد الخوارزمي بإحداث هجوم «رفض الخدمة» عن بُعد دون مصادقة، عن طريق استنزاف موارد وحدة المعالجة المركزية (CPU) أثناء إعادة تجميع أجزاء WebSocket. تقوم الدالة `oversize message?/2`، التي يتم استدعاؤها من `handle frame/3` في `lib/bandit/websocket/connection.ex`، بإلحاق إطارات الاستمرار غير النهائية بقائمة iolist متداخلة إلى اليسار، وإعادة قياس حجم المخزن المؤقت بالكامل باستخدام `IO.iodata length/1` لكل إطار. ويؤدي ذلك إلى عمل إعادة تجميع تربيعي (O(n^2)) بالنسبة لعدد إطارات الاستمرار. في حين أن الحد الأقصى `max fragmented message size` يقيد إجمالي البايتات، إلا أنه لا يحد من عدد الإطارات. يمكن للمهاجم إرسال العديد من إطارات الاستمرار الصغيرة لاستنزاف موارد وحدة المعالجة المركزية (CPU)، مما قد يؤدي إلى إعاقة عمل الخادم وحرمان المستخدمين الشرعيين من الخدمة. تؤثر هذه المشكلة بشكل خاص على التطبيقات التي تخدم نقاط نهاية WebSocket عبر Bandit، بما في ذلك تطبيقات Phoenix التي تستخدم Bandit كمحول HTTP.

يمكن لمهاجم عن بُعد غير مصدَّق أن يتسبب في حدوث هجوم «رفض الخدمة» (DoS) عن طريق استنفاد الذاكرة. تتجاهل الدالة `read data/2` الموجودة في `Elixir.Bandit.HTTP1.Socket` الخيار `:length` عند معالجة نصوص طلبات HTTP/1 المقسمة إلى أجزاء. وعلى وجه التحديد، تقوم الدالة `do read chunked data!/5` بتخزين كل جزء مستلم مؤقتًا في قائمة iolist دون تحديد الحد الأقصى المتراكم للنص وفقًا للحد المُعد مسبقًا، مما يؤدي إلى تحويل النص بأكمله إلى ملف ثنائي واحد. نظرًا لأن هذه العملية تحدث قبل التوجيه والمصادقة في نقاط النهاية القياسية لـ Phoenix، فإن إرسال طلب POST واحد مع رأس `Transfer-Encoding: chunked` ونص كبير الحجم بشكل تعسفي يمكن أن يستنفد ذاكرة عملية BEAM، مما يؤدي إلى إنهاء العملية بواسطة آلية Out-Of-Memory (OOM) في نظام التشغيل.

تسمح حلقة لا نهائية في الدالة `do read chunked data!/5` الموجودة في الملف `lib/bandit/http1/socket.ex` للمهاجمين عن بُعد غير المصادق عليهم بالتسبب في رفض الخدمة عن طريق استنفاد عمليات العمل. تحدث هذه المشكلة لأن الدالة لا تنتهي إلا عندما يتبع سطر «last-chunk» مباشرةً سطر ختامي فارغ، في حين أن RFC 9112 §7.1.2 يسمح بوجود صفر أو أكثر من الحقول الختامية. وعندما تكون الحقول الختامية موجودة، تدخل العملية في حالة تتكرر فيها بشكل متسلسل مع بقاء الحالة دون تغيير، مما يؤدي إلى تثبيت عملية العامل طوال مدة اتصال TCP. يمكن لعدد قليل من الطلبات المتزامنة المقسمة إلى أجزاء والمتوافقة مع RFC والتي تحتوي على حقول ختامية أن تستنفد مجموعة العمليات العاملة، مما يجعل الخادم غير مستجيب. يمكن أن يحدث هذا حتى مع حركة المرور المشروعة التي يتم توجيهها بواسطة بروكسيات مثل NGINX و HAProxy.

يمكن لمهاجم عن بُعد غير مصدَّق أن يتسبب في حدوث هجوم «رفض الخدمة» (DoS) عن طريق استنفاد الذاكرة عند تمكين ضغط WebSocket permessage-deflate. تحدث هذه المشكلة بسبب قيام الدالة `inflate/2` الموجودة في `Elixir. Bandit.WebSocket.PerMessageDeflate` تستدعي `:zlib.inflate/2` دون حد أقصى لحجم المخرجات، وتقوم بتحويل الحمولة غير المضغوطة إلى ملف ثنائي واحد باستخدام `IO.iodata to binary/1`. وعلى الرغم من أن `websocket options.max frame size` يحدد حجم الإطار المضغوط، إلا أنه لا يحدد حجم المخرجات غير المضغوطة. ونتيجة لذلك، يمكن للإطار المضغوط بنسبة عالية أن يفرض تخصيصات في الذاكرة المؤقتة (heap) بمقياس GiB، مما يستنفد ذاكرة عقدة BEAM ويؤدي إلى إنهاء العملية بسبب نفاد الذاكرة (OOM). وهذا يتطلب تمكين كل من الخيار `websocket options.compress` على مستوى الخادم وخيار `compress: true` لكل ترقية في `WebSockAdapter.upgrade/4`.