Thevilledev

يوجد خلل في تجاوز الصلاحيات يسمح لمديري مساحات الأسماء (namespace admins) بالهروب من حصر مساحة الاسم. يحدث هذا لأن متحكم التنظيف (cleanup controller) يقوم ببناء محمل السياق الخاص به بسياسة فارغة (nil policy)، مما يؤدي إلى قراءة حراس الأمان لمساحة اسم فارغة وعدم تقييد الوصول. يمكن للمهاجم إنشاء `CleanupPolicy` خاصة بمساحة الاسم تحتوي على إدخالات سياق `apiCall` أو `globalReference` لقراءة الأسرار (Secrets) عبر مساحات أسماء مختلفة وتعديل `validatingwebhookconfigurations` باستخدام حساب الخدمة (ServiceAccount) الخاص بمتحكم التنظيف.

يسمح تأكيد النوع غير المُتحقق منه في معالج التغيير `forEach` للمستخدم الذي يمتلك أذونات لإنشاء `Policy` أو `ClusterPolicy` بإدخال وحدة التحكم في الخلفية على مستوى المجموعة في حالة CrashLoopBackOff مستمرة، وهي حالة يتعطل فيها الحاوية بشكل متكرر ويتم إعادة تشغيلها. تؤدي هذه المشكلة أيضًا إلى قيام وحدة التحكم في القبول بقطع الاتصالات وحظر جميع عمليات الموارد المطابقة. تستمر حلقة التعطل حتى يتم حذف السياسة. تقتصر هذه المشكلة على المحرك القديم، بينما لا تتأثر السياسات القائمة على CEL.

يتسبب مؤشر صفيف غير مُتحقق منه في دالة `podGCFromPod()` الخاصة بمُبلغ البود في حدوث حالة ذعر على مستوى وحدة التحكم بالكامل عندما يحتوي بود سير العمل على تعليق توضيحي `workflows.argoproj.io/pod-gc-strategy` غير صحيح. ونظرًا لأن حالة الذعر تحدث داخل غوروتين المُبلغ خارج نطاق استعادة وحدة التحكم، فإنها تؤدي إلى تعطل عملية وحدة التحكم بأكملها. يستمر وجود البود التالف عبر عمليات إعادة التشغيل، مما يؤدي إلى حلقة تعطل توقف جميع عمليات معالجة سير العمل حتى يتم حذف البود يدويًّا. وهذا يسمح لأي مستخدم لديه إذن بإرسال سير العمل بالتسبب في هجوم رفض الخدمة ضد جميع سير العمل في المجموعة.

Argo Workflows هو محرك سير عمل أصلي للحاويات مخصص لـ Kubernetes. يمكن للمستخدم القادر على إرسال سير العمل تجاوز الإعدادات الأمنية المحددة في `WorkflowTemplate` عن طريق تضمين حقل `podSpecPatch` في عملية إرسال سير العمل. يحدث هذا التجاوز حتى عندما يتم تكوين وحدة التحكم باستخدام `templateReferencing: Strict`، والذي يهدف إلى تقييد المستخدمين على القوالب المعتمدة من قبل المسؤول. يُعطى الحقل `podSpecPatch` الأولوية أثناء دمج المواصفات ويتم تطبيقه على مواصفات البود دون التحقق من صحة الإعدادات الأمنية. وعلى وجه التحديد، يكون ترتيب أولوية الدمج كما يلي: مواصفات سير العمل > مواصفات WorkflowTemplate > مواصفات WorkflowDefault. لا تقوم الدالة `ApplyPodSpecPatch()` إلا بالتحقق من صحة بناء جملة JSON للتصحيح، دون التحقق من وجود إعدادات أمنية خطيرة. وهذا يسمح للمهاجمين بتجاوز إعدادات الأمان مثل تشغيل الحاويات كجذر (root)، وتمكين الوضع المتميز (privileged mode)، وتركيب نظام ملفات المضيف، وإضافة جميع إمكانيات Linux. ويمكن أن يمنح الاستغلال المستخدم وصولاً كاملاً كجذر (root) إلى عقدة Kubernetes الأساسية.

