1Seal

يوجد تجاوز في التحقق من التوقيع في الدالة `verifyImages()`. تحدث هذه المشكلة لأن نتائج التحقق المخزنة مؤقتًا يتم فهرستها بواسطة سلسلة مرجع الصورة، مثل العلامة (tag)، بدلاً من ربطها بالملخص (digest) الذي تم التحقق منه. وبناءً على ذلك، تؤدي الإصابات في ذاكرة التخزين المؤقت إلى تخطي فحوصات التوقيع والتصديق. يمكن للمهاجم الذي يستطيع تقديم أعباء عمل وتغيير علامة السجل ملء ذاكرة التخزين المؤقت بصورة موقعة، ثم إعادة توجيه العلامة، مما يجعل النظام يقبل عبء العمل ويستخدم `mutateDigest` لتثبيت الملخص غير المتحقق منه.

توجد مشكلة إلغاء ضغط غير محدود في الدالة `extractStatement()`. يمكن للمهاجمين عن بُعد التسبب في حجب الخدمة عن طريق تقديم طبقات تصديق مضغوطة للغاية عبر مراجع سجلات العناصر. عندما يتم إلغاء ضغط طبقات التنبؤ gzip هذه، يمكن أن تتجاوز `maxPayloadSize` مما يؤدي إلى إنهاء وحدة التحكم في القبول بسبب نفاد الذاكرة (OOM kills).

توجد مشكلة إلغاء ضغط غير محدود في الدالة `FetchSignatureBlob()`. يمكن للمهاجمين الذين يتحكمون في مراجع السجل أو التواقيع تقديم طبقات توقيع موثقة مضغوطة للغاية. يمكن أن يتم فك ضغط طبقات gzip الصغيرة هذه بما يتجاوز المتغير `maxPayloadSize` مما يؤدي إلى استنفاد الذاكرة، وعمليات قتل بسبب نقص الذاكرة (OOM kills) لوحدة التحكم في القبول، مما يتسبب في حجب الخدمة.

An unbounded memory allocation issue exists where attackers can exhaust JVM memory by declaring a large uncompressed length in compressed input. By providing crafted bytes to the `uncompress()`, `uncompressString()`, `SnappyInputStream`, or `SnappyFramedInputStream` functions, an attacker can force allocations up to 2 GB, leading to an OutOfMemoryError and a denial of service.

يحدث تجاوز لقيود الأسماء عند استخدام نقطة في نهاية `rfc822Name` و URI. قيود الأسماء هي آلية تُستخدم في الشهادات لتقييد نطاق الأسماء التي يُعتمد على سلطة إصدار الشهادات في إصدار شهادات لها.

أثناء عملية تحميل الكتل (blob) المتجانسة، يتبع البرنامج رأس `Location` الذي يتحكم فيه السجل ويعيد استخدام رأس `Authorization` من طلب `POST` الأولي في طلب `PUT` اللاحق. إذا قام سجل ضار بإرجاع `Location` عبر المضيف، فقد يتم إرسال بيانات اعتماد المتصل إلى نقطة نهاية يسيطر عليها المهاجم. تحدث هذه المشكلة داخل الدالة `blobStore.completePushAfterInitialPost()` الموجودة في `registry/remote/repository.go`. وقد يؤدي ذلك إلى تسرب بيانات الاعتماد وتزوير الطلبات من جانب الخادم (SSRF) من جانب العميل، حيث يتم خداع الخادم لإرسال طلبات إلى وجهة غير مقصودة.

توجد مشكلة في مرشح UDP DNS عند تهيئته مع تحليل محلي أو عن بُعد لأسماء يبلغ طولها 255 بايت بالضبط. يؤدي الاستعلام الذي يحتوي على اسم من هذا النوع إلى إنهاء العملية بشكل غير طبيعي بسبب شرط مسبق غير صالح في وقت التشغيل يتطلب أن يكون اسم الاستعلام أقل من 255 بايت بدقة، وهو ما يتعارض مع مواصفات DNS rfc1035#section-2.3.4 التي تسمح بأسماء يصل طولها إلى 255 بايت.

يمكن لأحد أقران BLE عن بُعد وغير مصدق عليه أن يُحدث عملية كتابة خارج النطاق بحجم 2 بايت في مضيف Bluetooth أثناء إعادة تجميع L2CAP LE CoC SDU. ويحدث هذا عندما يقوم التطبيق بتمكين التجزئة عبر `chan ops.alloc buf` ويكون حجم `user data size` لمجموعة RX المحددة أصغر من 2 بايت. في هذا السيناريو، يتم كتابة عداد التجزئة المخزن في منطقة user data الخاصة بـ `net buf` خارج النطاق المسموح به داخل الدالة `l2cap chan le recv seg()`. وقد يؤدي ذلك إلى تلف الذاكرة المؤقتة (heap) أو حدوث أخطاء فادحة.

