تقنية SFOP هي نوع من هجمات إعادة استخدام الشيفرة (Code‑Reuse Attacks)، لكنها تعمل بطريقة مختلفة عن الأساليب التقليدية مثل Return‑Oriented Programming (ROP).

بدلاً من التلاعب بعناوين العودة داخل المكدس، يعتمد SFOP على فكرة أبسط ولكنها ذكية: إحداث سلسلة متعمدة من أخطاء segmentation fault داخل البرنامج.

في السيناريو النموذجي للهجوم:

• يقوم المهاجم بإجبار البرنامج على الوصول إلى موقع ذاكرة غير مسموح به.
• يؤدي ذلك إلى إطلاق خطأ Segmentation Fault.
• يقوم لينكس بإرسال إشارة SIGSEGV وتشغيل معالج الإشارة الخاص بالبرنامج.
• يستخدم المهاجم هذا المعالج لإعداد الخطوة التالية من الهجوم.

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

لماذا يفترض أن تمنع Intel CET هذه الهجمات؟

قدمت Intel تقنية CET كآلية دفاع عتادية ضد هجمات إعادة استخدام الشيفرة.

وتعتمد CET على عدة آليات، من أبرزها:

• التحقق من صحة عناوين العودة عبر Shadow Stack.
• تقييد القفزات غير المباشرة لمنع تنفيذ تعليمات غير متوقعة.

الهدف من هذه الآليات هو منع المهاجم من تغيير تدفق التنفيذ (Control Flow) داخل البرنامج بشكل غير مشروع.

لكن المشكلة أن CET صُممت أساساً لمراقبة انتقالات التنفيذ داخل مسار البرنامج الطبيعي.

وهنا يأتي دور SFOP.

كيف يتجاوز SFOP حماية CET في لينكس

الفكرة الأساسية للهجوم أن انتقال التنفيذ إلى معالج الإشارة هو انتقال شرعي يديره نظام التشغيل.

وبالتالي يمكن للهجوم استغلال هذا السلوك دون خرق القواعد التي تتحقق منها CET.

الخطوات المبسطة للهجوم تكون عادة كالتالي:

1. يجبر المهاجم البرنامج على الوصول إلى ذاكرة محظورة.
2. يحدث خطأ Segmentation Fault.
3. يرسل لينكس إشارة SIGSEGV ويحول التنفيذ إلى معالج الإشارة.
4. يقوم المعالج بتنفيذ خطوة جديدة يحددها المهاجم – غالباً إعداد خطأ جديد.
5. يتكرر السيناريو عدة مرات.

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

ومع تكرار هذه الدورة يمكن للمهاجم في النهاية تجميع سلسلة من العمليات تؤدي إلى تنفيذ تعليمات برمجية تعسفية داخل البرنامج المستهدف.

دور آلية SIGSEGV في لينكس

في لينكس، يمكن للتطبيقات تسجيل معالجات إشارات (Signal Handlers) للتعامل مع أخطاء مثل SIGSEGV. وغالباً تستخدم هذه المعالجات لتسجيل الخطأ أو محاولة الاسترداد.

هجوم SFOP يستغل هذا السلوك تحديداً عبر:

• التسبب المتعمد في أخطاء segmentation fault
• تشغيل معالج الإشارة في كل مرة
• تعديل حالة البرنامج تدريجياً

وبذلك تتحول آلية معالجة الأخطاء نفسها إلى أداة لبناء تسلسل تحكم في التنفيذ يمكن للمهاجم استخدامه خطوة بعد خطوة.

وسائل الدفاع المقترحة

يشير الباحثون إلى عدة استراتيجيات يمكن أن تقلل من خطر هذا النوع من الهجمات.

تقوية نواة لينكس

أحد الحلول المقترحة يتمثل في تعديلات على طريقة تعامل نواة لينكس مع الإشارات، بهدف تقليل قدرة المهاجم على استخدام أخطاء segmentation fault المتكررة كآلية للتحكم في التنفيذ.

