curl زیر بار CVE نرفت
خلاصهٔ کامل‌تر
دنیل استنبرگ تو پست تازه‌ش از اولین اختلاف رسمی پروژهٔ curl بر سر یه CVE می‌گه. curl چند سالی هست که خودش CNA شده؛ یعنی برای مشکلات امنیتی قلمرو خودش، خودش تصمیم می‌گیره و شناسهٔ CVE صادر می‌کنه و دیگه خبری از CVEهای بی‌ربطی که بیرون براش می‌ساختن نیست. تو این مدت ۵۷ آسیب‌پذیری با CVE منتشر کردن و به گفتهٔ نویسنده چون از قبل فرایند جاافتاده‌ای برای دریافت و بررسی گزارش‌ها داشتن، CNA بودن عملاً بار اضافه‌ای براشون نداره.
روند کارشون اینه که اول بررسی می‌کنن اصلاً موضوع یه مشکل امنیتی هست یا نه؛ اگه بود، شدتش رو LOW، MEDIUM، HIGH یا CRITICAL می‌ذارن — از دید خودِ curl، چون نمی‌دونن هر کاربر دقیقاً چطور ازش استفاده می‌کنه. ولی یه سطل دیگه هم دارن که اسمش رو «پایین‌تر از LOW» گذاشتن: مشکلاتی که فقط در تئوری ریسک دارن و رسیدن بهشون اون‌قدر شرط عجیب و مرحلهٔ پیچیده لازم داره که عملاً هیچ کاربری بهشون نمی‌رسه.
دلیلش هم صراحتاً اقتصادیه: libcurl حدود سی میلیارد نصب فعال رو کرهٔ زمین داره. به گفتهٔ نویسنده هر CVE که منتشر کنن، تیم‌های امنیتی سراسر دنیا رو به تکاپو می‌ندازه و موج وصله و آپدیت راه می‌ندازه. این هزینه روی دوش خودشون نیست و حسش نمی‌کنن، ولی روی اکوسیستم سنگینی می‌کنه — پس مسئولانه‌ش اینه که مشکل واقعی رو هیچ‌وقت لاپوشونی نکنن، اما برای مشکل تئوری هم آژیر نکشن.
خودِ باگ هم فنی و باریکه: کاربر باید تو URL یه نام میزبان با نقطهٔ ابتدایی بذاره، چیزی شبیه — نامی که تو DNS اصلاً غیرمجازه و فقط با چیزی مثل فایل /etc/hosts میشه براش آدرس تعریف کرد. اون‌وقت اگه سایت مقصد گواهی wildcard برای *.example.com داشته باشه و curl هم با OpenSSL یا Schannel ساخته شده باشه، تابع Curl_cert_hostcheck() اشتباهاً این ترکیب رو «تطبیق» گزارش می‌کرد، درحالی‌که طبق استاندارد تطبیق نیست. باگ هشتم دسامبر ۲۰۲۵ رفع شد و براش تست واحد هم نوشتن.
ولی سر CVE دادن بهش به توافق نرسیدن. به گفتهٔ استنبرگ، زنجیرهٔ شرط‌های لازم بیش از حد بعیده: کاربر باید عمداً یه نام نقطه‌دار عجیب بذاره، اپلیکیشن رو هم نمی‌شه گول زد که خودش سراغ چنین نامی بره چون اصلاً resolve نمی‌شه، مهاجم باید میزبان جعلی با همون گواهی wildcard بالا بیاره و عملاً پای یه مهاجم محلی با دسترسی وسطه. جمعش میشه «پایین‌تر از LOW» و به نظر تیم، ارزش CVE گرفتن نداره.
گزارشگر اما راضی نشد و دهم فوریهٔ ۲۰۲۶ ماجرا رو به مایتر (MITRE) برد تا CVE رو به زور بگیره. تیم curl توضیحش رو فرستاد و لینک گزارش عمومی رو داد؛ ۲۸ مه و بعد ۱۵ ژوئن باز هم همون سؤال از مایتر اومد و همون جواب رفت — استنبرگ با کنایه می‌نویسه که واقعاً چه سیستم عالی‌ای. سرانجام ۲۴ ژوئن حکم نهایی رسید: مایتر هم با ارزیابی CNA موافقه، این یه باگه که رفع شده و چون به مهاجم محلیِ دارای دسترسی نیاز داره آسیب‌پذیری امنیتی حساب نمی‌شه؛ پرونده بسته.
نکات کلیدی:
- curl خودش CNA ـه و تا حالا ۵۷ آسیب‌پذیری با CVE منتشر کرده؛ تصمیمِ CVE دادن یا ندادن هم با خودشه.
- تیم curl یه ردهٔ غیررسمی «پایین‌تر از LOW» داره: ریسک تئوری با شرط‌های آن‌قدر بعید که عملاً هیچ‌کس بهش نمی‌رسه.
- استدلالشون هزینهٔ اکوسیستمه؛ با سی میلیارد نصب libcurl، هر CVE موج وصله و آپدیت جهانی راه می‌ندازه.
- باگ واقعی بود و رفع شد: تطبیق اشتباه گواهی wildcard برای نام میزبان با نقطهٔ ابتدایی تو OpenSSL و Schannel.
- داوری مایتر بعد از چهار ماه به نفع curl تموم شد و برای این مورد CVE صادر نشد.
