Stefan Eissing

عند استخدام بيانات اعتماد المستخدم المحيطة، قد يتم إرسال طلب HTTP موجه إلى أصل معين عبر اتصال تم مصادقته مسبقًا عبر Negotiate لأصل مختلف، مما يترك بيانات الاعتماد المخصصة للطلب غير مستخدمة.

عند بنائه باستخدام wolfSSL، قد يقوم curl بالتحقق بشكل خاطئ من بصمة مفتاح عام مثبت (pinned) مقابل مفتاح لا يمتلكه نظير TLS. يحدث هذا أثناء مصافحة TLS عندما يقوم wolfSSL بالتحقق من الاتصال، ولكن يقوم curl لاحقاً بإعادة تحليل الشهادة نفسها. يمكن أن يؤدي التلاعب بحقل طول الصلاحية إلى خداع curl لاستخراج ومطابقة مفتاح مدمج مختلف، مما يؤدي إلى تفويض خاطئ للمفتاح العام المثبت.

يمكن لعملية نقل `ftp://` المهيأة باستخدام `CURLUSESSL NONE` إعادة استخدام اتصال تحكم FTP مجمع تم ترقيته مسبقًا باستخدام `STARTTLS` والمصادقة عليه باستخدام شهادة عميل. نظرًا لأن المقبض الثاني لا يقوم بإجراء مصافحة TLS جديدة أو تسجيل دخول FTP جديد، يستمر الخادم في تفويضه بموجب هوية شهادة المقبض الأول.

يؤدي تفعيل `CURLOPT CRLF` إلى إمكانية حقن الأوامر أثناء عمليات IMAP APPEND. عند نقل البيانات الموسعة لنهاية السطر، يقوم curl بالإعلان عن عدد بايتات الإدخال الخام في literal `IMAP APPEND {N}`. وبما أن الخادم يقرأ $N$ بايت فقط للحمولة، يتم تفسير وتنفيذ بايتات التجاوز المتبقية كأوامر IMAP pipelined ضمن الجلسة المصادق عليها.

توجد مشكلة حيث لا تتضمن مفتاح إعادة استخدام الاتصال الربط عندما يتم تعيين `CURLOPT INTERFACE` (أو خيار سطر الأوامر `--interface`) باستخدام أحد البادئات الموثقة مثل `if!` أو `host!` أو `ifhost!`. يسمح هذا لعملية نقل لاحقة تطلب مصدراً مختلفاً بإعادة استخدام اتصال موجود بصمت، مما يؤدي إلى خروج البيانات من عنوان مصدر عملية النقل السابقة.

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

عند بناء curl باستخدام GnuTLS، يمكن لخادم WebSocket خبيث أن يجعل curl يرسل ذاكرة تتجاوز ذاكرة التخزين المؤقت للإرسال. يحدث هذا بسبب قراءة خارج الحدود تلي إرجاع الدالة `gnutls record send()` لعدد من البايتات المرسلة أكبر من عدد البايتات التي طُلب منها إرسالها، وذلك بعد عملية إرسال محجوبة.

عند استخدام مستخدم محيطي (ambient user) في عملية نقل أولى باستخدام مصادقة Negotiate، قد يقوم curl بتمرير تفاصيل الاعتماد إلى أصل ثانٍ غير ذي صلة عند توجيهه لإعادة التوجيه إلى هناك.

يمكن لبروكسي HTTP خداع libcurl لإرسال بيانات اعتماد الأصل، مثل كلمات مرور Basic أو تذاكر Negotiate/Kerberos، مباشرة إلى البروكسي نفسه. يحدث هذا عندما يستجيب البروكسي لطلب نفق `CONNECT` بحالة 401 `WWW-Authenticate:` بدلاً من حالة 407 `Proxy-Authenticate:` المتوقعة.

توجد مشكلة فساد في الذاكرة من نوع use-after-free أثناء عمليات رفع البيانات عبر بروتوكول HTTP/2. تحدث هذه الثغرة عندما يتعامل curl بشكل خاطئ مع استجابة `RST STREAM` الخاصة بـ HTTP/2 المستلمة من الخادم مع السبب `HTTP 1 1 REQUIRED` أو `REFUSED STREAM` مما يؤدي إلى استخدام كائن `struct Curl easy` بعد تحريره من الذاكرة. يمكن للمهاجم عن بُعد الذي يتحكم في خادم خبيث استغلال ذلك للتسبب في تعطل العميل أو، في ظل ظروف محددة للغاية تتطلب معرفة دقيقة ببنية الهدف وتخطيط الذاكرة وتكوين TLS، تنفيذ رمز برمجي عن بُعد.

