ثغرات AWS SAM CLI (CVE-2025-3047 & CVE-2025-3048)

يقدّم ملف README هذا تحليلًا تفصيليًا لثغرتين أمنيتين تم اكتشافهما في واجهة الأوامر السطرية لنموذج التطبيقات الخادمة من AWS (AWS SAM CLI) – CVE-2025-3047 وCVE-2025-3048 – إلى جانب المشكلات على مستوى الكود والإصلاحات. تتعلق كلتا الثغرتين بمعالجة غير سليمة للروابط الرمزية (symlinks) أثناء عملية البناء باستخدام حاويات Docker. يغطي كل قسم أدناه ثغرة CVE واحدة مع ملخص، والكود المتأثر (مع مراجع إلى شيفرة SAM CLI المصدرية)، والتصحيح وكيفية حلّه للمشكلة، وإرشادات المعالجة.

ترتبط هذه العيوب بمعالجة غير سليمة للروابط الرمزية (symlinks) أثناء عملية sam build --use-container. تؤثر كلتا المشكلتين على بيئات التطوير المحلية (لا تؤثران على خدمات أو موارد AWS المنشورة)، إلا أنهما قد تسمحان بوصول غير مصرّح به إلى ملفات على الجهاز المضيف من خلال إساءة استخدام طريقة معالجة AWS SAM CLI للروابط الرمزية. يُنصح بشدة بترقية AWS SAM CLI إلى الإصدارات المصححة (1.133.0+ لـ CVE-2025-3047، و1.134.0+ لـ CVE-2025-3048).

CVE-2025-3047 – تجاوز المسار عبر الروابط الرمزية في بناء الحاوية

GHSA-px37-jpqx-97q9 هي ثغرة تجاوز مسار في AWS SAM CLI <= v1.132.0 سمحت بوصول غير مصرّح به إلى الملفات على الجهاز المضيف أثناء sam build --use-container. عند بناء تطبيق خادم (serverless) داخل حاوية Docker، كان SAM CLI يتبع الروابط الرمزية في المشروع افتراضيًا. يمكن للمهاجم الذي يزرع رابطًا رمزيًا ضارًا في المشروع (يشير إلى ملف حساس على المضيف) استغلال الصلاحيات المرتفعة لحاوية Docker لجعل هذا الملف يُركَّب داخل الحاوية ويُنسخ إلى موقع يمكن الوصول إليه داخل الحاوية. في الواقع، كان هذا يعني إمكانية قراءة ملفات المضيف المقيّدة (خارج دليل المشروع) وإخراجها عبر حاوية البناء. تم إصلاح المشكلة في v1.133.0. (للحفاظ على التوافق مع الإصدارات السابقة للحالات المشروعة، قدّم SAM CLI v1.133.0 علامة اختيارية --mount-symlinks لإعادة تفعيل السلوك القديم عند الحاجة.)

السبب الجذري والمكوّن المتأثر: تكمن المشكلة الأساسية في كيفية تركيب AWS SAM CLI لأدلة المشروع وروابطها الرمزية في حاوية Docker المستخدمة للبناء. في كود AWS SAM CLI (الوحدة samcli.local.docker.container)، قبل التصحيح، كانت جميع الروابط الرمزية ذات المستوى الأعلى في دليل المشروع تُحلَّل وتُركَّب تلقائيًا في الحاوية بنفس الصلاحيات المرتفعة التي تتمتع بها عملية الحاوية. تعمل الحاوية كـ root افتراضيًا، لذا فإن حلّ رابط رمزي يشير إلى مسار حساس على المضيف وتركيبه كان يمنح الحاوية وصولاً إلى هذا الملف، وهو ما لا يملكه مستخدم المضيف غير المتميز عادةً. لم يقيّد الكود الضعيف بشكل كافٍ الروابط الرمزية التي يجب اتباعها/تركيبها.

تحديدًا، في الدالة التي تنشئ تركيبات وحدات تخزين Docker للبناء، كان SAM CLI يتعامل بشكل غير مشروط مع الروابط الرمزية كملفات/أدلة فعلية لتركيبها. كانت الثغرة تكمن في منطق تنسيق الحاويات في SAM CLI، وتحديدًا في طريقة Container.create في samcli/local/docker/container.py. في الإصدارات الضعيفة، كانت هذه الطريقة تحاول دائمًا حلّ وتركيب أهداف الروابط الرمزية من المشروع إلى حاوية Docker، بغض النظر عن السياق. يظهر الكود المُشكِل أدناه، من SAM CLI v1.132.0:

# samcli/local/docker/container.py (v1.132.0 - vulnerable snippet)
if self._host_dir:
    mount_mode = "rw,delegated" if self._mount_with_write else "ro,delegated"
    LOG.info("Mounting %s as %s:%s, inside runtime container", self._host_dir, self._working_dir, mount_mode)
