Chrisvest

يفشل مكون `NoQuicTokenHandler` في التحقق من صحة الرموز بشكل صحيح عندما لا يتم تعيين معالج رموز محدد من قبل التطبيق. على وجه التحديد، تُرجع الدالة `validateToken()` القيمة 0 دون قيد أو شرط، والتي تفسرها الدالة `QuicheQuicServerCodec.handlePacket()` على أنها رمز صالح. وهذا يسمح للمهاجم بتزوير عنوان IP المصدر للضحية وإدراج أي بايتات رموز غير فارغة في حزمة أولية. ونتيجة لذلك، يعامل الخادم عنوان الضحية على أنه تم التحقق من صحته، متجاوزًا حد الإرسال المضاد للتضخيم البالغ 3x المحدد في RFC 9000 §8.1. وهذا يمكّن الخادم من عكس عمليات مصافحة كاملة الحجم، مثل الشهادات، نحو الضحية دون قيود التضخيم القياسية.

يسمح ثغرة في مكون netty-codec-haproxy التابع لإطار عمل تطبيقات الشبكة Netty لمهاجم عن بُعد بالتسبب في حالة رفض الخدمة (DoS). عند إرسال رسالة HAProxy مصممة خصيصًا تحتوي على رأس TLV (Type-Length-Value) PP2 TYPE SSL غير صحيح، حيث يتم تعيين الطول على أقل من 5، فإن الدالة `readNextTLV()` في `HAProxyMessage` تُحدث استثناءً من نوع IndexOutOfBoundsException. ونظرًا لأن `HAProxyMessageDecoder` لا يلتقط سوى استثناء `HAProxyProtocolException`، فإن هذا الاستثناء ينتشر، مما يمنع تحرير الذاكرة المحتجزة في مخزن التراكم المشترك ويؤدي إلى تسرب في الذاكرة.

توجد مشكلة في تخصيص الذاكرة غير الخاضع للرقابة في الدالة `SslClientHelloHandler.decode()`. عندما لا يتسع سجل ClientHello في السجل الأول، يقوم النظام بتخصيص الذاكرة بشكل متسرع باستخدام `ctx.alloc().buffer(handshakeLength)` استنادًا إلى طول مصافحة TLS البالغ 24 بت. ونظرًا لأن `SniHandler` و`AbstractSniHandler` والمُنشِئات ذات الصلة غالبًا ما تُعيّن `maxClientHelloLength` و`handshakeTimeoutMillis` على القيمة 0، يتم تعطيل حارس الطول ولا يتم جدولة أي مهلة. ونتيجة لذلك، فإن أي طلب بحجم 16 ميغابايت أو أكبر يتجاوز حجم القطعة المجمعة الافتراضي، مما يؤدي إلى تخصيص فوري ضخم أو غير مجمّع يتم الاحتفاظ به حتى إغلاق القناة.

يحدث تسرب لمؤشر الملف في الدالة `netty unix socket recvFd` عندما يرسل نظير مؤشرين للملف في آن واحد عبر رسالة تحكم SCM RIGHTS. يقوم النظام بتخصيص مخزن مؤقت للتحكم سعة 24 بايت على نظام Linux 64 بت، وهو ما يتناسب تمامًا مع رسالة تحكم تحتوي على عددين صحيحين. ونظرًا لأن النواة تقوم بتثبيت كلا الوصفين دون تشغيل علامة `MSG CTRUNC`، فإن فحص الطول اللاحق `cmsg->cmsg len == CMSG LEN(sizeof(int))` يفشل لأنه يتوقع 20 بايت. يؤدي هذا إلى تخطي التطبيق للمنطق الذي يقرأ الوصف، وفشله في إغلاق الوصفات المثبتة. ثم تخرج العملية من حلقة القراءة بشكل طبيعي، مما يؤدي إلى تسرب وصفين للملفات لكل رسالة. يمكن الوصول إلى هذه المشكلة عبر `Epoll`/`KQueue` `DomainSocketChannel` عندما يتم تكوين التطبيق باستخدام `DomainSocketReadMode.FILE DESCRIPTORS`.