Kubewarden هو آلية سياسات لـ Kubernetes. يمكن للمهاجم الذي يتمتع بأذونات مميزة لإنشاء ”AdmissionPolicy“ استغلال ثلاث واجهات برمجة تطبيقات (API) قديمة للرد من المضيف: `kubernetes/ingresses` و`kubernetes/namespaces` و`kubernetes/services`. عند إنشاء سياسة تستخدم واجهات برمجة التطبيقات هذه، يحصل المهاجم على وصول للقراءة إلى موارد Ingresses وNamespaces وServices. هذا الوصول هو للقراءة فقط، دون قدرات للكتابة ودون وصول إلى البيانات الحساسة مثل Secrets أو ConfigMaps. يمكن للمهاجم نظريًا الكشف عن البنية الداخلية للمجموعة من خلال قراءة معلومات Service، والوصول إلى أسماء وتسميات المساحات الاسمية، وأسماء المضيفين وقواعد التوجيه الخاصة بـ Ingress.

يحتوي المكون الإضافي `opa-envoy-plugun` على مشكلة في طريقة بناء الحقل `input.parsed path`. يتم التعامل مع مسارات طلبات HTTP على أنها عناوين URI كاملة أثناء التحليل، مما يؤدي إلى تفسير الأجزاء الأولية من المسار التي تبدأ بعلامتي شرطة مزدوجة (`//`) على أنها مكونات للسلطة، وبالتالي إزالتها من المسار الذي تم تحليله. قد يسمح هذا التباين بين المسار الذي يتم تقييمه بواسطة مرشح التفويض والمسار الذي يقدمه الخادم الخلفي للمهاجمين بالتحايل على ضوابط الوصول عن طريق إنشاء طلبات ضارة. تحدث المشكلة عندما تعتمد سياسات التفويض على `input.parsed path` لاتخاذ قرارات تستند إلى المسار، وتطبق الخوادم الخلفية توحيدًا متسامحًا للمسار. توضح أمثلة أنماط الطلبات المتأثرة كيف يمكن أن يختلف الحقل `input.parsed path` عن المسار الفعلي للطلب، مما قد يؤدي إلى وصول غير مصرح به. يحتوي الحقل `input.attributes.request.http.path` على مسار الطلب الخام غير المعالج.

Kyverno هو آلية سياسات مخصصة لفرق هندسة المنصات السحابية الأصلية. تعاني الإصدارات المتأثرة من استهلاك غير محدود للذاكرة داخل آلية السياسات. يمكن للمستخدمين الذين يتمتعون بامتيازات إنشاء السياسات إحداث هجوم رفض الخدمة عن طريق إنشاء سياسات تضخم بيانات السلسلة (string) بشكل أسي باستخدام متغيرات السياق. تشبه هذه المشكلة هجومًا من نوع «Billion Laughs»، حيث يمكن للمهاجم تعطيل النظام عن طريق استنفاد الذاكرة المتاحة.

يحتوي Kyverno، وهو آلية سياسات مخصصة لفرق هندسة المنصات السحابية الأصلية، على ثغرة خطيرة تتعلق بحدود التفويض في `apiCall` الخاص بسياسة Kyverno ذات نطاق الاسم. يتم تنفيذ `urlPath` الذي تم تحليله باستخدام ServiceAccount الخاص بوحدة التحكم في القبول في Kyverno دون فرض قيود على نطاق الاسم. وهذا يسمح لأي مستخدم تمت مصادقته ولديه إذن لإنشاء سياسة ذات نطاق اسم بإجراء طلبات إلى واجهة برمجة تطبيقات Kubernetes باستخدام هوية وحدة التحكم في القبول في Kyverno، مما قد يؤدي إلى استهداف أي مسار واجهة برمجة تطبيقات يسمح به نظام RBAC الخاص بـ ServiceAccount المذكور. وهذا يعرض عزل نطاق الأسماء للخطر، حيث يسمح بالقراءة عبر نطاقات الأسماء لموارد مثل ConfigMaps وSecrets، ويسمح بعمليات الكتابة على نطاق الكلستر أو عبر نطاقات الأسماء، مثل إنشاء سياسات الكلستر (ClusterPolicies)، من خلال التحكم في `urlPath` عن طريق استبدال متغيرات السياق. تكمن الثغرة الأمنية في الطريقة التي يعالج بها Kyverno مدخلات السياق `apiCall`، وتحديدًا استبدال المتغيرات في الحقل `URLPath` دون تطهير مناسب أو التحقق من صحة التفويض. يمكن للمهاجم إنشاء أي مسار API صالح للوصول إلى الموارد التي لا يُفترض أن يكون له حق الوصول إليها وتعديلها. وقد يؤدي ذلك إلى تسرب البيانات، أو تعطيل الكلستر بأكمله من خلال إنشاء موارد `ClusterPolicy` ضارة

