Marten-Seemann

يمكن للمهاجم إحداث تخصيص مفرط للذاكرة في تطبيقات عميل وخادم HTTP/3 عن طريق إرسال إطار HEADERS مشفر باستخدام QPACK. يتم فك تشفير هذا الإطار ليصبح قسم حقل تذيلي كبير يحتوي على العديد من أسماء الحقول الفريدة أو القيم الكبيرة. يقوم النظام بإنشاء `http.Header` لـ `http.Request` أو `http.Response`، لكنه يفرض قيودًا فقط على حجم إطار HEADERS المضغوط بدلاً من قسم الحقول الذي تم فك تشفيره. يسمح هذا التباين لإطار مصمم بشكل خبيث بالتوسع حتى 50 ضعف حجمه المشفر باستخدام إدخالات الجدول الثابت لـ QPACK، مما يؤدي إلى استنفاد الذاكرة وحالة رفض الخدمة (DoS).

يمكن للمهاجم التسبب في استهلاك غير محدود للذاكرة من خلال إنشاء وإغلاق العديد من تدفقات WebTransport بشكل متكرر. لم تكن التدفقات المغلقة تُزال من خريطة داخلية للجلسة، مما يمنع عملية التخلص من مواردها. يمكن لمهاجم خبيث استغلال هذه الثغرة عن طريق فتح وإغلاق عدد كبير من التدفقات، مما يؤدي إلى نمو مستمر في استهلاك الذاكرة يتناسب مع عدد التدفقات المغلقة. يحتفظ البرنامج بخريطة داخلية تتعقب تدفقات WebTransport، ولم تكن الإصدارات المتأثرة تزيل إدخالات التدفقات المغلقة من هذه الخريطة.

يمكن لزوج خبيث التسبب في رفض الخدمة في webtransport-go عن طريق منع أو تأخير إغلاق جلسة WebTransport إلى أجل غير مسمى. وعلى وجه التحديد، يمكن لمستخدمين أن يحتفظا برصيد التحكم في تدفق QUIC في تدفق CONNECT، مما يحجب إرسال كبسولة WT CLOSE SESSION ويؤدي إلى توقف عملية الإغلاق. يقوم بروتوكول WebTransport بالإشارة إلى إنهاء الجلسة عن طريق إرسال كبسولة WT CLOSE SESSION في تدفق CONNECT. وكانت الإصدارات المتأثرة تتعطل إلى أجل غير مسمى أثناء انتظار الحصول على رصيد كافٍ من التحكم في تدفق QUIC من الطرف المقابل.

تعد ميزة إدارة الجلسات في webtransport-go عرضة لاستهلاك مفرط للذاكرة. يمكن للمهاجم إرسال كبسولة `WT CLOSE SESSION` تحتوي على رسالة خطأ تطبيق كبيرة الحجم بشكل مفرط. لا يفرض التنفيذ الحد الأقصى البالغ 1024 بايت الذي يتطلبه المسودة في هذا الحقل، مما يسمح للمهاجم بإرسال حمولة رسالة كبيرة الحجم بشكل تعسفي يتم قراءتها بالكامل وتخزينها في الذاكرة. وهذا يسمح للمهاجم باستهلاك كمية تعسفية من الذاكرة، مما يتطلب إرسال الحمولة بالكامل لتحقيق استهلاك الذاكرة.

يمكن لعميل QUIC ضار استغلال منطق استعادة الفقدان لحزم استكشاف المسار في quic-go لإحداث إشارة إلى مؤشر فارغ. ويتم تحقيق ذلك عن طريق إرسال حزم QUIC صالحة من عناوين بعيدة مختلفة، مما يؤدي إلى تشغيل منطق التحقق من صحة المسار ويجعل الخادم يرسل حزم استكشاف المسار، يلي ذلك إرسال إقرارات الاستلام (ACKs) المصممة خصيصًا للحزم المستلمة من الخادم.

