عصر جديد: إشاعة الثغرات الأمنية تستحث الاستغلال الآلي في المصادر المفتوحة

لقد أصدرتُ إصلاحًا أمنيًا لمكتبة OCaml Cohttp 6.3.0 اليوم، والذي يعالج مشكلة اجتياز المسار. كان التصحيح بحد ذاته واضحًا ومباشرًا، وفي الظروف المعتادة، يتضمن الإجراء الأمني إصلاحه بشكل خاص، وإبلاغ المستخدمين المتأثرين، ثم إصدار استشارة عامة. لكن هذه المرة، لاحظت تحقيقات في سجلات خادم الويب المباشر الخاص بي تحتوي على نمط الخطأ الدقيق بعد دقائق فقط من فتح طلب السحب (PR) لإصلاح المشكلة.

والأمر الأكثر إثارة للقلق هو أنني وجدت أنه يمكنني استخدام أدواتي للعثور على الاستغلال فقط من خلال معرفة ما تدور حوله المشكلة تقريبًا، وبالتالي كان من الممكن استغلالها قبل وقت طويل من توفر التصحيح العام! بالنظر إلى أن مجرد إشاعة بوجود مشكلة أمنية تبدو كافية لتزويد المهاجمين بمعلومات كافية للعثور على ثغرات جديدة، فإننا بحاجة إلى تغيير الطريقة التي نتعامل بها مع الاستجابات الأمنية في عالم المصادر المفتوحة.

إشاعة وجود خلل هي كل ما تحتاجه أنظمة استغلال الثغرات الذكية الجديدة

وصل هذا التقرير بشكل خاص على قناة Slack عبر Jane Street الأسبوع الماضي، وتم العثور عليه أيضًا عبر Claude Fable. وهذا يضغط جميع الجداول الزمنية إلى حد كبير.

الجدول الزمني لتقرير أمني حديث

قبل فحص التصحيح بالتفصيل، وجهت أدواتي الذكية نحو الكود المتأثر لمعرفة ما كان كامنًا (طلبت منها التحقيق في مشكلات تطبيع المسار). تم رفض Fable بشكل محبط تمامًا بسبب حظرها الأمني الخاص، لكن Deep Sec V4 Pro ألزمني وأثار بشكل مستقل العديد من القضايا ذات الصلة. قام وكيل أعمالي أيضًا بإنشاء برنامج استغلالي لاستكشاف خادم مباشر محلي في أقل من دقيقة.

بعد بعض الجدل مع مراسل الأخطاء حول الإصلاحات المحتملة، فتحت موضوع Cohttp #1145 علنًا للحصول على المزيد من الآراء عليه. يستغرق هذا عادةً بضعة أيام ويكون الإصدار خلال أسبوع أو أسبوعين أمرًا معقولًا. في غضون حوالي عشر دقائق (!) كان هذا الموقع يرسل تحقيقات لتسلسلات اجتياز المسار المشفرة بنسبة مئوية، مما يشير إلى أن المراقبين الآليين يراقبون المستودعات العامة.

إذا استغرق الأمر مني دقيقة واحدة فقط لإنشاء برمجية استغلال خاصة بي محليًا، إذن عشر دقائق تبدو في الواقع طويلة جدًا لبدء نافذة الهجوم الآلي! يمكن للمهاجم المصمم الذي يراقب مستودعات الحزم أن يستغلها بسهولة في غضون ثوانٍ.

لم تعد عمليات حظر الكشف الأمني فعالة

تتضمن عملية الأمان التقليدية حظر معلومات الثغرات، ويفترض أن سرية التفاصيل تحمي المستخدمين. ومع ذلك، كل ما يحتاجه الوكيل الذكي اليوم هو اتجاه واسع للبحث فيه، ويمكنه إجراء بحثه الخاص. وجد فانغ وآخرون أنه عند إعطاء وصف لـ CVE، وكيل GPT-4 الخاص بهم استغل 87% من 15 نقطة ضعف، وبدون وصف، 7% فقط.

وبعد عامين، متوسط ​​الوقت اللازم للاستغلال هو -7 أيام. بمعنى آخر، الاستغلال الآن يسبق التصحيح! يبدو أن هذا المقياس نفسه كان حوالي 63 يومًا في 2018-2019، وتجاوز الصفر في عام 2024. ويجد البحث السريع الكثير من الحالات المماثلة الأخرى هذه الأيام… انتقلت CVE-2026-39987 (Marimo) من الاستشارة إلى محاولة الاستغلال الأولى في 9 ساعات، حتى مع عدم وجود إثبات عام للمفهوم. استغرق CVE-2026-33017 (Langflow) 20 ساعة. يبدو أننا قد تجاوزنا الحد الأقصى لتوليد الاستغلال الآلي.

