مثال في دليل إعداد AWS REX خلّف وثائق SSM قابلة لحقن الأوامر

ماذا حدث

نشرت AWS النشرة الأمنية 2026-173-AWS في 11/06/2026 الساعة 09:00 AM PST. وتتناول النشرة CVE-2026-122193، وهي ثغرة أمنية من نوع حقن أوامر نظام التشغيل في مثال ضمن وثائق إعداد Trusted Remote Execution (REX). وتصنّف AWS النشرة بأنها «Important (requires attention)»، أي مهمة وتتطلب الانتباه. كما تشير النشرة إلى GHSA-95g5-m242-wvhr.

REX إطار عمل مفتوح المصدر لتشغيل سكربتات معزولة (sandboxed) على المثيلات المُدارة. وتصف AWS سياسة Cedar الموقّعة بأنها «حدّ الأمان غير القابل للتغيير الذي يحيط بكل تشغيل لسكربت». وكان السكربت المثال في الدليل ينشئ مستندَين من Systems Manager هما Rex-RO وRex-RW، يشغّلان سكربتات REX على المثيلات المُدارة.

تكمن الثغرة في طريقة تعامل السكربت المثال مع معاملات الإدخال. فبإمكان مستخدم يملك صلاحية استدعاء أحد مستندات SSM هذه أن يمرّر مدخلات مُعدّة خصيصًا تؤدي إلى تشغيل أوامر نظام تشغيل غير مقصودة على المثيل المُدار، خارج بيئة REX المعزولة. وتقول AWS إن المعامل scriptArgs يعاني الفئة نفسها من المشكلات.

تؤكد AWS أنه لا يوجد أي إصدار منشور من مكوّنات REX متأثر. فالمشكلة في مثال الوثائق، وكل من أنشأ مستندات Rex-RO أو Rex-RW باتباع الدليل متأثر.

وتقول AWS إنها أزالت المثال من الدليل، وتوصي بحذف أي مستندات SSM من هذا النوع في كل حساب وكل منطقة (Region) شُغّل فيها المثال. ولا تذكر أي حلول بديلة مؤقتة.

نشرة AWS هي المصدر الأساسي. ويُدرج سجل NVD درجة CVSS أساسية قدرها 9.3، وحالته Received. ويقول NVD إن الثغرة قد تسمح بتشغيل أوامر عشوائية بصلاحيات root على المثيل المُدار، متجاوزةً فرض سياسات Cedar. ويشير وصفه إلى سكربت التهيئة المثال «before 2026-07-28» (أي قبل 2026-07-28).

تحديث: تؤكد نشرة GitHub الأمنية GHSA-95g5-m242-wvhr، المنشورة في 6 نوفمبر 2026، رواية AWS: فمستندات SSM المثال هي العنصر المتأثر، وقد أُزيل المثال، ولا يوجد تصحيح برمجي ولا حلول بديلة مؤقتة. وتكرر النشرة العلاج نفسه، أي حذف المستندات في كل حساب وكل منطقة. وتصنّف المشكلة بأنها Critical (حرجة)، وتعرض درجة CVSS إجمالية قدرها 9.9 مع المتجه CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H، وتصنّف نقطة الضعف ضمن CWE-78. وتُدرج البيانات الوصفية للحزمة فيها rex-runner (Rust) بإصدار متأثر 0.1.0 وإصدار مُصحِّح 0.1.0، بينما لا يزال نصها يقول إن هذه «ليست مشكلة في إصدار منشور من مكوّنات REX».

لماذا يهم

جوهر REX أن سياسة Cedar الموقّعة تقيّد ما يمكن لتشغيل السكربت فعله. أما هذه الثغرة فتقع في آلية التسليم المحيطة بهذا الحد. فمن يستطيع استدعاء مستند SSM يحصل على تنفيذ أوامر على المضيف دون المرور بالبيئة المعزولة. ويقول NVD إن الثغرة قد تسمح بتشغيل الأوامر بصلاحيات root. وضمانة «التنفيذ عن بُعد في بيئة معزولة» لا تصمد لدى أي جهة تشغّل المستندات المثال.

المشكلة التشغيلية هي الاكتشاف. فهذه ليست حزمة ولا إصدارًا:

• لا تستطيع npm ls ولا pip list ولا قوائم مكونات البرمجيات (SBOM) ولا أدوات فحص الحاويات ولا أدوات رصد الثغرات المعتمدة على الإصدارات رؤية مستندات SSM في حساباتك.
• تذكر البيانات الوصفية لنشرة GitHub الحزمة rex-runner 0.1.0 بوصفها متأثرة ومُصحَّحة في آن واحد. وقد ترفع الأدوات التي تقرأ بيانات نشرات GitHub تنبيهًا بشأن تلك الحزمة. لكن هذا التنبيه لا يقول شيئًا عن وجود مستندات SSM في حساباتك، والنتيجة النظيفة لا تعني أنك بمأمن.
• لا يوجد إصدار مُصحِّح يمكن الترقية إليه.
• درجة التعرض هي ببساطة مستندات SSM الموجودة في حساباتك، التي أنشأها من نسخ الدليل أيًّا كان.
• تبقى هذه المستندات قائمة بعد تغيّر الدليل. فإزالة المثال من الوثائق لا تفعل شيئًا للمستندات المنشورة بالفعل.

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