تشير التقارير العامة إلى وجود مقترحات لتحديثات على مستوى النواة، لكن التفاصيل التقنية الكاملة لهذه التعديلات لم تُنشر بعد بشكل واسع في التقارير المتاحة.

طبقة الحماية PLaTypus

الحل الآخر الذي اقترحه الباحثون هو آلية تقوية تسمى PLaTypus.

تركز هذه الطبقة على مشكلة مهمة في هجمات إعادة استخدام الشيفرة: القفز بين مكتبات البرنامج المختلفة.

أظهرت الأبحاث أن المهاجمين ما زالوا قادرين على تحويل التنفيذ بين مكتبات متعددة حتى مع تفعيل CET. لذلك يقوم PLaTypus بما يلي:

• تقييد القفزات غير المباشرة بين المكتبات المختلفة
• السماح بالانتقالات فقط عندما تكون مصرحاً بها
• إبقاء معظم الانتقالات داخل نفس المكتبة

ووفقاً للتقارير البحثية، يمكن لهذه الآلية تقليل أهداف التحكم في التدفق بين المكتبات بأكثر من 98% مع تأثير ضئيل جداً على الأداء أثناء التشغيل.

لماذا يعد هذا الاكتشاف مهماً

يوضح بحث SFOP درساً مهماً في مجال أمن الأنظمة: الحماية العتادية وحدها لا تكفي إذا كان بإمكان المهاجم استغلال سلوكيات شرعية في نظام التشغيل.

فحتى مع وجود تقنيات متقدمة مثل Intel CET، قد تظهر ثغرات عندما تتفاعل طبقات مختلفة من النظام – مثل المعالج ونظام التشغيل وآليات معالجة الأخطاء – بطرق غير متوقعة.

لذلك يشير الباحثون إلى أن الدفاعات المستقبلية يجب أن تُصمم بالنظر إلى السلسلة الكاملة للنظام: من المعالج إلى النواة وصولاً إلى التطبيقات والمكتبات.

فالمهاجمون غالباً لا يحتاجون إلى كسر كل الحمايات — يكفيهم العثور على مسار واحد يسمح بالالتفاف حولها.

تقنية SFOP هي نوع من هجمات إعادة استخدام الشيفرة (Code‑Reuse Attacks)، لكنها تعمل بطريقة مختلفة عن الأساليب التقليدية مثل Return‑Oriented Programming (ROP).

بدلاً من التلاعب بعناوين العودة داخل المكدس، يعتمد SFOP على فكرة أبسط ولكنها ذكية: إحداث سلسلة متعمدة من أخطاء segmentation fault داخل البرنامج.

في السيناريو النموذجي للهجوم:

• يقوم المهاجم بإجبار البرنامج على الوصول إلى موقع ذاكرة غير مسموح به.
• يؤدي ذلك إلى إطلاق خطأ Segmentation Fault.
• يقوم لينكس بإرسال إشارة SIGSEGV وتشغيل معالج الإشارة الخاص بالبرنامج.
• يستخدم المهاجم هذا المعالج لإعداد الخطوة التالية من الهجوم.

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

لماذا يفترض أن تمنع Intel CET هذه الهجمات؟

قدمت Intel تقنية CET كآلية دفاع عتادية ضد هجمات إعادة استخدام الشيفرة.

وتعتمد CET على عدة آليات، من أبرزها:

• التحقق من صحة عناوين العودة عبر Shadow Stack.
• تقييد القفزات غير المباشرة لمنع تنفيذ تعليمات غير متوقعة.

الهدف من هذه الآليات هو منع المهاجم من تغيير تدفق التنفيذ (Control Flow) داخل البرنامج بشكل غير مشروع.

لكن المشكلة أن CET صُممت أساساً لمراقبة انتقالات التنفيذ داخل مسار البرنامج الطبيعي.

وهنا يأتي دور SFOP.

كيف يتجاوز SFOP حماية CET في لينكس

الفكرة الأساسية للهجوم أن انتقال التنفيذ إلى معالج الإشارة هو انتقال شرعي يديره نظام التشغيل.

وبالتالي يمكن للهجوم استغلال هذا السلوك دون خرق القواعد التي تتحقق منها CET.

