ثغرة TCP في Linux: التصحيح أم التخفيف؟

لدى نواتك ثغرة use-after-free قابلة للاستغلال عن بُعد في مسار مصافحة TCP، ولم تُصدر توزيعتك إصلاحًا بعد، وشخص ما أثبت بالفعل وجود استغلال يعمل للحصول على صلاحيات root. فما الخطة؟ الانتظار، أم البدء بإسقاط الحزم عند جدار الحماية؟ ثغرة TCP use-after-free في Linux المعلنة باسم CVE-2026-98432 مثال واضح على أقدم قرار في عمليات الأمن: التصحيح مقابل التخفيف، والإجابة الصريحة أن الخيارين ليسا متماثلين أبدًا. أحدهما يحل المشكلة فعلًا.

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

ما هي ثغرة TCP Use-After-Free فعليًا

الآليات مهمة هنا لأنها تحدد ما يستطيع التخفيف فعله وما لا يستطيعه. عندما يقبل خادمك اتصال TCP عبر IPv4، تتتبع النواة المصافحة نصف المفتوحة في request socket خفيف، ثم ترقّيه إلى socket كامل بعد اكتمال المصافحة. وإذا كانت ترويسة IPv4 لدى الطرف الآخر تحمل خيارات، تحفظها النواة لتعيدها في ردودها. الخلل: مرّرت النواة هذه الخيارات المحفوظة إلى الاتصال الجديد دون نسخها، ثم حررتها فورًا، بينما قد تكون معالجة أخرى على نواة مختلفة ما زالت تقرأها لبناء رد المصافحة. هذا use-after-free يمكن الوصول إليه من طرف بعيد غير موثّق، قبل أن يُنفَّذ أي سطر من كود تطبيقك.

الإصلاح في المصدر الأصلي، من Eric Dumazet، مكوّن من أربعة أسطر: استدعاءان بسيطان لـkfree() يصبحان kfree_rcu()، وهذه الدالة تؤجل التحرير حتى ينتهي كل القراء من استخدام الذاكرة. وهو الإصلاح المعتمد في النواة لهذا النوع من الأخطاء، فالقراء تحت RCU يحملون مراجع لا تراها، لذلك تترك فترة الـgrace period تنقضي قبل استرجاع الذاكرة. وقد صنّفت جهة CNA الخاصة بالنواة الثغرة بدرجة CVSS 9.8. أما Red Hat فصنّفتها أولًا 8.1، ثم رفعتها إلى 9.8 بدرجة Critical في 30 أكتوبر، مستندةً إلى عدم الحاجة إلى أي شروط مسبقة على الشبكة.

هناك تفصيلان يغيّران حساب التعرض. أولًا: سباق الحالة يفشل بلطف، فالمحاولة الفاشلة تُفشل المصافحة فقط دون أن تُسقط الجهاز، لذلك يستطيع المهاجم إعادة المحاولة بلا حدود. ثانيًا: مسار الاستغلال الذي أثبتته Anthropic يستهدف مضيفات لديها listener من نوع multipath TCP، ووفقًا لفريق الأمان في Go، فإن برامج Go تفتح listeners من نوع MPTCP افتراضيًا على Linux منذ Go 1.24، حيثما تسمح النواة بذلك. تحقق من أسطولك:

ss -Mlnp                 # MPTCP listeners and their owning processes
sysctl net.mptcp.enabled # 1 means apps may open MPTCP sockets

المخرج الفارغ لأمر ss -M يعني عدم وجود listener من نوع MPTCP. لكن لا تطمئن كثيرًا، فقد أوضح فريق Go أن الخلل الأساسي ليس خاصًا بـ MPTCP. إنه use-after-free عام في معالجة المصافحة، وMPTCP مجرد المسار الذي أثبته أحدهم من البداية إلى النهاية.

مسار التصحيح: نواة مُصلحة، ثم إعادة تشغيل، وانتهى الأمر

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

المشكلة في إعادة التشغيل. لا يفعل تحديث النواة شيئًا حتى يُقلع الجهاز عليها، وهنا تكمن التكلفة التشغيلية الحقيقية: إخلاء عقد Kubernetes، ومراجعة سيناريوهات الfailover، وقاعدة البيانات الرئيسية التي لا يريد أحد إعادة تشغيلها في ساعات العمل. لهذا تبقى عبارة «فقط صحّح» صحيحة دائمًا، لكنها لا تكفي كنصيحة. تحتاج إلى خطة نشر: مضيفات تجريبية أولًا، ثم الطبقات عديمة الحالة، ثم الطبقات ذات الحالة ضمن نوافذ صيانة. إذا مررت سابقًا بعملية تبديل نواة طارئة على مستوى الأسطول، فأنت تعرف الإجراء. الفرق التي تتعامل مع هذا جيدًا هي التي تدربت على إخلاء العقد وقت الهدوء، وعادات الهندسة الدفاعية التي تبنيها في أيام الهدوء هي ما يثمر أثناء ثغرة بدرجة 9.8.