_volumes = {
    self._host_dir: {
        "bind": self._working_dir,
        "mode": mount_mode,
    },
    **self._create_mapped_symlink_files(),  # Always resolve and mount symlinks (vulnerable) 
}

في الكود أعلاه، تقوم _create_mapped_symlink_files() بفحص الروابط الرمزية داخل دليل المشروع وتجهيزها للتركيب. ولأن هذا كان مُدرجًا بشكل غير مشروط، فإن جميع الروابط الرمزية (بما في ذلك تلك التي تشير إلى خارج المشروع) كانت ستُركَّب في الحاوية. (انظر aws/aws-sam-cli#7865)

تكمن المشكلة هنا في أنه أثناء sam build --use-container, كان SAM CLI يتعامل مع الروابط الرمزية كملفات يجب تركيبها في الحاوية. إذا كان الرابط الرمزي يشير، على سبيل المثال، إلى /etc/shadow على المضيف، فإن حاوية Docker (التي قد تعمل بصلاحيات مرتفعة) كانت ستركّب هذا الملف. هذا هو أسلوب تجاوز المسار القائم على الروابط الرمزية الكلاسيكي، مما يؤدي إلى تصعيد الامتيازات – حيث يمكن قراءة ملفات المضيف التي لا يملك المستخدم وصولاً إليها عادةً بواسطة الحاوية ثم تظهر في مخرجات البناء.

التصحيح (الكود المُصحح في v1.133.0): يقدّم الإصلاح مفهوم سياق البناء ويعطّل حلّ الروابط الرمزية أثناء عمليات بناء الحاويات. في الإصدار المُصحح، تأخذ Container.create معاملًا إضافيًا يحدد السياق (BUILD مقابل INVOKE)، ولن تحلّ الروابط الرمزية إلا إذا كان السياق هو الاستدعاء (عند تشغيل الدوال محليًا)، وليس أثناء البناء. فيما يلي الكود المُصحح من الإصدار المُصحح:

# samcli/local/docker/container.py (v1.133.0+ - patched snippet)
if self._host_dir:
    mount_mode = "rw,delegated" if self._mount_with_write else "ro,delegated"
    LOG.info("Mounting %s as %s:%s, inside runtime container", self._host_dir, self._working_dir, mount_mode)
    mapped_symlinks = self._create_mapped_symlink_files() if self._resolve_symlinks(context) else {} 
_volumes = {
    self._host_dir: {
        "bind": self._working_dir,
        "mode": mount_mode,
    },
    **mapped_symlinks,  # Only mount symlinks if explicitly allowed by context (not in build) 
}

في الكود المُصحح، يتم تغليف _create_mapped_symlink_files() خلف فحص للسياق. يحدد تعداد ContainerContext الجديد سياقات مثل BUILD وINVOKE، وتُرجع _resolve_symlinks(context) القيمة False لسياق البناء. وبالتالي، ستكون mapped_symlinks قاموسًا فارغًا أثناء البناء، مما يعني عدم تركيب أي روابط رمزية في الحاوية افتراضيًا.

مرجع تغيير الكود: تم تنفيذ الإصلاح في Pull Request#7865 (“إصلاح: حلّ الروابط الرمزية في الاستدعاء المحلي فقط”) وتم إصداره كجزء من v1.133.0. يُظهر الفرق في GitHub تقديم ContainerContext ومنطق التركيب الشرطي. بعدم تركيب أهداف الروابط الرمزية أثناء البناء، لم تعد الحاوية تحصل على وصول إلى ملفات خارج دليل المشروع. (إذا أراد المستخدم بالفعل السماح بروابط رمزية إلى مسارات المضيف، فعليه الآن الاشتراك صراحةً عبر علامة --mount-symlinks، التي أُضيفت بعد هذا الإصلاح.)

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

المعالجة: يجب على جميع المستخدمين الترقية إلى AWS SAM CLI v1.133.0 أو إصدار أحدث للحصول على هذا الإصلاح. بعد الترقية، يكون السلوك الافتراضي آمنًا. فقط إذا كنت تثق صراحةً في مشروعك وتحتاج إلى السلوك القديم، يجب عليك استخدام sam build --use-container --mount-symlinks. بالنسبة لمعظم المطورين، يُوصى بترك هذه العلامة معطّلة (الافتراضي) لضمان عدم قدرة الروابط الرمزية على تجاوز مساحة العمل. ومن الممارسات الجيدة أيضًا مراجعة أي روابط رمزية في مشاريعك للتأكد من أنها لا تشير إلى مواقع حساسة.

AWS-SAM-CLI-Vulnerabilities

الأكثر شعبية

ثغرات AWS SAM CLI (CVE-2025-3047 & CVE-2025-3048)

CVE-2025-3047 – تجاوز المسار عبر الروابط الرمزية في بناء الحاوية