الخطوات المبسطة للهجوم تكون عادة كالتالي:

1. يجبر المهاجم البرنامج على الوصول إلى ذاكرة محظورة.
2. يحدث خطأ Segmentation Fault.
3. يرسل لينكس إشارة SIGSEGV ويحول التنفيذ إلى معالج الإشارة.
4. يقوم المعالج بتنفيذ خطوة جديدة يحددها المهاجم – غالباً إعداد خطأ جديد.
5. يتكرر السيناريو عدة مرات.

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

ومع تكرار هذه الدورة يمكن للمهاجم في النهاية تجميع سلسلة من العمليات تؤدي إلى تنفيذ تعليمات برمجية تعسفية داخل البرنامج المستهدف.

دور آلية SIGSEGV في لينكس

في لينكس، يمكن للتطبيقات تسجيل معالجات إشارات (Signal Handlers) للتعامل مع أخطاء مثل SIGSEGV. وغالباً تستخدم هذه المعالجات لتسجيل الخطأ أو محاولة الاسترداد.

هجوم SFOP يستغل هذا السلوك تحديداً عبر:

• التسبب المتعمد في أخطاء segmentation fault
• تشغيل معالج الإشارة في كل مرة
• تعديل حالة البرنامج تدريجياً

وبذلك تتحول آلية معالجة الأخطاء نفسها إلى أداة لبناء تسلسل تحكم في التنفيذ يمكن للمهاجم استخدامه خطوة بعد خطوة.

وسائل الدفاع المقترحة

يشير الباحثون إلى عدة استراتيجيات يمكن أن تقلل من خطر هذا النوع من الهجمات.

تقوية نواة لينكس

أحد الحلول المقترحة يتمثل في تعديلات على طريقة تعامل نواة لينكس مع الإشارات، بهدف تقليل قدرة المهاجم على استخدام أخطاء segmentation fault المتكررة كآلية للتحكم في التنفيذ.

تشير التقارير العامة إلى وجود مقترحات لتحديثات على مستوى النواة، لكن التفاصيل التقنية الكاملة لهذه التعديلات لم تُنشر بعد بشكل واسع في التقارير المتاحة.

طبقة الحماية PLaTypus

الحل الآخر الذي اقترحه الباحثون هو آلية تقوية تسمى PLaTypus.

تركز هذه الطبقة على مشكلة مهمة في هجمات إعادة استخدام الشيفرة: القفز بين مكتبات البرنامج المختلفة.

أظهرت الأبحاث أن المهاجمين ما زالوا قادرين على تحويل التنفيذ بين مكتبات متعددة حتى مع تفعيل CET. لذلك يقوم PLaTypus بما يلي:

• تقييد القفزات غير المباشرة بين المكتبات المختلفة
• السماح بالانتقالات فقط عندما تكون مصرحاً بها
• إبقاء معظم الانتقالات داخل نفس المكتبة

ووفقاً للتقارير البحثية، يمكن لهذه الآلية تقليل أهداف التحكم في التدفق بين المكتبات بأكثر من 98% مع تأثير ضئيل جداً على الأداء أثناء التشغيل.

لماذا يعد هذا الاكتشاف مهماً

يوضح بحث SFOP درساً مهماً في مجال أمن الأنظمة: الحماية العتادية وحدها لا تكفي إذا كان بإمكان المهاجم استغلال سلوكيات شرعية في نظام التشغيل.

فحتى مع وجود تقنيات متقدمة مثل Intel CET، قد تظهر ثغرات عندما تتفاعل طبقات مختلفة من النظام – مثل المعالج ونظام التشغيل وآليات معالجة الأخطاء – بطرق غير متوقعة.

لذلك يشير الباحثون إلى أن الدفاعات المستقبلية يجب أن تُصمم بالنظر إلى السلسلة الكاملة للنظام: من المعالج إلى النواة وصولاً إلى التطبيقات والمكتبات.

فالمهاجمون غالباً لا يحتاجون إلى كسر كل الحمايات — يكفيهم العثور على مسار واحد يسمح بالالتفاف حولها.