حالة استغلال نماذج اللغات الكبيرة (LLM) في عام 2026 (المصدر: Vulncheck)

هل علم الثغرات (Bugonomics) بات ضد القائمين على صيانة المصادر المفتوحة؟

يبدو لي أن عملياتنا الأمنية تحتاج إلى التكيف بشكل جذري، نظرًا لأن مجرد شخص واحد يبحث عن فئة مشكلة معينة (قد يكون هذا سؤالًا في قائمة بريدية، أو التزامًا غريبًا في فرع مهجور، أو تسرب سياق) يكفي لتنبيه وكيل ذكي آخر والسماح له بالحصول على رمز الاستغلال. هذا أمر جنوني.

صاغت ورقة بحثية في مايو 2026 مصطلح bugonomics (علم الثغرات)، مشيرة إلى أن عنق الزجاجة قد انتقل إلى قدرة المدافعين على المعالجة. تقوم نماذج اللغات الكبيرة (LLMs) بإنشاء برمجيات استغلال الثغرات بسعادة، لكن قدرتنا على الدفاع ضدها لا تتحسن بالضرورة مع بقاء معدلات التحقق من صحة المشرف والفرز والإصدار ثابتة. يتطابق هذا للأسف مع وجهة النظر من كرسي مشرف المصادر المفتوحة الخاص بي:

السؤال ليس ما إذا كانت النماذج الحدودية، أو نماذج الوزن المفتوح، أو تحليل البرامج ستفوز. السؤال هو كيفية تنسيقها بحيث تذهب القدرة النادرة على التحقق من الصحة وتحديد الأولويات والإصدار نحو إصلاحات دائمة بدلًا من البحث الميكانيكي وصياغة التقارير. فرصة المدافع المركزي هي المعالجة الفنية للديون: سير عمل يعتمد على الدلالات، ويتم التحقق منه بالأدوات، ومدعوم بالنماذج، مما يساعد المشرفين على العثور على العيوب المتعلقة بالأمن والتحقق من صحتها وتحديد أولوياتها وإصلاحها قبل أن تصبح نقاط ضعف مستغلة في الغد.

ولماذا تظل قدرات المشرف ثابتة؟ حسنًا، يعد عدم القدرة على الوصول إلى عملاء الحدود مثل Mythos أمرًا واضحًا، ولكن أيضًا هندسة التصحيح الأمني ​​الذي لا يسبب أي تراجعات هو مجرد المزيد من العمل بشكل أساسي.

إذًا، ما الذي يمكننا فعله حيال هذا الأمر؟

من الواضح أننا بحاجة إلى التكيف بسرعة إلى حد ما. لا أعتقد أن عملية الفرز اليدوي الحالية يجب أن تختفي، لكنني رأيت زيادة غير مستدامة في النشاط منذ ظهور Fable. لقد بدأنا للتو في التعرف على كمية البيانات الهائلة القادمة التي يتم توليدها آليًا، ولكن من الواضح أنها كثيرة.

لقد قامت الشركات الهندسية الكبرى (مثل جوجل) بدمج التحديثات المصغرة (microupdates) مباشرة في برامجها لضمان وصول الإصلاحات إلى المستخدمين كأولوية بدلًا من إصلاحها في مستودع أكواد Chrome (على سبيل المثال). ليس لدينا حقًا هذا النوع من الرفاهية في Docker أو OCaml، لأننا لا نتحكم في نقاط النهاية التي يُستخدم فيها برنامجنا. تقوم التوزيعات النهائية، مثل Docker Desktop، بإعادة تجميع المصادر المفتوحة بشكل صحيح وفقًا لجداولها الزمنية وشروطها الخاصة.

بالنسبة للمشاريع الصغيرة مثل OCaml، فإن مجرد الوصول إلى النماذج الرائدة يمثل صراعًا. النماذج الغربية لديها حراس أمنيين، مما يعني أننا لا نستطيع استخدام الحراس المتاحين تجاريًا. مشروع Glasswing التابع لـ Anthropic توسع ليشمل 150 مؤسسة في 15 دولة، بما في ذلك مشغلو البنية التحتية الحيوية ومقدمو الخدمات السحابية والمالية ومؤسسة Linux، لكن المشرفين العاديين لا يزالون غير قادرين على الوصول. كنت أتساءل في أبريل عما إذا كان هذا ضارًا، لكن من الواضح جدًا اليوم أن الأمر أصبح سيئًا للغاية.

