نسخه امنیتی PHP امروز، و چگونگی تقویت امنیت

اوایل امروز، پروژه PHP PHP 8.5.12، 8.4.27، 8.3.36 و 8.2.35 را منتشر کرد. این نسخه‌ها دو آسیب‌پذیری حیاتی را برطرف می‌کنند که در شرایط مناسب، به یک مهاجم تأیید نشده اجازه می‌دهد تا کد را روی سرورهایی که PHP دارند اجرا کند. اگر PHP را اجرا می کنید، ضروری است که همین الان به روز رسانی کنید. اعلامیه php.net حاوی جزئیات فنی در مورد آسیب‌پذیری‌ها، بردارهای حمله و دستورالعمل‌هایی در مورد نحوه به‌روزرسانی در کدام سیستم است و به آن ارجاع می‌دهد.

این پست در مورد نحوه به روز رسانی نیست. این در مورد چگونگی یافتن و رفع این آسیب‌پذیری‌ها است، چه چیزی در نحوه مدیریت امنیت PHP در دو سال گذشته تغییر کرده است، و آنچه ما از سازمان‌هایی که برای ادامه کار امنیتی PHP به PHP وابسته هستند، نیاز داریم.

هر دو مشکل در بخش‌هایی از PHP قرار دارند که تقریبا هر درخواستی به آن مربوط می‌شود: مدیریت حافظه و مدیریت خطا. جایگاه اصلی آنها در PHP همان چیزی است که هر دو آسیب‌پذیری را جدی می‌کند، و همچنین رفع آن‌ها را بدون شکستن سازگاری، آسیب رساندن به عملکرد، یا ایجاد تغییرات در اکوسیستم بزرگ برنامه‌های افزودنی شخص ثالث، سخت کرده است.

در سال 2024، PHP اولین ممیزی امنیتی خارجی خود را پس از چند سال انجام داد. بنیاد PHP برای سازماندهی این ممیزی از طریق OSTIF بودجه ای را از آژانس Sovereign Tech تامین کرد و توسط Quarkslab انجام شد. هنگام رفع یکی از مشکلاتی که Quarkslab گزارش کرده بود، یک توسعه‌دهنده هسته PHP که با بنیاد PHP قرارداد داشت، اولین نشانه‌های مشکل OOM را در پشت CVE-2026-109618 پیدا کرد. در سال 2024، یک بهره برداری بالقوه برای مشکل OOM تئوری شد، اما هیچ بردار مشخصی یافت نشد و سایر مسائل عینی با تأثیر واضح بر این نگرانی ها سایه انداختند.

برای رفع مشکل OOM، تیم امنیتی PHP چندین رویکرد رقیب را توسعه داد، اما هر کدام دارای معاوضه‌های خاص خود بودند: شکست‌های سازگاری به عقب، پتانسیل جدید انکار سرویس، یا نیاز به تغییرات در بسیاری از برنامه‌های افزودنی شخص ثالث که هماهنگی آنها غیرممکن به نظر می‌رسید. تیم امنیتی PHP، که بر اساس اجماع عمل می‌کرد، برای انتخاب بین این موارد تلاش کرد و از پیامدهای ارسال انتخاب نادرست می‌ترسید.

همراه با فقدان یک مسیر شناخته شده برای اجرای کد از راه دور و تیم کوچک توسعه دهندگان هسته با دانش عمیق لازم در مورد موتور که مسئولیت های زیادی را به عهده داشتند، این فرآیند تصمیم گیری باعث شد که کار بر روی یک تعمیر به طور مکرر طی ماه ها متوقف شود و دوباره راه اندازی شود. ما خلاف این را تظاهر نمی کنیم: این تاخیر یک شکست ساختاری بود که هم ناشی از فرآیند تصمیم گیری تیم امنیتی و هم کمبود منابع آن بود. تیم امنیتی از آن زمان تغییر فرآیندهای خود را آغاز کرده است، و این کار ادامه دارد، به طوری که تصمیمات را می توان با اکثریت اتخاذ کرد و مصالحه را تشویق کرد.

طی ماه های گذشته، نحوه سازماندهی کار امنیتی PHP به طور قابل توجهی تغییر کرده است. در ماه مه 2026، بنیاد PHP تیم امنیتی اکوسیستم را ایجاد کرد که در کنار تیم امنیتی PHP روی تریاژ، هماهنگی و سخت‌سازی کار می‌کند. کار Volker Dusch به عنوان مهندس امنیت هوش مصنوعی در Residence در بنیاد PHP به طور قابل توجهی ارتباطات و همکاری بین تیم امنیتی PHP و بنیاد را بهبود بخشیده است.

الکساندر داوبوا در ماه ژوئیه به بنیاد PHP پیوست تا به تیم امنیتی PHP کمک کند تا گزارش‌های امنیتی را مدیریت، مدیریت و اصلاح کند و دانیل شرزر در ماه سپتامبر برای انجام کارهای سخت‌تر به آن ملحق شد.

