0xmrma/cve-2026-33936ثغرة حجب الخدمة في ecdsa (PyPI)
ثغرة رفض الخدمة في ecdsa (PyPI)
حددتُ وكشفتُ بشكل مسؤول عن ثغرة بمستوى متوسط الخطورة في python-ecdsa، وهي مكتبة تشفير Python تُستخدم على نطاق واسع، وقد حققت 47.8 مليون عملية تنزيل في الشهر الماضي.
وجدت هذه المشكلة أثناء مراجعة python-ecdsa ومعي سؤال محدد جدًا في ذهني:
ماذا يحدث إذا ادّعى ترميز DER تالف كذبًا بشأن طوله ووثق به المحلل أكثر مما ينبغي؟
في هذه الحالة، قادني هذا السؤال إلى خلل حقيقي.
قبلت أدوات تحليل DER المساعدة في ecdsa.der بيانات مبتورة في الحالات التي ادّعى فيها الطول المشفّر وجود بايتات أكثر مما هو موجود فعلًا. كان يجب رفض هذا الإدخال التالف فورًا. وبدلًا من ذلك، كان بإمكانه التسلل أعمق إلى منطق التحليل وإطلاق IndexError داخلي في النهاية أثناء تحليل المفاتيح.
أصبحت هذه المشكلة CVE-2026-33936.
المشروع: python-ecdsa على GitHub
الحزمة: ecdsa (pip)
CVE: CVE-2026-33936
attacker-controlled malformed DER → truncated length accepted as valid → parser continues past trust boundary → SigningKey.from_der() reaches internal exception path → unexpected IndexError / application-level DoS risk
python-ecdsa هي مكتبة Python تُستخدم على نطاق واسع للتشفير بالمنحنيات الإهليلجية.
من بين أمور أخرى، تعالج:
وهذا يعني أن كود التحليل لديها يقع مباشرة على حدود أمنية.
كلما قبِلت مكتبة ما مواد مفاتيح مقدمة من الخارج أو مدخلات ثنائية منظمة، فإن الصحة ليست مجرد مسألة جودة. إنها خاصية أمنية.
إذا قُبل إدخال تالف بينما كان يجب رفضه، يبدأ الكود اللاحق في بناء افتراضات فوق حالة غير صالحة.
هنا تتوقف الأخطاء عن كونها «مجرد أخطاء تحليل» وتبدأ في التحول إلى ثغرات.
تحليل DER هو أحد تلك المجالات التي يمكن أن يكون لأخطاء التحقق الصغيرة فيها تأثيرات غير متناسبة.
فئة هذا الخلل واضحة ومباشرة:
هذا بالضبط نوع فشل الحدود الذي يستحق الفحص في المراجعة الأمنية.
لم أكن أبحث عن سلوك تشفيري غريب هنا. كنت أبحث عن إخفاقات الثقة في معالجة المدخلات المنظمة.
وكان ذلك هو المكان الصحيح للبحث.
كانت المشكلة الجذرية هي التحقق غير السليم من حقول طول DER عند تحليل إدخال تالف أو مبتور.
تحديدًا، قبِلت ecdsa.der.remove_octet_string() إدخالًا تجاوز فيه طول DER المُعلَن عدد البايتات المتاحة فعلًا في المخزن.
لذا بدلًا من رفض DER التالف مثل هذا:
40963قبِلت الأداة المساعدة ذلك وأعادت المحتوى المبتور كما لو كان صالحًا.
هذا بالفعل خلل.
لكن التأثير الأقوى ظهر في المراحل اللاحقة.
ولأن الإدخال التالف قُبل بدلًا من رفضه عند الحدود، فقد يصل SigningKey.from_der() لاحقًا إلى مسار استثناء داخلي ويُطلق:
IndexError: index out of bounds on dimension 1
هذا مهم لأن هذا ليس نوع الفشل الذي يتوقعه المستدعي من إدخال تالف. السلوك الصحيح هو رفض تحليل نظيف مثل UnexpectedDER أو ValueError.
إذن لم تكن الثغرة هي «وجود IndexError» بمعزل عن غيره.
كانت الثغرة الحقيقية هي:
هذه سلسلة خلل واحدة، وليست مشكلتين مستقلتين.
رفض المحلل لإدخال تالف ليس تحسينًا تجميليًا. إنه جزء من النموذج الأمني.
التمييز المهم هنا ليس ما إذا كان الإدخال غير صالح. بالطبع كان غير صالح.
التمييز المهم هو كيف تصرفت المكتبة في مواجهة الإدخال غير الصالح.
هناك فرق حقيقي بين:
الأول سلوك متين.
الثاني يُنشئ خطرًا على مستوى التطبيق إذا كان البرنامج يحلل DER غير موثوق ويفترض أن إخفاقات المكتبة تبقى ضمن أنواع الاستثناءات المتوقعة.
لهذا صُنّفت هذه بشكل صحيح كثغرة وليست مجرد خلل في جودة المحلل.
استخدمت إثباتَي مفهوم (PoC) لأنهما أظهرا جزأين مختلفين من سلسلة الخلل نفسها.
أظهر إثبات المفهوم الأول أن remove_octet_string() قبِلت DER مبتورًا يتجاوز طوله المُعلَن المخزن المتاح.
وهذا أثبت فشل التحقق الأساسي:
أظهر إثبات المفهوم الثاني التأثير اللاحق الأكثر أهمية: DER التالف المُمرَّر إلى SigningKey.from_der() كان يُطلق بشكل حتمي IndexError داخليًا قبل الإصلاح.
وهذا أثبت التأثير المرتبط بالأمن:
هذه نتيجة أقوى بكثير من «المحلل قبِل بايتات غريبة».
إنها تُظهر فشل الحدود بالإضافة إلى عواقب تشغيلية حقيقية.
يُثبت إثبات المفهوم الأول السبب الجذري.
ويُثبت إثبات المفهوم الثاني التأثير.
هذا التقسيم مهم.
كثير من التقارير تتوقف عند:
«هذا المحلل يقبل بيانات تالفة».
هذا مفيد، لكنه ليس دائمًا كافيًا لإظهار سبب أهمية الخلل.
في هذه الحالة، كان التقرير الأقوى هو:
وهذا يجعل القصة الأمنية أوضح بكثير.
كان الإصلاح بسيطًا وصحيحًا.
أضاف التصحيح قاعدة الأمان المفقودة نفسها المستخدمة بالفعل في remove_sequence():
يجب أن يتسع الطول المُعلَن ضمن المخزن المتاح
طُبّق هذا الفحص على:
remove_constructed()remove_implicit()remove_octet_string()وبمجرد إضافة فحوصات الحدود هذه، أصبح DER التالف/المبتور يُرفض فورًا بـ:
UnexpectedDER: Length longer than the provided buffer
ولم يعد إثبات المفهوم الذي كان يُطلق IndexError سابقًا يصل إلى مسار الاستثناء الداخلي. لقد فشل بنظافة أثناء التحليل، وهو بالضبط ما كان يجب أن يحدث منذ البداية.
هذا هو نوع الإصلاح الذي تريد رؤيته في ثغرة محلل:
لا إعادة تصميم. لا غموض. فقط تحقق صحيح حيث كان مفقودًا.
أضفتُ أيضًا اختبارات انحدار مركّزة للتأكد من بقاء هذه الفئة بالضبط من DER التالف مرفوضة.
تغطي الاختبارات الجديدة رفض الطول المبتور لكل من:
remove_octet_stringremove_constructedremove_implicitكان ذلك مهمًا لأن الخلل لم يكن يتعلق بمسار تشغيل غريب واحد. بل كان يتعلق بقاعدة تحقق كان يجب أن تصمد باستمرار عبر أدوات DER المساعدة المرتبطة.
بعد إضافة الإصلاح والاختبارات، اجتازت المجموعة الكاملة الاختبارات محليًا:
python -m pytest -q
# 2018 passed, 5 skipped
هذا مهم في أعمال الإفصاح الحقيقية.
يكون الإصلاح أقوى بكثير عندما يأتي مع اختبارات تُحكم قبضتها على الحدود.
صُنّفت هذه المشكلة بشكل معقول على أنها متوسطة.
التأثير الرئيسي هنا هو التوافر/المتانة، وليس السرية أو السلامة.
كان تصنيف النشرة الأمنية:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Lهذا منطقي.
الادعاء ليس أن DER التالف يسمح للمهاجم بتنفيذ كود. الادعاء هو أن DER التالف قد يُطلق استثناءات داخلية غير متوقعة في البرمجيات التي تحلل مواد DER غير موثوقة باستخدام هذه المكتبة.
هذا خلل تحليل حقيقي وقابل للدفاع عنه بأسلوب رفض الخدمة (DoS).
أُبلغ عن هذه المشكلة بشكل خاص عبر GitHub Security Advisories.
تضمن التقرير:
IndexError في المراحل اللاحقةتحقق المُطوِّر الرئيسي من المشكلة، وطلب أن يُدمج الإصلاح مع اختبارات وحدة، وتقدّم الإصلاح المنسّق عبر سير عمل الفرع الخاص المؤقت في GHSA.
أثناء معالجة CVE، رفض GitHub في البداية تعيين المعرف لأن نص النشرة بدا وكأنه قد يصف أكثر من ثغرة واحدة.
كان التوضيح بسيطًا:
هذه كانت ثغرة واحدة ذات سبب جذري واحد — تحقق غير سليم من طول DER — وكانت IndexError الناتجة عن SigningKey.from_der() نتيجة لاحقة لنفس قبول الإدخال التالف، وليست مشكلة منفصلة قابلة للإصلاح بشكل مستقل.
كان هذا التوضيح كافيًا، وعُيّن للمشكلة المعرف:
CVE-2026-33936
الدرس هنا ليس «DER معقّد».
الجميع يعرف مسبقًا أن DER معقّد.
الدرس الحقيقي هو:
يجب رفض الإدخال المنظم التالف في النقطة الدقيقة التي يعلم فيها المحلل أنه غير صالح.
إذا فاتتك تلك الحدود، ينتهي الأمر بالكود اللاحق ليعمل على افتراضات لم تعد جديرة بالثقة.
هكذا تتحول أخطاء التحليل منخفضة المستوى إلى مشكلات أمنية.
يعزز هذا الخلل أيضًا شيئًا مهمًا حول الكتابات الفنية (writeups) والفرز (triage):
كان «قبول إدخال تالف» بداية القصة.
كان «قبول إدخال تالف، ثم انتشاره إلى مسار استثناء داخلي أثناء تحليل المفاتيح» هو القصة الكاملة.
ساعد هذا التمييز في تقديم الحجة بوضوح وبشكل صحيح.
لم تكن هذه الثغرة حول تشفير غريب.
بل كانت حول محلل وثق بإدخال تالف لفترة أطول مما كان ينبغي.
عبر حقل طول DER مبتور الحدود، ونجا من التحقق بينما كان يجب رفضه، وتسبب في النهاية في سلوك انهياري في تحليل المفاتيح.
لهذا أصبحت هذه CVE-2026-33936.
عولجت بفرض فحوصات مناسبة لحدود طول DER في أدوات التحليل المساعدة المتأثرة.