Argo CD، وهي أداة GitOps إعلانية للتسليم المستمر لـ Kubernetes، معرضة لحدوث حالة تنافس في معالج بيانات اعتماد المستودع الخاص بها. تحدث هذه الحالة عند تنفيذ عمليات متزامنة على نفس عنوان URL للمستودع، مما قد يتسبب في حدوث حالة ذعر (panic) وفشل خادم Argo CD. تكمن المشكلة في معالجات متعلقة بالمستودع داخل الملف `util/db/repository secrets.go`، وتحديدًا في وظائف مثل `secretToRepoCred`. ينشأ التنافس على الموارد من الوصول المتزامن إلى قوائم الخرائط دون الحماية المناسبة بواسطة الموتكس (mutex)، ويحدث ذلك نتيجة لعمليات بيانات اعتماد المستودع (إنشاء أو تحديث أو حذف) جنبًا إلى جنب مع عمليات إعادة مزامنة مُبلغ Kubernetes والمراقبين في الخلفية. يتطلب استغلال هذه الثغرة رمز API صالحًا مع أذونات المورد `repositories`، مما يسمح للمهاجمين بتكرار تشغيل هذه الحالة والحفاظ على حالة رفض الخدمة، مما يؤدي إلى تعطيل عمليات GitOps.

يحتوي CoreDNS، وهو خادم DNS يعمل بنظام تسلسل المكونات الإضافية، على ثغرة أمنية تتعلق بـ«التشويش في TTL» داخل المكون الإضافي etcd. تنشأ هذه الثغرة عن الاستخدام غير الصحيح لمعرّفات الترخيص (lease IDs) كقيم TTL، مما قد يتيح شن هجمات تثبيت ذاكرة التخزين المؤقت لـ DNS. وعلى وجه التحديد، تقوم الدالة `TTL()` الموجودة في `plugin/etcd/etcd.go` بتحويل معرّفات الترخيص (64 بت) في etcd إلى uint32، مما يؤدي إلى قيم TTL كبيرة للغاية عندما يكون معرّف الترخيص كبيرًا. وهذا يسمح للمهاجمين بتثبيت إدخالات ذاكرة التخزين المؤقت لـ DNS لفترات طويلة، مما يؤدي إلى رفض الخدمة (DoS) فيما يتعلق بحل عناوين DNS للخدمات المتأثرة. يمكن للمهاجم الذي يمتلك حق الوصول للكتابة في etcd استغلال هذه الثغرة عن طريق كتابة أو تحديث مفتاح بأي مدة تأجير، مما يتسبب في قيام برامج التحليل والعملاء في المراحل اللاحقة بتخزين الإجابات في ذاكرة التخزين المؤقت لسنوات.

Kyverno معرض لثغرة أمنية من نوع «رفض الخدمة» (DoS) ناجمة عن المعالجة غير الصحيحة لاستبدالات متغير JMESPath. يمكن للمهاجمين الذين يمتلكون أذونات لإنشاء أو تحديث سياسات Kyverno استغلال هذه الثغرة عن طريق صياغة تعبيرات تستخدم المتغير `{{@}}` بالاقتران مع علامة الأنابيب ووظيفة JMESPath غير صالحة (على سبيل المثال، `{{@ | non existent function }}`). ويؤدي ذلك إلى استبدال القيمة `nil` في بنية السياسة. وتؤدي المعالجة اللاحقة بواسطة الدالة `getValueAsStringMap`، التي تتوقع قيمًا نصية، إلى حدوث حالة ذعر (panic) بسبب فشل تأكيد النوع. وقد يؤدي ذلك إلى تعطل خيوط عمل Kyverno داخل وحدة التحكم في القبول (admission controller) وتسبب تعطلًا مستمرًا لوحدة التحكم في التقارير (reports controller pod)، مما قد يؤدي إلى تدهور الخدمة أو عدم توفرها.