Name of the Vulnerable Software and Affected Versions: quic-go versions prior to 0.48.2 Description: An off-path attacker can inject an ICMP Packet Too Large packet, disrupting a QUIC connection by setting the MTU value to smaller than 1200 bytes. This can be done after the handshake completion, circumventing any TCP fallback. The attacker needs to know the client's IP and port tuple to mount an attack. Recommendations: For versions prior to 0.48.2, upgrade to version 0.48.2 to fix the vulnerability. As a temporary workaround, consider using `IP PMTUDISC PROBE` instead of `IP PMTUDISC DO` to disable the kernel's MTU tracking. Alternatively, use iptables to drop ICMP Unreachable packets to minimize the risk of exploitation.

The issue is related to the QUIC protocol implementation in quic-go, where an attacker can cause its peer to run out of memory by sending a large number of `NEW CONNECTION ID` frames that retire old connection IDs. The receiver is supposed to respond to each retirement frame with a `RETIRE CONNECTION ID` frame. However, the attacker can prevent the receiver from sending out these `RETIRE CONNECTION ID` frames by collapsing the peer's congestion window and manipulating the peer's RTT estimate.

The issue is related to unbounded storage of information related to connection ID retirement, which could lead to excessive resource consumption. Each QUIC connection possesses a set of connection Identifiers (IDs). Endpoints declare the number of active connection IDs they are willing to support using the `active connection id limit` transport parameter. The peer can create new IDs using a "NEW CONNECTION ID" frame but must stay within the active ID limit. This is done by retirement of old IDs, the endpoint sends "NEW CONNECTION ID" includes a value in the `retire prior to` field, which elicits a "RETIRE CONNECTION ID" frame as confirmation. An unauthenticated remote attacker can exploit the issue by sending "NEW CONNECTION ID" frames and manipulating the connection so that "RETIRE CONNECTION ID" frames can only be sent at a slower rate than they are received, leading to storage of information related to connection IDs in an unbounded queue.

An attacker can cause its peer to run out of memory by sending a large number of `PATH CHALLENGE` frames. The receiver is supposed to respond to each `PATH CHALLENGE` frame with a `PATH RESPONSE` frame. However, the attacker can prevent the receiver from sending out most of these `PATH RESPONSE` frames by collapsing the peer's congestion window and manipulating the peer's RTT estimate.

The issue is related to unbounded queuing of path validation messages, which could lead to excessive resource consumption. QUIC path validation requires that the recipient of a `PATH CHALLENGE` frame responds by sending a `PATH RESPONSE`. An unauthenticated remote attacker can exploit this by sending `PATH CHALLENGE` frames and manipulating the connection, such as restricting the peer's congestion window size, so that `PATH RESPONSE` frames can only be sent at a slower rate than they are received, leading to storage of path validation data in an unbounded queue.

The QUIC stack, as used by h2o, is susceptible to a state exhaustion attack. When h2o is serving HTTP/3, a remote attacker can exploit this vulnerability to progressively increase the memory retained by the QUIC stack. This can eventually cause h2o to abort due to memory exhaustion. HTTP/1 and HTTP/2 are not affected by this vulnerability as they do not use QUIC.

The issue arises from serializing an ACK frame after the CRYPTO frame, allowing a node to complete the handshake. This can trigger a nil pointer dereference when the node attempts to drop the Handshake packet number space, leading to a panic. An attacker can bring down a quic-go node with minimal effort by completing the QUIC handshake, which requires sending and receiving only a few packets.

A malicious actor can store an arbitrary amount of data in a remote node's memory by sending the node a message with a signed peer record. This memory does not get garbage collected, and so the victim can run out of memory and crash. If users of go-libp2p in production are not monitoring memory consumption over time, it could be a silent attack, where the attacker could bring down nodes over a period of time, depending on the node resources. For example, a go-libp2p node on a virtual server with 4 GB of memory can be brought down in about 90 seconds.

A malicious peer can use large RSA keys to run a resource exhaustion attack and force a node to spend time doing signature verification of the large key. This issue is present in the core/crypto module of go-libp2p and can occur during the Noise handshake and the libp2p x509 extension verification step. To prevent this attack, go-libp2p now restricts RSA keys to <= 8192 bits.