تتباين تصنيفات الخطورة الآن. فـAWS تصنّف النشرة «Important» ولا تنشر أي درجة. وتصنّفها GitHub بأنها Critical بدرجة CVSS إجمالية قدرها 9.9 ومتجه يشير إلى هجوم عبر الشبكة، وصلاحيات مطلوبة منخفضة، ودون تفاعل من المستخدم، ونطاق متغيّر، وأثر مرتفع على السرية والسلامة والتوافر. ويُدرج NVD الدرجة 9.3 في سجل حالته Received وقد يتغيّر. وقد تعرض أدوات الفحص ولوحات المتابعة 9.9 أو 9.3 أو «Important» للثغرة نفسها، ولا يشرح أي مصدر سبب الاختلاف. والإجراء المطلوب واحد أيًّا كان الرقم الذي تعرضه أدواتك.

التقييم الهندسي

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

تعتمد درجة التعرض على من يستطيع استدعاء المستندات، لا على إمكانية الوصول عبر الشبكة. فيجب أن يكون المهاجم حائزًا مسبقًا صلاحية تشغيل المستند Rex-RO أو Rex-RW. قد يبدو هذا قيدًا، لكن REX وُجدت أصلًا كي يتمكن أشخاص بصلاحيات محدودة ومقيّدة بالسياسات من تشغيل السكربتات. ومن المرجّح أن يكون المستخدمون الممنوحون صلاحيات الاستدعاء هم أنفسهم من صُمّمت سياسة Cedar لتقييدهم. وإذا كانت هذه الصلاحيات قد حُدّدت للمشغّلين أو موظفي الدعم أو أدوار الأتمتة على افتراض أن Cedar ستحتويهم، فينبغي معاملة هذه الجهات على أنها امتلكت قدرة تنفيذ أوامر على مستوى المضيف. ويقول NVD إن الثغرة قد تسمح بتشغيل الأوامر بصلاحيات root. ويتسق تصنيف GitHub بنطاق متغيّر مع هذه القراءة: فالأثر يتجاوز المكوّن الذي كان يُفترض أن يبقى المستدعي محصورًا فيه.

التكلفة الحقيقية هي الانتشار عبر حسابات ومناطق متعددة. فتعليمات AWS صريحة في أنها لكل حساب ولكل منطقة. والمؤسسات التي تستخدم AWS Organizations أو مناطق الهبوط (landing zones) أو آليات توفير الحسابات (account vending) ربما كررت المثال على نطاق واسع، وأحيانًا عبر البنية التحتية كتعليمات برمجية (IaC) التي ستعيد إنشاء المستندات في عملية النشر التالية. وحذف المستندات دون إزالتها أيضًا من Terraform أو CloudFormation أو CDK أو سكربتات التهيئة الأولية لن يدوم.

وهناك أيضًا فجوة فيما تقدّمه AWS. فحذف المستندات يزيل درجة التعرض، لكنه يترك مستخدمي REX دون مسار التهيئة الذي وفّره لهم الدليل. ولا يذكر أي من المصادر مثالًا مُصحَّحًا. ويتعيّن على الفرق التي لا تزال تحتاج إلى REX أن تبني تكاملها الخاص مع SSM، وأن تعامل معالجة المعاملات بوصفها شيفرة حرجة أمنيًا. وبحذر: إلى أن تنشر AWS بديلًا، افترض أن أي غلاف (wrapper) مطوّر داخليًا يحتاج إلى مراجعة أمنية مستقلة.

لا تتوافق صياغة NVD «before 2026-07-28» توافقًا واضحًا مع تأكيد AWS أنه لا يوجد مكوّن ذو إصدار متأثر، كما تضيف البيانات الوصفية لـrex-runner 0.1.0 في نشرة GitHub إشارة ثانية شبيهة بالإصدار تناقض نص النشرة نفسها. لا تعتمد على التاريخ ولا على إصدار الحزمة لإدراج المستندات أو استبعادها. وينبغي معاملة المستندات المُنشأة من المثال في أي وقت على أنها متأثرة، ما لم تستطع إثبات أنها بُنيت بطريقة مختلفة.

هل يعنيك هذا؟