تطوير التصحيحات بسرية تامة

العلاج الأول هو تطوير الإصلاحات في مكان خاص بعيدًا عن متناول الذكاء الاصطناعي. شوكات GitHub الخاصة المؤقتة تقوم بذلك اسميًا، لكنها لا تعمل بشكل جيد بالنسبة لنا.

أولًا، قام GitHub بتقييدها: للحفاظ على أمان معلومات الثغرات، لا يمكن للمكونات المتكاملة، بما في ذلك التكامل المستمر (CI)، الوصول إلى الشوكات الخاصة المؤقتة، مما يؤدي على الفور إلى فصل المشرف عن شريان الحياة لنتائج CI الخاصة بنا. ثانيًا، لا يمكن دمج سوى طلب سحب (PR) واحد في الشوكة، وهو ما لا يعمل بشكل جيد مع المشكلات التي غالبًا ما تمتد إلى عدد قليل من المستودعات. يجب أيضًا أن يتم تسجيل المراجعين واحدًا تلو الآخر من قبل المسؤول، وفي المصادر المفتوحة، يكون المراجعون متاحين بشكل حر نسبيًا اعتمادًا على من هو متاح (خاصة في أغسطس!).

وعلى نطاق أوسع، يؤدي هذا إلى سد التسرب الخاطئ. لا يعد بقاء التصحيح سريًا بنفس أهمية ضمان وصول الوصف الخاص بالمشكلة إلى الأشخاص المناسبين تمامًا دون تسربه إلى المهاجمين.

ليس لدينا بنية تحتية قوية للمناقشة متاحة داخل المصادر المفتوحة حيث تنتشر عبر العديد من البنى التحتية المشفرة من طرف إلى طرف (نحن نستخدم Matrix) ولكن أيضًا البنية التحتية المشتركة مثل Discord أو Slack التي تكون شديدة التسرب. نحن بحاجة إلى نوع من شبكة الثقة لتمييز الأخيار عن الأشرار في سياق مشروع معين.

لا حظر، فقط الشحن المستمر

شيء آخر يمكننا القيام به هو إصلاح المشكلات العامة بسرعة، والشحن بشكل مستمر، وتحسين مسار الإصدار من خلال أتمتة أفضل.

تُظهر المشاريع الأكبر مثل Chrome أن هذا ممكن من خلال تحديثات أمنية أسبوعية (إصداران في الأسبوع!) والتصحيح الديناميكي الذي يقوم بتبديل العمليات الخلفية للثنائيات المحدثة دون إعادة التشغيل. هذه ليست تقنية جديدة تمامًا؛ لقد بحثت في دمج التصحيح المباشر لـ ksplice Linux باستخدام Xen منذ أكثر من 15 عامًا. تقوم نواة Linux أيضًا بشحن الإصلاحات في أسرع وقت ممكن، مع تأجيلها على الأكثر سبعة أيام، وأربعة عشر يومًا في الحالات الاستثنائية.

ومع ذلك، فإن تغليف البرامج هو العائق الرئيسي الذي يواجهنا. يتمتع Chrome بمهمة سهلة نسبيًا تتمثل في شحن قطعة أثرية ثنائية واحدة، ولكن المصادر المفتوحة غالبًا ما تكون عبارة عن مجموعة من المكتبات المضمنة في مجموعة متنوعة من المنتجات النهائية. لذلك، للقيام بذلك، سنحتاج:

• إدارة حزم النظام البيئي الشامل بشكل أفضل بكثير لاكتشاف مكان دمج المكتبات المتباينة في النهاية. سيتحدث ريان جيب عن هذا في ICFP الأسبوع المقبل!
• وأدوات مسح أفضل للمساعدة في الفرز؛ كان أندرو نيسبيت يفعل هذا بالضبط في المدقق خلال الأشهر القليلة الماضية. لقد كنت أناقش مع توماس غازاجنير تجربة ذلك بالنسبة لرمز OCaml الخاص بنا، بشرط الوصول إلى نموذج حدودي معقول بدون عوائق أمنية.
• مراقبة جودة أكثر قوة في الوقت الفعلي (IR) دون أي نتائج إيجابية كاذبة تعمل عبر مجموعة من الأنظمة الأساسية المدعومة. على الرغم من أنه من السهل نسبيًا تشغيل CI على Linux، إلا أن الأمر مختلف تمامًا مع OpenBSD و FreeBSD و Mac، وبعض البنى مثل RISC-V.

