سرریز بافر در curl و libcurl که هنگام دسترسی از طریق پراکسی SOCKS5 آشکار می شود

یک آسیب‌پذیری (CVE-2023-38545) در curl، ابزاری برای ارسال و دریافت داده‌ها از طریق شبکه، و کتابخانه libcurl که به صورت موازی در حال توسعه است، کشف شده است. این آسیب‌پذیری می‌تواند منجر به سرریز بافر شود و به طور بالقوه منجر به اجرای کد سمت کلاینت هنگام دسترسی به یک سرور HTTPS تحت کنترل مهاجم با استفاده از curl یا یک برنامه مبتنی بر libcurl شود. این مشکل فقط زمانی خود را نشان می‌دهد که curl امکان دسترسی از طریق پروکسی SOCKS5 را فراهم کند. دسترسی مستقیم و بدون پروکسی، آسیب‌پذیری را آشکار نمی‌کند. این آسیب‌پذیری در curl 8.4.0 برطرف شده است. محقق امنیتی که این اشکال را کشف کرد، ۴۶۶۰ دلار پاداش از طرح Internet Bug Bounty در Hackerone دریافت کرده است.

این آسیب‌پذیری ناشی از اشکالی در کد حل مسئله نام میزبان قبل از تماس با پروکسی SOCKS5 است. اگر نام میزبان تا ۲۵۶ کاراکتر طول داشته باشد، curl بلافاصله نام را برای حل مسئله محلی به پروکسی SOCKS5 ارسال می‌کند. اگر نام میزبان بیش از ۲۵۵ کاراکتر باشد، به یک حل‌کننده محلی تغییر می‌کند و آدرس از پیش تعریف‌شده را به SOCKS5 ارسال می‌کند. به دلیل اشکالی در کد، پرچمی که نشان‌دهنده نیاز به حل مسئله محلی است، می‌تواند در طول مذاکره اتصال SOCKS5 که کند است، به اشتباه تنظیم شود و در نتیجه نام میزبان طولانی در بافری که برای ذخیره‌سازی اختصاص داده شده است، نوشته شود. آدرس های IP یا نامی که بیش از ۲۵۵ کاراکتر نباشد.

صاحب وب‌سایتی که curl از طریق پروکسی SOCKS5 به آن دسترسی دارد، می‌تواند با برگرداندن یک کد تغییر مسیر (HTTP 30x) و تنظیم هدر "Location:" روی یک URL با نام میزبان بین ۱۶ تا ۶۴ کیلوبایت، سرریز بافر سمت کلاینت را ایجاد کند. (مقدار ۱۶ کیلوبایت با حداقل اندازه مورد نیاز برای سرریز بافر اختصاص داده شده تعیین می‌شود و مقدار ۶۵ کیلوبایت مربوط به حداکثر طول نام میزبان مجاز در یک URL است.) اگر تغییر مسیر در تنظیمات libcurl فعال باشد و پروکسی SOCKS5 مورد استفاده به اندازه کافی کند باشد، نام میزبان طولانی در یک بافر کوچکتر، که مسلماً کوچکتر است، نوشته خواهد شد.

این آسیب‌پذیری در درجه اول برنامه‌های مبتنی بر libcurl را تحت تأثیر قرار می‌دهد و تنها زمانی در ابزار curl خود را نشان می‌دهد که گزینه "--limit-rate" با مقداری کمتر از ۶۵۵۴۱ استفاده شود - libcurl به طور پیش‌فرض ۱۶ کیلوبایت بافر اختصاص می‌دهد، در حالی که ابزار curl ۱۰۰ کیلوبایت اختصاص می‌دهد، اما این اندازه بسته به مقدار پارامتر "--limit-rate" تغییر می‌کند.

دنیل استنبرگ، نویسنده این پروژه، خاطرنشان کرد که این آسیب‌پذیری به مدت ۱۳۱۵ روز کشف نشده باقی مانده است. او همچنین اظهار داشت که اگر curl با زبانی با حافظه امن نوشته می‌شد، احتمالاً ۴۱٪ از آسیب‌پذیری‌های قبلاً شناسایی شده در curl قابل اجتناب بودند، اما هیچ برنامه‌ای برای بازنویسی curl به زبان دیگری در آینده‌ای قابل پیش‌بینی وجود ندارد. اقداماتی برای بهبود امنیت پایگاه کد شامل گسترش ابزارهای تست کد و استفاده بیشتر از وابستگی‌های نوشته شده به زبان‌های با حافظه امن است. جایگزینی تدریجی بخش‌هایی از curl با انواع نوشته شده به زبان‌های با حافظه امن، مانند backend آزمایشی Hyper HTTP که در Rust پیاده‌سازی شده است، نیز در حال بررسی است.

منبع: opennet.ru

اضافه کردن نظر