في مكون اكتشاف الشبكة network-libp2p، يقبل النظام تحديثات PeerContact الموقعة من أقران غير موثوق بهم ويخزنها في دفتر جهات اتصال الأقران. ونظرًا لعدم وجود عملية تحقق للتأكد من أن قائمة العناوين ليست فارغة، يمكن للمهاجم إدراج جهة اتصال موقعة مع قائمة عناوين فارغة. عندما تحاول الدالة `known peers()` في `PeerContactBook` إنشاء دفتر عناوين، فإنها تستدعي `addresses.first().expect()`، مما يؤدي إلى حدوث حالة ذعر إذا كانت القائمة فارغة. ونتيجة لذلك، فإن أي استدعاء لنقطة النهاية ’get address book‘ عبر RPC أو عميل الويب يمكن أن يتسبب في تعطل العقدة أو مهمة RPC.

يقوم apko بالتحقق من التوقيع الموجود على ملف ’APKINDEX.tar.gz‘، لكنه يفشل في مقارنة حزم ’.apk‘ التي تم تنزيلها بشكل فردي مع المجموع الاختباري المسجل في الفهرس الموقع. على الرغم من تحليل المجموع الاختباري عبر `ChecksumString()` وحساب هاش التحكم في الحزمة التي تم تنزيلها، إلا أن هذه القيم لا تتم مقارنتها داخل دالة `getPackageImpl()`. وهذا يسمح بقبول الحزم غير المتطابقة دون إشعار. يمكن للمهاجم القادر على استبدال استجابات التنزيل، مثلًا من خلال مرآة مخترقة أو مستودع HTTP أو ذاكرة تخزين مؤقتة CDN ملوثة، تثبيت حزم تعسفية في الصور المُجمَّعة.

يمكن لملف .apk مُعدّ خصيصًا تثبيت إدخال tar من نوع `TypeSymlink` بحيث يشير الهدف إلى موقع خارج جذر البناء. ويمكن لعمليات إنشاء الدلائل أو كتابة الملفات اللاحقة في نفس الأرشيف أو في أرشيف لاحق أن تتجاوز هذا الرابط الرمزي للوصول إلى مسارات المضيف التي يمتلك مستخدم البناء إذنًا للكتابة فيها. تنشأ المشكلة من الأداة المساعدة `sanitizePath` الموجودة في `pkg/apk/fs/rwosfs.go`، والتي ترفض فقط التجاوز اللغوي لـ `..` وتفشل في حل أو رفض الروابط الرمزية. يؤثر هذا على أساليب `DirFS` المدعومة بالقرص التي تمرر المسارات التي يوفرها المستدعي إلى استدعاءات المكتبة القياسية التي تتبع الروابط الرمزية، بما في ذلك `ReadFile()` و`WriteFile()` و`Chmod()` و`Chown()` و`Chtimes()` و`MkdirAll()` و`Mkdir()` و`Mknod()`. العنصر الأساسي الذي يمكن الوصول إليه أثناء استخراج ملفات tar هو سلسلة `MkdirAll()` / `Mkdir()` / `WriteFile()` عبر `apko build-cpio` والمستهلكين المدعومين بالقرص مثل `melange`.

تقوم الدالة `DiscoverKeys()` الموجودة في الملف `pkg/apk/apk/implementation.go` بإجراء تأكيد نوع غير مشروط لمفاتيح JWKS (مجموعة مفاتيح JSON على الويب) على أنها `*rsa.PublicKey` دون التحقق من نوع المفتاح. إذا عادت نقطة نهاية JWKS في المستودع بمفتاح غير RSA، مثل مفتاح المنحنى الإهليلجي (EC)، فإن عملية التأكيد غير المدققة تتسبب في حدوث حالة ذعر وتعطل التطبيق. ويؤثر ذلك على أي سير عمل يقوم بتهيئة قاعدة بيانات APK واسترداد مفاتيح المستودع.

تسمح الإصلاحات غير الكاملة لمشكلة «اجتياز المسار» (path traversal) للمستخدمين المصادق عليهم عن بُعد والذين يتمتعون بسلطة توقيع مفوضة بكتابة ملفات خارج دلائل الإخراج المقصودة. ويحدث ذلك لأن مسارات الكتابة تثق في مسار الوجهة المضمَّن دون إجراء تحقق احتوائي بعد التحليل. يمكن إثارة هذه المشكلة عبر أسماء الأهداف المطلقة في ’copy target/link target‘، أو الدلائل الأصلية المرتبطة برموز رمزية في ’save target‘، أو أسماء ملفات البيانات الوصفية المرتبطة برموز رمزية في الدالة `SignedRole::write`.

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