الحماية الاستباقية على مستوى البروتوكول

لقد كانت لدي أيضًا أفكار أكثر جذرية حول كيفية تطوير وسائل حماية ديناميكية لحماية نقاط النهاية باستخدام مكتباتنا. إذا قبلنا أن إصلاحات التصحيح الأولية ستؤدي دائمًا إلى تتبع الاستغلال، فإننا يجب أن نضع شيئًا أسرع للمضي قدمًا.

على سبيل المثال، يحتوي خطأ cohttp الذي تم إصلاحه اليوم على تخفيف بسيط: ما عليك سوى تسوية فواصل المسار المشفرة بنسبة مئوية في عنوان URL للطلب. كانت هذه القاعدة قابلة للتنفيذ بمجرد وصول التقرير، كما كانت قابلة للنشر أثناء مرور الإصلاح الكامل بالمراجعة والاختبار والتعبئة. يعد التصحيح الافتراضي أمرًا روتينيًا في البنية التحتية السحابية هذه الأيام؛ فقد قامت Cloudflare بنشر قواعد مُدارة لتخفيف هجمات Log4shell في عام 2021.

لكن المصدر المفتوح يفتقر إلى آلية توزيع لمثل هذه القواعد خارج شبكة CDN التجارية. هذا ما تحاول شبكة المضادات الحيوية – وهي فكرة من ورقتنا البحثية عن علم البيئة على الإنترنت – توصيله عبر المزيد من تنوع البرامج حول شبكة الإنترنت العالمية. كيف يمكن أن يكون لدينا دفاعات محلية سريعة الانتشار تسمع عن وجود ثغرة أمنية وتتصرف على بنيتها التحتية المباشرة في غضون ثوانٍ؟

بعض المتابعات البحثية

أعتقد أننا سنحتاج إلى مزيج من الخيارات الثلاثة على المدى القصير: شبكة ثقة خفيفة الوزن للمساهمين في المصادر المفتوحة (مثل ما كان عليه Advogato سابقًا)، بالإضافة إلى المزيد من التركيز على تعبئة برمجيات المصدر المفتوح وآليات النشر والفرز المستمرة التي لا تطغى على المساهمين البشريين الثمينين.

لقد قمت أيضًا بنشر بعض الأفكار الجديدة لأبحاث الماجستير في الفلسفة لأي شخص قادم إلى كامبريدج الشهر المقبل ويبحث عن مشروع:

• An antibotty defensive testbed to protect network services يضع بوابة MirageOS أمام الشبكة المنزلية، ويتحقق مما إذا كان يمكن جعل مجموعة قواعد التخفيف جديرة بالثقة بما يكفي للنشر تلقائيًا. هناك لعبة ممتعة لالتقاط العلم يمكننا لعبها من خلال إعطاء نفس الإشاعة إلى العميل المهاجم والمدافع ومعرفة أيهما يصل إلى هناك أولًا.
• Compiling Lean specifications into OxCaml enforcement automata يحدد ما يُسمح للمكتبة بفعله عبر نظام الملفات والمحلل اللغوي وطبقات الشبكة باستخدام ديكسترا موناد. سيؤدي هذا إلى تجميع مواصفات Lean هذه في جهاز OxCaml الآلي الذي يفرضها في وقت التشغيل. إنها تدور حديث على أتمتة استدعاء الحالة التي بنيتها خلال الدكتوراه.

وإذا كان أي شخص من Project Glasswing يستمع، فيمكن لفريق OCaml استخدام الوصول الآن 🙂

(ملاحظة: لم يكن إصلاح cohttp مجهودًا فرديًا. فقد عثرت Sapphire Livingstone على المشكلة وأبلغت عنها، وأرشدت عملية الإصلاح وشاركت في تطوير العلاج؛ مايكل ديلز، توروك إدوين وباتريك فيريس استعرضوا التصحيح. هانس مينرت نسق الاستشارة. وقد تم التفكير في مشكلة الفرز الأوسع مع توماس غازاجنير. شكرًا لكم جميعًا! قد يكون علم الثغرات ضدنا، ولكننا سنصل إلى قمة هذه الحدبة.)