فخ يستحق الذكر: ظهور حزمة مُصلحة في dpkg -l أو rpm -q kernel لا يعني شيئًا إذا كانت النواة الجارية أقدم منها. الأمر uname -r يخبرك بما يعمل فعليًا. وعلى توزيعات RHEL وما شابهها، يوضح لك needs-restarting -r بصراحة إن كانت إعادة التشغيل معلقة. راجعت تقارير ما بعد الحوادث حيث كان الأسطول «المُصحَّح» مجرد نوى مثبتة لكنها غير قيد التشغيل. تحقق من إصدار النواة الجارية مقابل متتبع توزيعتك، لا مقابل الرقم في المصدر الأصلي، فنوى التوزيعات تحمل backports تحت ترقيم خاص بها.

مسار التخفيف: إسقاط خيارات IPv4 وتعطيل MPTCP

التخفيف المؤقت المنشور هو قاعدة nftables تُسقط حزم IPv4 TCP الواردة التي تحمل خيارات IP، وهي شرط الإطلاق للمسار الضعيف. ويمكنك تكميلها بتعطيل MPTCP (sysctl -w net.mptcp.enabled=0) إذا كنت لا تستخدمه. كلاهما سريع، ولا يتطلب إعادة تشغيل، ويمكن نشره بأدوات إدارة الإعدادات في نصف يوم. وهذه هي جاذبيته.

الآن الجزء الذي يجب أن يخفف حماسك: تقول نشرة Red Hat نفسها إن قاعدتها «تقلل التعرض لهذه الثغرة لكنها لا تمنعها بالكامل». اقرأ الجملة مرتين. التخفيف يضيّق سطح الهجوم ولا يغلقه. الحزم التي تحمل خيارات IP نادرة في حركة المرور العادية، ومعظم الـmiddleboxes تُسقطها أصلًا، وهذا أحد أسباب اعتبار الاستغلال عبر الإنترنت المفتوح مستبعدًا، لكن «نادر» و«مستحيل» كلمتان مختلفتان، والخلل في كود المصافحة العام، لا في مسار الخيارات وحده الذي اختبره أحدهم.

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

التصحيح مقابل التخفيف: متى ينتصر كلٌّ منهما

هذه بطاقة تقييمي الصريحة، بعد سنوات من اتخاذ هذا القرار تحت الضغط.

• توجد نواة مُصلحة لتوزيعتك. التصحيح يفوز بلا منازع. أصدرت Debian وSUSE Enterprise وOracle UEK وAmazon Linux كلها إصلاحات. لا يوجد تخفيف أذكى من إصلاح المصدر الأصلي المكون من أربعة أسطر. جدول إعادة التشغيل، وانشر على حلقات، وانتقل للتالي.
• لا توجد نواة مُصلحة بعد، والتعرض حقيقي. خفّف فورًا، فهذا بالضبط ما وُجدت له التخفيفات. كانت Ubuntu وRHEL لا تزالان في حالة «معرضة» أو «متأثرة» في نهاية أكتوبر. إذا كنت مكشوفًا على الإنترنت ولديك listener من نوع MPTCP، فأسقط حزم خيارات IP وعطّل MPTCP اليوم، وتابع النواة المُصلحة كأنها إصدار تمنع إطلاقه.
• مكشوف على الإنترنت لكن خلف واجهة مُدارة. ينخفض إلحاحك. توجيه AWS، الذي يقول إن الحركة المارة عبر موازنات الأحمال أو CloudFront أو API Gateway لا تصل إلى مثيلاتك كـTCP خام غير موثوق، توجيه سليم. ومع ذلك خفّف لأنه رخيص، وصحّح ضمن دورة عادية بدل دورة طارئة.
• أنظمة بنواة أو طابور واحد. أولوية أقل. السباق يحتاج معالجة متزامنة للحزم على عدة نوى. الأجهزة المدمجة والآلات الافتراضية الصغيرة تحصل على بعض الراحة، لكنها غالبًا ما تكون الأجهزة التي لا يعيد أحد تشغيلها أبدًا، فلا تدع «أولوية منخفضة» تصبح «لا شيء أبدًا».
• نوى منتهية الدعم (قبل 5.10 في المصدر الأصلي). التخفيف هو خيارك الوحيد المستقل عن المصدر الأصلي. هنا ينتصر التخفيف فعليًا، لأن البديل هو backport من الموزع قد لا يصل أبدًا. وهي أيضًا إشارة واضحة بأن الجهاز نفسه هو الثغرة، وأن الحل الحقيقي هو استبداله.