يمكن للمستخدمين المصادق عليهم عن بُعد والذين يتمتعون بسلطة التوقيع المفوضة تجاوز فحوصات سلامة مواصفات TUF الخاصة ببيانات تعريف الأهداف المفوضة وتلويث ذاكرة التخزين المؤقتة المحلية لبيانات التعريف. يحدث هذا لأن الدالة `load delegations()` لا تطبق نفس فحوصات التحقق المتعلقة بانتهاء الصلاحية والتجزئة وفرض الطول كما هو الحال في مسار بيانات تعريف الأهداف ذات المستوى الأعلى.

عند استخدام علامة الاشتراك الاختياري ’--persist-lint-results‘ عبر ’melange lint‘ أو ’melange build‘، يقوم البرنامج بإنشاء مسارات ملفات الإخراج عن طريق ربط المعلمة ’--out-dir‘ بقيمتي `arch` و`pkgname` المقروءتين من ملف التحكم .PKGINFO الخاص بملف APK. ونظرًا لعدم التحقق من صحة هذه القيم فيما يتعلق بفواصل المسارات أو تسلسلات «..»، فإن المهاجم الذي يزود مسار lint أو مسار البناء بملف APK ضار قد يتسبب في قيام النظام بكتابة تقرير lint بتنسيق JSON إلى مسار .json عشوائي يمكن للعملية الوصول إليه. وقد يؤدي ذلك إلى الكتابة فوق ملفات JSON أخرى موجودة على نظام الملفات. لا تؤثر هذه المشكلة إلا على عمليات النشر التي يتم فيها تمكين علامة «--persist-lint-results» بشكل صريح.

عند تصدير بيانات القياس عن بُعد إلى الخلفية أو المجمع عبر gRPC أو HTTP باستخدام تنسيق بروتوكول OpenTelemetry (OTLP)، تؤدي الطلبات غير الناجحة (HTTP 4xx أو 5xx) إلى قراءة الاستجابة في الذاكرة دون حد أقصى لعدد البايتات المستهلكة. قد يؤدي ذلك إلى استنفاد الذاكرة وحالة رفض الخدمة في التطبيق المستهلك إذا كانت الخلفية أو نقطة نهاية المجمع المُعدة خاضعة لسيطرة المهاجم، أو إذا قام مهاجم شبكي بتنفيذ هجوم «الرجل في الوسط» (MitM) لإرجاع نص استجابة ضخم للغاية.

يمكن للمهاجم القادر على التلاعب بملف التكوين — كما هو الحال في سيناريوهات «البناء كخدمة» (build-as-a-service) أو سيناريوهات التكامل المستمر (CI) التي تعتمد على طلبات السحب (pull requests) — التلاعب بالمتغير `pipeline[].uses` لتضمين مسارات مطلقة أو تسلسلات `../`. تفشل الدالة `compilePipeline()` الموجودة في `pkg/build/compile.go` في التحقق من صحة هذا المتغير قبل تمريره إلى `filepath.Join()`، مما يسمح للعملية بقراءة ملفات عشوائية قابلة للتحليل بلغة YAML خارج دليل خط الأنابيب المحدد. نظرًا لأن الملف الذي تم تحميله يُفسر على أنه خط أنابيب ويتم تنفيذ كتلة `runs:` الخاصة به عبر `/bin/sh -c` داخل بيئة البناء المعزولة (sandbox)، فإن هذا يتيح تنفيذ أوامر شل غير مصرح بها من ملفات خارج الشجرة، متجاوزًا حدود المراجعة القياسية.

تقوم سياسات التحقق من الموارد الموثوقة بمقارنة سلسلة مصدر المورد `refSource.URI` مع `spec.resources[].pattern` باستخدام الدالة `regexp.MatchString`. ونظرًا لأن هذه الدالة تُبلغ عن وجود تطابق إذا تم العثور على النمط في أي مكان في السلسلة، يمكن تجاوز الأنماط غير المثبتة بواسطة سلاسل مصدر يسيطر عليها المهاجمون وتحتوي على النمط الموثوق به كسلسلة فرعية. وقد يؤدي ذلك إلى تطابق غير مقصود مع السياسة وتغيير أوضاع التحقق أو المفاتيح المطبقة.

عند إنشاء مورد RequestAuthentication مع وجود `jwksUri` يشير إلى خدمة داخلية، يقوم istiod بتنفيذ طلب HTTP GET غير مصدق إلى عنوان URL هذا دون تصفية عناوين IP الخاصة بـ localhost أو link-local. قد يؤدي هذا السلوك إلى توزيع البيانات الحساسة على وكلاء Envoy من خلال تكوين xDS.