Paulo Valente

يمكن لمهاجم غير مصرح له أن يتسبب في استنفاد الذاكرة وتعطل العقدة عن طريق إرسال جسم طلب كبير الحجم عبر تدفق العميل (client-streaming) أو التدفق ثنائي الاتجاه (bidirectional-streaming). تحدث هذه المشكلة لأن مسار قراءة التدفق في `Elixir.GRPC.Server.Adapters.Cowboy.Handler`:info/3 لا يفرض حد `max body size` الأقصى، على عكس مسار القراءة الأحادية (unary read path). وبشكل محدد، تقوم الدالة `Elixir.GRPC.Server.Adapters.Cowboy`:reading stream/1 بإضافة كل جزء مستلم إلى ذاكرة مؤقتة (buffer) حتى تكتمل الرسالة المحددة مسبقاً بطولها. ومن خلال التصريح عن رسالة كبيرة جداً وإرسالها عبر العديد من إطارات بيانات HTTP/2 الصغيرة، يمكن للمهاجم إجبار الذاكرة المؤقتة على النمو بلا حدود، مما يؤدي إلى استنفاد ذاكرة BEAM وتعطل العقدة بالكامل.

يمكن للمهاجمين المصادق عليهم الوصول إلى الموارد الخاصة بمستخدمين آخرين أو تعديلها عن طريق تهريب قيمة متعارضة لأي حقل مرتبط بمسار عبر سلسلة الاستعلام أو نص الطلب. يحدث هذا في الدالة `map request/5` داخل `Elixir.GRPC.Server.Transcode` (lib/grpc/server/transcode.ex)، حيث يتم استخدام `Map.merge/2` مع ربط المسار كحجة أولى، مما يمنحها أولوية دمج أدنى. ونتيجة لذلك، يؤدي طلب مثل «GET /users/me/profile?user id=victim» أو طلب POST يحتوي على `user id` في نص الطلب إلى بنية protobuf تم فك تشفيرها، حيث يتم استبدال الحقل المرتبط بالمسار بالقيمة التي يقدمها المهاجم. وهذا يسمح بتجاوز المعالجات التي تستخدم هذه الحقول للتوثيق، أو التحقق من الملكية، أو تحديد نطاق الاستخدام المتعدد. تتطلب هذه المشكلة تمكين تحويل الترميز من HTTP إلى gRPC.

يمكن للمهاجمين غير المصادق عليهم استنفاد ذاكرة BEAM وتعطيل الخادم عن طريق بث نص طلب أحادي كبير الحجم أو بطيء التدفق. تقوم الدالة `read full body/3` الموجودة في ’Elixir.GRPC.Server.Adapters.Cowboy.Handler‘ بتجميع كل جزء مستلم في ملف ثنائي واحد متزايد الحجم دون حد أقصى للحجم. علاوة على ذلك، إذا أغفل العميل رأس `grpc-timeout`، يتم تعيين مهلة القراءة لكل جزء إلى ما لا نهاية، مما يمكّن العميل الذي يرسل البيانات ببطء شديد من الحفاظ على الاتصال إلى أجل غير مسمى بينما يزداد استهلاك الذاكرة. يكفي اتصال واحد لاستنفاد ذاكرة الخادم وتعطيل العقدة.

يؤدي التعامل غير السليم مع البيانات شديدة الضغط في وحدتي `GRPC.Compressor.Gzip` و`GRPC.Message` إلى إمكانية إحداث هجوم رفض الخدمة عبر قنبلة فك ضغط gzip. تستدعي الدالة `decompress/1` في `Elixir.GRPC.Compressor.Gzip` الدالة `:zlib.gunzip/1` على بايتات يتحكم فيها المهاجم دون حد لحجم البيانات بعد فك الضغط، أو فحص النسبة، أو فك التشفير التدريجي. يحدث هذا تلقائيًا عندما يحتوي إطار gRPC وارد على رأس `grpc-encoding: gzip`. وبما أن `:zlib.gunzip/1` تخصص النتيجة الكاملة بعد فك الضغط كملف ثنائي واحد، فإن حمولة صغيرة قابلة للضغط بدرجة عالية يمكن أن تتوسع إلى عدة غيغابايت، مما يستنفد كومة الذاكرة (heap) لعقدة BEAM ويؤدي إلى إنهاء العملية بسبب نفاد الذاكرة. الحد `max receive message length` غير فعال لأنه لا يُفرض إلا بعد فك الضغط. ويمكن استغلال هذه الثغرة من قبل نظير بعيد غير مصدق عليه باستخدام الدالة `from data/2` في `Elixir.GRPC.Message`.

يؤدي فك تسلسل البيانات غير الموثوق بها وتخصيص الموارد دون قيود أو تحديد للسعة إلى تمكين المهاجمين غير المصادق عليهم من إحداث تعطل في عقدة BEAM أو تنفيذ تعليمات برمجية عن بُعد على الخادم. تستدعي الدالة `decode/2` الموجودة في `Elixir.GRPC.Codec.Erlpack` الدالة `:erlang.binary to term/1` على نص رسالة gRPC الخام دون خيار `:safe` أو حدود الحجم أو حراس الأنواع. يمكن لأي نظير غير مصدق عليه يرسل طلبًا بـ `Content-Type: application/grpc+erlpack` تقديم حمولة مصممة خصيصًا لإنشاء ذرات جديدة عشوائية، والتي لا يتم جمعها كقمامة، مما يؤدي إلى استنفاد جدول الذرات وتعطل آلة افتراضية (VM). بالإضافة إلى ذلك، يمكن للحمولة ترميز مصطلح fun الذي ينفذ كودًا يتحكم فيه المهاجم إذا تم تطبيقه في المراحل اللاحقة. تحدث هذه المشكلة عندما يتم تسجيل `GRPC.Codec.Erlpack` صراحةً كبرنامج ترميز على خادم gRPC.