• هل اعتمد أحد في مؤسستك AWS Trusted Remote Execution (REX)؟
• هل تحتوي أي حسابات على مستندات SSM مملوكة ذاتيًا باسم Rex-RO أو Rex-RW، أو مستندات مشتقة منها تحت اسم آخر؟
• هل شغّل أحد سكربت التهيئة المثال من دليل إعداد REX، أو نسخه إلى البنية التحتية كتعليمات برمجية، أو إلى خطوط الأساس للحسابات، أو إلى خطوط التهيئة الأولية؟
• هل تملك أي جهات IAM صلاحية إرسال أوامر باستخدام هذه المستندات، وهل مُنحت هذه الصلاحيات على افتراض أن سياسات Cedar ستقيّدها؟
• هل تدير عدة حسابات أو مناطق في AWS ربما شُغّل فيها المثال بشكل منفصل؟

إذا كانت إجابتك نعم عن السؤال الثاني أو الثالث، فأنت متأثر.

ما الذي ينبغي فعله

1. اجرد الآن، لكل حساب ولكل منطقة. اعرض مستندات SSM المملوكة ذاتيًا وابحث عن Rex-RO أو Rex-RW أو مشتقاتهما:
   • aws ssm list-documents --filters Key=Owner,Values=Self --region <region>
   • aws ssm describe-document --name Rex-RO --region <region>
   • ليس من إرشادات المورّد: كرّر العملية على كل منطقة مفعّلة (aws ec2 describe-regions) وكل حساب في مؤسستك، لا على الحسابات التي تتوقعها فقط.
2. احذف المستندات المتأثرة. هذا هو العلاج الذي توصي به AWS، وكرّره NVD ونشرة GitHub: aws ssm delete-document --name Rex-RO --region <region>، والأمر نفسه لـRex-RW، في كل حساب وكل منطقة شُغّل فيها المثال.
3. أزل المصدر. ليس من إرشادات المورّد: ابحث في مستودعات IaC وخطوط الأساس لتوفير الحسابات وسكربتات التهيئة الأولية عن السكربت المثال أو أسماء هذه المستندات. وأزلها كي لا يُعاد إنشاؤها.
4. راجع صلاحيات الاستدعاء. ليس من إرشادات المورّد: حدّد الجهات التي كان بإمكانها تشغيل هذه المستندات. وضيّق أي صلاحيات لم تكن موجودة إلا لدعمها.
5. راجع ما سبق. ليس من إرشادات المورّد: إذا كانت المستندات موجودة، فراجع سجل أوامر Systems Manager وCloudTrail بحثًا عن استدعاءاتها، مع التركيز على قيم المعاملات غير المعتادة في scriptArgs وغيرها من المدخلات. ولا تقدّم AWS أي إرشادات للاكتشاف. وعامل المضيفات التي لا يمكن تفسير الاستدعاءات عليها بوصفها بحاجة إلى مراجعة حوادث.
6. خطط للبديل. ليس من إرشادات المورّد: ينبغي للقادة التقنيين أن يقرروا ما إذا كانت REX لا تزال مطلوبة. وإن كانت كذلك، فعامل كل معامل يقدّمه المستدعي، بما في ذلك scriptArgs، على أنه غير موثوق، ولا تسمح له أبدًا بالوصول إلى تنفيذ الأوامر دون تحقق، واحرص على مراجعة التصميم قبل الطرح.

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

ما لا نعرفه بعد

• إساءة الاستخدام: لا تتناول AWS ولا NVD ولا نشرة GitHub ما إذا كانت المستندات المتأثرة قد أُسيء استخدامها.
• الصلاحيات: لا تحدد المصادر بدقة صلاحيات IAM التي تتيح الاستدعاء، ولا مدى اتساع منحها عادةً.
• تاريخ NVD: لم يُوضَّح ما الذي تشير إليه عبارة «before 2026-07-28» في وصف NVD، علمًا بأن AWS لا تذكر أي إصدار أو تاريخ متأثر.
• البيانات الوصفية للحزمة: لم يُوضَّح سبب إدراج نشرة GitHub الحزمة rex-runner 0.1.0 بوصفها متأثرة ومُصحَّحة معًا، بينما يقول نصها إنه لا يوجد مكوّن منشور متأثر ولا يوجد تصحيح برمجي.
• البديل: لا يوجد أي حديث عن مثال مُصحَّح أو طريقة تهيئة مدعومة.
• الاكتشاف: لا تقدّم المصادر أي إرشادات للاكتشاف أو التحليل الجنائي.
• الدرجة: تعرض GitHub درجة CVSS إجمالية قدرها 9.9 (Critical)، ويُدرج NVD الدرجة 9.3 في سجل حالته Received وقد يتغيّر، ولا تنشر AWS أي درجة وتصنّف النشرة «Important». ولا يشرح أي مصدر سبب الاختلاف.

سيتابع المكتب نشرة AWS والنشرة GHSA-95g5-m242-wvhr بحثًا عن تحديثات بشأن مثال بديل وإرشادات للاكتشاف والبيانات الوصفية للحزمة. كما سيتابع سجل NVD مع تقدّم التحليل. ومزيد من التغطية متاح في صفحة أخبار مكتب الهندسة.

المصادر

• aws.amazon.com
• aws.amazon.com
• github.com
• NVD