در اوایل امسال، ما با Alpha-Omega کار کردیم تا PHP را با Claude Mythos از Anthropic اسکن کنیم. اما از زمان اسکن Mythos، ما ابزارهای دیگری از جمله Daybreak Red OpenAI را برای اعتبارسنجی گزارش‌ها و اکسپلویت‌ها، در کنار ساخت‌های ضدعفونی‌کننده و محیط‌های تولید مثل که با CI ما در هر پلتفرمی که PHP پشتیبانی می‌کند، اضافه کرده‌ایم.

بنیاد PHP پروژه PHP را در برنامه Patch the Planet قرار داد، به عنوان بخشی از آن، شرکت امنیتی Calif در 30 ژوئیه 2026 ممیزی PHP را آغاز کرد. در 11 آگوست، محقق Ryan A در کالیفرنیا، اجرای کد از راه دور بدون قید و شرط را با همان علت اصلی مشکل OOM که ما در سال 2024 گزارش کرده بودیم، گزارش داد. OpenAI در 18 سپتامبر و از Wiz در 24 آگوست. اخیرا Trail of Bits نیز PHP را ممیزی کرده است.

گزارش‌های Calif، OpenAI و Wiz تأثیر کامل مشکل OOM را روشن کردند و از 11 آگوست به بعد، رفع آن به اولویت اصلی همه تیم بنیاد PHP که روی امنیت کار می‌کنند تبدیل شد. بدون بودجه بنیاد، غیرممکن بود که چندین نفر به صورت تمام وقت روی این موضوع کار کنند، در نهایت در تعطیلات آخر هفته و شبانه روز برای هماهنگی و ارتباط با سایر طرف های درگیر.

رشد تحقیقات به کمک هوش مصنوعی همچنین به این معنی است که تیم امنیتی PHP گزارش های بسیار بیشتری نسبت به قبل دریافت می کند. همانطور که الکساندر داوبوا هفته گذشته در چگونه تیم امنیتی PHP گزارش های شما را مدیریت می کند، توضیح داد، این تیم از اول ژوئیه 15 CVE منتشر کرده است و بیش از 100 گزارش را بررسی کرده است که معلوم شد نامعتبر، تکراری یا غیرقابل تکرار هستند. هوش مصنوعی به تیم کمک می‌کند تا گزارش‌ها و گزارش‌های گروهی را که علت اصلی یکسانی دارند اعتبار سنجی کنند، اما یک فرد هر تماسی را انجام می‌دهد و روی هر پچ کار می‌کند.

افشای هماهنگ این آسیب‌پذیری‌ها تا 2 روز قبل از تاریخ انتشار هدف به خوبی کار می‌کرد.

در روز سه شنبه، 20 اکتبر، حدود ساعت 15:00 UTC، دو شناسه CVE در انجمن های آنلاین و رسانه های اجتماعی شروع به گردش کردند. آنها با زمان انتشار اشتباه و امتیاز CVSS اشتباه 10.0 (نمره واقعی 9.2) آمدند. هیچ جزئیات فنی فاش نشد. در پاسخ، پروژه PHP پیش اعلامیه خود را ارائه کرد و آن را در ساعت 19:30 UTC منتشر کرد. همچنین انتشار را از 22 اکتبر، 14:00 UTC، به 21 اکتبر، 14:00 UTC منتقل کرد. توزیع کنندگان هنوز در حال بسته بندی رفع مشکل بودند، بنابراین انتشار فوری باعث می شد بسیاری از کاربران راهی آسان برای به روز رسانی نداشته باشند.

یک روز جلو بردن نسخه به جلو بهترین سازش بین سریع عمل کردن، دادن زمان به مردم برای آماده شدن و اطمینان از اینکه همه در هنگام فاش شدن آسیب‌پذیری‌ها یک مسیر به‌روزرسانی ساده دارند، بود.

در نتیجه نشت و پیش‌اعلان در حدود ساعت 20:00 UTC، کالیفرنیا، یکی از شرکت‌های امنیتی که این مشکلات را گزارش کرده بود، به اشتباه ویدیویی را منتشر کرد. این نشان می‌دهد که مفهوم آنها در برابر تعدادی از اهداف کار می‌کند و چند جزئیات اضافی، هرچند محدود، درباره آسیب‌پذیری‌ها را نشان می‌دهد. چندی بعد کپی هایی از ویدیوی حذف شده در شبکه های اجتماعی دست به دست شد. این ویدیو به توسعه سریع PoC های مختلف (اثبات بهره برداری از مفاهیم) کمک کرد، که سپس در 21 اکتبر تیراژ افزایش یافت.

توصیه‌های کاهشی که در حدود 20 اکتبر ساعت 23:00 UTC شروع به ارائه به چند ارائه‌دهنده زیرساخت‌های حیاتی کردیم، ممکن است نیز فاش شده باشد. تیم امنیتی PHP از نزدیک PoC های ظاهر شده را پس از نشت بررسی و بازرسی کرد، اما هیچ گونه سوء استفاده عملکردی را در زمان انتشار/افشای عمومی شناسایی نکرد.