يمكن لمهاجم عن بُعد التسبب في هجوم «رفض الخدمة» (DoS) عن طريق إرسال أجزاء من رسائل بروتوكول نقل التحكم في التدفق (SCTP) تم التلاعب بها بشكل خاص وغير مكتملة. تحدث المشكلة لأن المعالج يستخدم `fragments.put(streamId, Unpooled.wrappedBuffer(frag, byteBuf))` لكل جزء غير مكتمل، مما يؤدي إلى إنشاء CompositeByteBuf جديد يضم المجمع السابق. ينتج عن ذلك سلسلة من المركبات ذات N مستويات من العمق، حيث تتكرر استدعاءات `readableBytes()` أو `getBytes()` عبر N مستويات. ونظرًا لعدم وجود حدود لعدد الأجزاء أو إجمالي البايتات أو عدد إدخالات `streamId` التي يمكن للمهاجم فتحها، فإن أي نظير لا يقوم أبدًا بتعيين العلامة `complete` قد يتسبب في نمو غير محدود للذاكرة واستهلاك مفرط لموارد النظام.

في إطار عمل تطبيقات الشبكة، يقوم `DefaultHttp2Connection.DefaultEndpoint` بتهيئة `maxActiveStreams` و`maxStreams` إلى `Integer.MAX VALUE`، في حين أن `Http2Settings` لا يقوم بإدراج `SETTINGS MAX CONCURRENT STREAMS` بشكل افتراضي. إذا لم يستدعِ التطبيق صراحةً `initialSettings().maxConcurrentStreams(n)`، فإن خادم HTTP/2 لا يعلن عن أي حد للتدفقات المتزامنة ولا يفرضه. وهذا يسمح لاتصال TCP واحد بإنشاء مئات الآلاف من كائنات التدفق طويلة العمر، حيث يخصص كل تدفق مفتوح كائن `DefaultStream`، وفتحات `PropertyMap`، وحالة وحدة التحكم في التدفق، وإدخالًا في `IntObjectHashMap`. كما يتيح هذا الوضع تضخيم هجمات «Rapid-Reset»، حيث يؤدي عدم وجود حد أدنى للتدفقات المتزامنة إلى زيادة عبء العمل على الخلفية.

يتسبب معالج RedisArrayAggregator في تسرب دائم لمخازن الذاكرة المباشرة المجمعة عندما يُغلق اتصال خط أنابيب Redis قبل اكتمال تجميع مصفوفة RESP. يحتفظ المعالج بالرسائل الفرعية في حقل `depths`، لكنه يفتقر إلى طرق `channelInactive` أو `handlerRemoved` أو `exceptionCaught` لتحريرها أثناء تفكيك خط الأنابيب. ونظرًا لأن المخازن المؤقتة المتسربة هي شرائح من كتل `PooledByteBufAllocator`، فإنها تمنع هذه الكتل من العودة إلى تجمع الذاكرة المباشرة على مستوى JVM. يؤدي التغيير المستمر للاتصال من قبل نظير الشبكة إلى استنزاف هذا المجمع المشترك، مما يؤدي إلى فشل التخصيص عبر جميع قنوات Netty في العملية.

تدير فئة `DelegatingDecompressorFrameListener` عملية فك ضغط HTTP/2 باستخدام `EmbeddedChannel` لكل دفق لتشغيل برامج فك الضغط مثل gzip أو deflate أو zstd. يتم التعامل مع الأجزاء التي تم فك ضغطها ككائنات `ByteBuf` مجمعة ويتم تمريرها إلى معالج ذيل مجهول من نوع `ChannelInboundHandlerAdapter` مسؤول عن تحريرها. يمكن لنظير بعيد إرسال إطارات مصممة خصيصًا تتسبب في قيام وحدة التحكم في التدفق بإلقاء استثناء، مما يؤدي إلى حدوث تسرب في الموارد. قد يؤدي هذا التسرب إلى حدوث خطأ OutOfMemoryError (OOME)، مما قد يتسبب في تعطل آلة Java الافتراضية (JVM).