توجد مشكلة «رفض الخدمة» (DoS) في تنفيذ خادم DNS-over-QUIC (DoQ) الخاص بـ CoreDNS. في السابق، كان الخادم ينشئ goroutine جديدة لكل دفق QUIC مستلم، دون فرض أي قيود على عدد الدفقات أو goroutines المتزامنة. يمكن لمهاجم بعيد وغير مصدق عليه فتح عدد كبير من الدفقات، مما يؤدي إلى استهلاك غير منضبط للذاكرة ويؤدي في النهاية إلى حدوث خطأ «نفاد الذاكرة» (OOM) — خاصة في البيئات التي تستخدم الحاويات أو التي تعاني من قيود على الذاكرة. يقدم هذا التصحيح آليتين رئيسيتين للتخفيف من المخاطر: `max streams`، التي تحدد عدد تدفقات QUIC المتزامنة لكل اتصال بقيمة افتراضية تبلغ `256`؛ و`worker pool size`، التي تُنشئ مجموعة محدودة من العمال على مستوى الخادم بأكمله لمعالجة التدفقات المستلمة بقيمة افتراضية تبلغ `1024`.

cpp-httplib هي مكتبة خادم وعميل HTTP/HTTPS مكتوبة بلغة C++ وتتألف من الرؤوس فقط (header-only). لا تفرض الإصدارات الأقدم من 0.20.1 حدودًا للحجم المُعدة مسبقًا على نصوص طلبات الاستقبال عند استخدام `Transfer-Encoding: chunked` أو عند عدم توفير رأس `Content-Length`. وهذا يسمح لمهاجم عن بُعد بإرسال طلب مقسم (chunked) بدون الجزء الأخير الذي يبلغ حجمه صفرًا، مما يؤدي إلى تخصيص ذاكرة غير خاضع للرقابة. وقد يؤدي ذلك إلى استنفاد ذاكرة النظام وتعطل الخادم أو عدم توفره.

Argo Events هو إطار عمل لأتمتة سير العمل الموجه بالأحداث لـ Kubernetes. يمكن للمستخدم الذي يتمتع بإذن إنشاء أو تعديل الموارد المخصصة EventSource و Sensor الحصول على وصول مميز إلى النظام المضيف والمجموعة، حتى دون امتلاك امتيازات إدارية مباشرة. تسمح CRs EventSource و Sensor بتخصيص البود (pod) المنسق المقابل باستخدام spec.template و spec.template.container، وبالتالي يمكن تحديد أي مواصفات ضمن container، مثل command و args و securityContext و volumeMount، وتطبيقها على بود EventSource أو Sensor. وبذلك، يمكن للمستخدم الحصول على وصول مميز إلى مضيف الكلستر إذا قام بتحديد CR EventSource/Sensor ببعض الخصائص المحددة في template.

Beego هو إطار عمل ويب مفتوح المصدر للغة البرمجة Go. توجد ثغرة أمنية من نوع «التنفيذ البرمجي عبر المواقع» (XSS) في الدالة `RenderForm()` بسبب عدم إجراء الهروب المناسب لعلامات HTML في البيانات التي يتحكم فيها المستخدم. وهذا يسمح للمهاجمين بحقن كود JavaScript ضار يتم تنفيذه في متصفحات الضحايا، مما قد يؤدي إلى اختطاف الجلسة أو سرقة بيانات الاعتماد أو الاستيلاء على الحساب. تؤثر هذه الثغرة الأمنية على أي تطبيق يستخدم وظيفة `RenderForm()` في Beego مع البيانات التي يقدمها المستخدم. تقوم الدالة `RenderForm()` بإنشاء جميع علامات النموذج ولا تقوم بتفريغ السمات تلقائيًا، مما يشكل خطرًا لوقوع هجمات الحقن. توجد الثغرة الأمنية في الدالة `renderFormField()` في الملف `templatefunc.go` (تقريبًا في الأسطر 316-356)، حيث يتم حقن القيم التي يقدمها المستخدم مباشرةً في HTML دون تفريغ مناسب.