در 21 اکتبر در ساعت 07:41 UTC، بیش از شش ساعت قبل از انتشار هماهنگ، Chainguard به طور یکجانبه تحریم را شکست و تصاویر ساخته شده حاوی اصلاح را منتشر کرد. مانند سایر توزیع‌کنندگان، Chainguard این وصله را از قبل دریافت کرده بود تا کاربران آن بتوانند در لحظه افشای آسیب‌پذیری‌ها، آن را به‌روزرسانی کنند. اکنون هر مهاجمی می تواند اصلاح را به شکل باینری مطالعه کند در حالی که سایر کاربران PHP هنوز منتظر انتشار بودند. این امر باعث نادیده گرفته شدن هفته ها تلاش بسیاری از طرف ها برای افشای هماهنگ شد.

نسخه امروز پیشرفت ما را در نحوه مدیریت امنیت PHP نشان می دهد. هنگامی که تأثیر کامل مشکل OOM در ماه آگوست درک شد، تیم امنیتی، بنیاد و مدیران انتشار، راه‌حلی برای این مشکل ریشه‌دار در تمام شاخه‌های پشتیبانی‌شده ارائه کردند و توزیع‌ها و فروشندگان LTS این وصله را زودتر از موعد دریافت کردند تا کاربرانشان بتوانند به‌سرعت به‌روزرسانی شوند.

ما مطمئن هستیم که یک آسیب‌پذیری جدی با اصلاحی که بر روی مبادلات سخت گیر کرده است، اکنون خیلی زودتر به رهبری بنیاد PHP می‌رسد، زیرا در حال تغییر فرآیندها هستیم تا رهبری بتواند به هدایت وضعیت به سمت حل به موقع کمک کند. ما اکنون در حال اولویت بندی اقداماتی هستیم تا مطمئن شویم آسیب پذیری هایی که به اصلاحات پیچیده مشابهی نیاز دارند، زمانی که در آینده گزارش شوند، سریعتر برطرف می شوند. بنیاد PHP و تیم امنیتی PHP در هفته‌های گذشته چیزهای زیادی آموختند و تلاش خواهند کرد تا تجربیات خود را به فرآیندهای تکرارپذیر پایدار تبدیل کنند.

PHP بخش بزرگی از وب را اجرا می‌کند، از جمله خدمات دولتی، فروشگاه‌های آنلاین، بانک‌ها، سایت‌های رسانه‌ای و بسیاری از نرم‌افزارهایی که کسب‌وکارها هر روز به آن تکیه می‌کنند. با این حال، کار امنیتی بر روی خود PHP هنوز به گروه کوچکی از توسعه دهندگان سرمایه گذاری شده توسط بنیاد و کمی کمک داوطلبانه بستگی دارد.

اکنون ابزارها سریعتر از همیشه اشکالات را برای مدافعان و مهاجمان پیدا می کنند و تعداد گزارش ها همچنان در حال افزایش است. کاری که ابزارها نمی توانند انجام دهند این است که در مورد راه حل مناسب برای یک تصمیم طراحی طولانی مدت در موتور تصمیم بگیرند، معاوضه های سازگاری را بسنجید و پچ را بررسی کنید. اتخاذ این تصمیمات نیازمند مهندسان با تجربه ای است که کل پایگاه کد PHP را می دانند و امروزه تعداد آنها بسیار کم است.

بخش اصلی ماموریت بنیاد PHP افزایش تعداد مهندسان با دانش عمیق از پایگاه کد PHP و دادن منابع مورد نیاز تیم امنیتی است. ما فقط می‌توانیم با کمک مالی افرادی که به PHP وابسته هستند به این هدف برسیم:

حمایت مالی از بنیاد PHP مستقیم ترین راه برای اطمینان از اینکه مسائل ساختاری مانند آسیب پذیری OOM به طور پایدار مورد توجه قرار می گیرند، قبل از تبدیل شدن به شرایط اضطراری است. در thephp.foundation/sponsor یک حامی شوید و اگر سازمان شما مایل است در مورد تعهد بزرگتری صحبت کند، با ما تماس بگیرید.

از تیم امنیتی PHP، داوطلبان و پیمانکاران بنیاد PHP، مدیران انتشار و نگهدارندگان بسته در توزیع‌ها و فروشندگان LTS که این نسخه‌ها را ممکن کردند، تشکر می‌کنیم. از کالیفرنیا، به ویژه Ryan A، Wiz، OpenAI Codex Security، به ویژه Amy Burnett، OSTIF، و Quarkslab برای تحقیقات و افشای مسئولانه‌شان تشکر می‌کنیم. به Alpha-Omega، OpenAI و Anthropic برای دسترسی تیم به ابزارهایشان و تامین مالی برخی از کارهای امنیتی؛ به آژانس Sovereign Tech برای تأمین مالی حسابرسی 2024؛ و به همه حامیان ما که حمایت آنها این کار را ممکن کرد

له