يتسبب برنامج الترميز HAProxy PROXY protocol v2 في تسرب الذاكرة الأصلية أو ذاكرة الكومة عند كل اتصال عندما يرسل العميل رأسًا صحيحًا من الناحية النحوية يحتوي على سجلات TLV (سجلات النوع والطول والقيمة) `PP2 TYPE SSL` متداخلة بعمق اثنين أو أكثر. يحدث هذا أثناء مسار التحليل الناجح حيث يظل مخزن التراكم الأساسي، وهو `ByteBuf` مجمّع وربما مباشر تم تخصيصه بواسطة القناة، مثبتًا بشكل دائم حتى بعد تحرير `HAProxyMessage` وإزالة وحدة فك التشفير لنفسها.

Netty هو إطار عمل لتطبيقات الشبكات يُستخدم لتطوير خوادم وعملاء البروتوكولات. تقوم الدالة `SimpleTrustManagerFactory.engineGetTrustManagers()` والمسارات ذات الصلة بتغليف X509TrustManager العادي الذي يقدمه المستخدم في X509TrustManagerWrapper. يُوسّع هذا الغلاف `X509ExtendedTrustManager`، لكنه يُنفّذ الدالة ذات المعلمات الثلاثة `checkServerTrusted(chain, authType, SSLEngine)` عن طريق تجاهل `SSLEngine` واستدعاء الدالة المفوضة ذات المعلمتين. ونظرًا لأن الكائن يتم تعريفه على أنه `X509ExtendedTrustManager`، فإن الأغلفة الداخلية من SunJSSE أو Netty لا تعيد تغليفه لإضافة تعريف نقطة النهاية. ينتج عن ذلك فشل في إجراء التحقق من اسم المضيف عندما يتم إنشاء عميل باستخدام `SslContextBuilder.forClient().trustManager(somePlainX509TrustManager)`، حتى لو تم تعيين `endpointIdentificationAlgorithm` على ”HTTPS“ افتراضيًا، مما قد يتيح هجمات «الرجل في الوسط».

قبل قراءة سطر الطلب الأول، تتخطى دالة `HttpObjectDecoder` بصمت جميع المسافات البيضاء وكل بايت يكون فيه `Character.isISOControl(b)` صحيحًا (0x00–0x1F و0x7F). يخالف هذا السلوك ما ورد في RFC 9112 §2.2، الذي يسمح للخوادم فقط بتجاهل الأسطر الفارغة التي تحتوي على CRLF (نهاية السطر + عودة السطر) التي تسبق سطر الطلب لمعالجة حلول بديلة لـ HTTP/1.0 POST. ومن خلال استيعاب أحرف التحكم غير CRLF مثل NUL وSOH وSTX، يمكن استغلال البرنامج لإحداث تشويش في حدود الطلب في عمليات النقل المتسلسلة أو المتعددة. يحدث هذا عندما يعامل مكون الواجهة الأمامية، مثل موزع الحمل أو محطة TLS، هذه البايتات بطريقة مختلفة عن Netty، مما قد يؤدي إلى عدم تزامن الطلبات أو هجمات التهريب.

تتعلق المشكلة بقراءة غير آمنة لملفات البيئة، مما قد يؤدي إلى حدوث هجوم «رفض الخدمة» في Netty. عند تحميل Netty على تطبيق يعمل بنظام Windows، يحاول Netty تحميل ملف غير موجود. إذا أنشأ المهاجم ملفًا كبير الحجم، فقد يتعطل تطبيق Netty. تم الإبلاغ عن مشكلة مماثلة سابقًا، لكن الإصلاح كان غير مكتمل، حيث لم يتم احتساب البايتات الفارغة ضمن حد الإدخال. ترتبط هذه الثغرة الأمنية بوظيفة `BufferedReader.readLine()` و`InputStreamReader`، اللتين يمكن أن تملآ مخزن السطر المؤقت بأحرف بديلة عند مواجهة بايتات فارغة.