When using the wolfSSL backend with CA caching enabled, a flaw exists where the `CURLOPT SSL CTX FUNCTION` callback can be overridden. If this callback replaces the trust store, libcurl may silently reinstall the cached store after the callback returns. This results in a scenario where a certificate trusted by the cached store is incorrectly accepted, even if it was rejected by the store selected via the callback.

A flaw exists where the software incorrectly reuses an HTTP connection setup for a specific hostname when using Negotiate authentication, specifically when the initial request is made with empty credentials. This behavior can lead to a situation where a request from one user is transmitted over a connection previously authenticated by another user.

يسمح خطأ منطقي في آلية تجميع الاتصالات للبرنامج بإعادة استخدام اتصال غير صحيح للطلبات التي تتم مصادقتها عبر بروتوكول Negotiate. ويحدث هذا حتى عندما تكون الطلبات مكونة لاستخدام خدمات مختلفة، مما قد يؤدي إلى إرسال طلب عبر اتصال تمت مصادقته لخدمة مختلفة على نفس الخادم.

توجد مشكلة قد تؤدي إلى قيام libcurl بإرسال بيانات الطلب عبر اتصال جديد قبل فرض فشل التحقق من الشهادة. ويحدث هذا عندما يتصل المستخدم أولاً بخادم HTTP/3 شرعي، ثم يتصل لاحقًا بجهاز مزيف تابع للمهاجم يفتقر إلى شهادة صالحة. قد يحدث تسرب للمعلومات الحساسة في حالة استخدام جلسة SSL مخزنة مؤقتًا (عندما يكون `CURLOPT SSL SESSIONID CACHE` ممكّنًا) وعندما تكون ميزة البيانات المبكرة نشطة (عندما يتم تعيين بت `CURLSSLOPT EARLYDATA` في `CURLOPT SSL OPTIONS`).

عند تهيئة البرنامج لاستخدام ملف `.netrc` لتخزين بيانات الاعتماد مع تحديد عنوان URL يحتوي على اسم مستخدم دون كلمة مرور في الوقت نفسه (على سبيل المثال، `https://user@example.com/`)، قد يقوم البرنامج باسترداد واستخدام كلمة مرور مستخدم آخر محدد في ملف `.netrc` الخاص بذلك المضيف بشكل غير صحيح، شريطة عدم وجود تطابق للمستخدم المحدد.

يوجد عيب يتمثل في أن عملية نقل جديدة تستخدم بروتوكول STARTTLS لترقية الاتصال قد تعيد استخدام اتصال نشط قائم بشكل غير صحيح، على الرغم من عدم تطابق إعدادات TLS.

يحتوي مكون WebSocket في مكتبة libcurl على مشكلة في تخصيص الموارد. بشكل افتراضي، يستجيب curl تلقائيًا لإطارات PING الخاصة بـ WebSocket. ونظرًا لعدم وجود حد أقصى لتخصيص الذاكرة للإطارات غير المؤكدة في البرنامج، يمكن لمهاجم عن بُعد يتصرف كخادم ضار استنفاد كل الذاكرة المتاحة عن طريق إغراق العميل برسائل PING متتالية وسريعة، مما يؤدي إلى حدوث هجوم رفض الخدمة.

تسمح مشكلة في وظيفة استقبال QUIC عبر بروتوكول UDP لخادم HTTP/3 ضار عن بُعد بالتسبب في هجوم «رفض الخدمة». تفشل وظيفة المساعدة في احتساب حزم بيانات UDP ذات الطول الصفري ضمن مخصصات الحزم لكل مكالمة قبل التخلص منها، مما يمكّن نظير QUIC متصل من بث حزم بيانات فارغة وتعطيل العميل إلى أجل غير مسمى.

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

توجد مشكلة ”استخدام بعد التحرير“ (use-after-free) في libcurl تتعلق بإدارة شجرة التبعية لتيار HTTP/2. تحدث هذه المشكلة عندما يقوم أحد التطبيقات بتكوين الشجرة باستخدام `CURLOPT STREAM DEPENDS` أو `CURLOPT STREAM DEPENDS E`، ثم يستدعي الدالة `curl easy reset()`، ثم ينهي المقبض عبر الدالة `curl easy cleanup()`. أثناء عملية التنظيف النهائية، تحاول المكتبة الوصول إلى بنية داخلية وتعديلها، وهي بنية تم تحريرها بالفعل أثناء عملية إعادة الضبط. قد تسمح هذه الثغرة لمهاجم عن بُعد بالتسبب في رفض الخدمة.