فجوة التوزيعات هي القصة الحقيقية

التفصيل الذي يجب أن يزعجك ليس الخلل نفسه، فإصلاحات use-after-free المكونة من أربعة أسطر تصل إلى نوى الاستقرار كل شهر. بل أن اثنين من أكبر توزيعات الخوادم في العالم، Ubuntu وRHEL، ظلتا بلا إصلاحات مُصدرة بعد أكثر من أسبوعين من المصدر الأصلي، بينما كانت Amazon Linux قد صححت كل نواتها، وكان AlmaLinux، وهو إعادة بناء مجتمعية، يملك نوى مُصلحة في الاختبار قبل المصدر الأصلي. لاحظ مجتمع Hacker News ذلك، ومن حقهم الانزعاج، فهذه التوزيعات هي الأكثر تسويقًا لجاهزيتها للخوادم.

بالنسبة للممارسين، الخلاصة غير لامعة: نافذة تعرضك تحددها خط backport لدى موزعك، لا المصدر الأصلي. وهذا يقتضي أمرين. أولًا، اعرف روابط متتبعات توزيعتك وراقبها فعلًا، فهذه الثغرة بقيت في حالة «Received» على NVD دون تحليل، بينما كانت جهة CNA الخاصة بالنواة وRed Hat والتوزيعات الأخرى تملك صفحات مفصلة. ثانيًا، اجعل سرعة استجابة الموزع معيارًا للاختيار. أثبتت Amazon Linux للتو أن خط إصلاح النواة لديها أسرع بشكل ملحوظ من الاثنين الكبيرين. هذا لن يهم في عرض تسويقي، لكنه يهم في عطلة نهاية الأسبوع عندما تنزل ثغرة 9.8.

الاستغلال المكتوب بالذكاء الاصطناعي يغيّر الساعة

أهم سطر في الإفصاح يسهل تجاوزه: تقول Anthropic إن نموذج Claude الخاص بها أنتج استغلالًا يعمل للوصول إلى صلاحيات root عن بُعد، بعد توجيه أولي، واستغرق أقل من ساعة من وقت الآلة للانتقال من تسريب مؤشر في النواة إلى shell بصلاحيات root. لم تنشر الشركة الاستغلال، وسخر بعض المشككين في HN من صيغة «ثق بي». وهذا منصف. لكن حتى مع خصم الدعاية، الاتجاه واضح: الفاصل بين «وصول الفرق إلى شجرة الاستقرار» و«وجود استغلال يعمل» يتقلص، لأن عنق الزجاجة في كتابة الاستغلال لم يكن الخلل، بل الإنسان القادر على قراءة الفرق وتنفيذ heap grooming.

هذا يضغط نافذة قرار التصحيح مقابل التخفيف. عندما كان تطوير الاستغلال يستغرق أسابيع، كان «خفّف الآن وصحّح في نافذة الصيانة القادمة» مقبولًا. أما عندما يستطيع نموذج أن يصنع PoC خلال ليلة من commit عام، فيجب أن تُقاس مرحلة التخفيف بالساعات، ومرحلة التصحيح بالأيام. الإصلاح المكون من أربعة أسطر متاح للجميع، ويستطيع أي أحد دراسته. افترض أن الاستغلال متاح أيضًا.

توصيتي

صحّح. لا تخفف إلا كجسر مؤقت، وضع تاريخ انتهاء لهذا الجسر. عمليًا: إذا كانت توزيعتك تملك نواة مُصلحة، فابدأ بتعميمها الآن، وتحقق من uname -r بعد كل إعادة تشغيل. إذا كنت على Ubuntu أو RHEL، فانشر إسقاط خيارات IP وعطّل MPTCP اليوم، ثم تعامل مع غياب إصلاح النواة كاعتماد يمنع الإطلاق، وراجع المتتبع يوميًا لا أسبوعيًا. أعطِ الأولوية لأي شيء مكشوف على الإنترنت ولديه listener من نوع MPTCP، ثم لكل ما يستقبل TCP وارد، وهذا يشمل تقريبًا كل شيء. الحاويات لن تنقذك، فهي تشارك نواة المضيف، لذا صحّح العُقد.

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