Mralias

يوجد تجاوز سعة عدد صحيح في محلل بروتوكول النص memcached الخاص بـ OpenTelemetry eBPF Instrumentation (OBI). عند تحليل أوامر تخزين memcached مثل `set` أو `add` أو `replace` أو `append` أو `prepend` أو `cas`، يقبل النظام قيمًا كبيرة جدًا للمتغير `bytes` ويضيف طول محدد الحمولة دون التحقق من وجود تجاوز سعة. يؤدي الطلب المصمم خصيصًا، حيث يتم تعيين `bytes` إلى `math.MaxInt` أو `math.MaxInt-1`، إلى تحول طول الحمولة المحسوب إلى قيمة سالبة، مما يؤدي إلى حدوث حالة ذعر في وقت التشغيل داخل الدالة `LargeBufferReader.Peek()`. وقد يؤدي ذلك إلى حدوث هجوم عن بعد لرفض الخدمة (DoS)، مما يتسبب في تعطل عملية OBI وفقدان عملية جمع بيانات القياس عن بُعد.

يعتمد محلل ELF البديل على إزاحات الأقسام، وعددها، وإزاحات السلاسل الواردة في الملفات القابلة للتنفيذ. ويمكن لملف ELF محلي مصمم خصيصًا أن يتسبب في قيام الوكيل بإلغاء مرجعية مؤشرات أقسام غير صالحة أو تجاوز جداول السلاسل، مما يؤدي إلى حدوث حالة ذعر أثناء تحديد لغة العملية. ينتج عن ذلك هجوم محلي لرفض الخدمة (DoS) يستهدف وكيل القياس عن بُعد، مما يسمح لمستخدم محلي بتعطيل الوكيل ومقاطعة قابلية المراقبة لأحمال العمل الأخرى. تشمل التفاصيل الفنية دالة `matchExeSymbols()` التي تتكرر عبر الأقسام باستخدام سياق `fastelf` غير مصدق عليه، ودالتي `GetCStringUnsafe()` و`ReadStruct()` اللتين تقومان بعمليات تقطيع وتحويل مؤشرات غير آمنة دون حماية ضد الإزاحات خارج النطاق أو السالبة. بالإضافة إلى ذلك، تثق الدالة `NewElfContextFromData()` في قيم `Shoff` و`Shnum` و`Phnum` الواردة من رأس ملف ELF دون التحقق من صحة الإزاحات.

يفترض محلل بروتوكول Postgres خطأً أن حمولات رسائل `BIND` تحتوي على اسم بوابة صالح منتهي بـ NUL. عند معالجة حمولة فارغة أو غير منتهية تم تصميمها خصيصًا، قد يقوم النظام بتقسيم البيانات إلى أجزاء تتجاوز نهاية المخزن المؤقت الملتقط، مما يؤدي إلى حدوث حالة ذعر في وقت التشغيل. يحدث هذا ضمن منطق حالة `BIND` حيث يحسب النظام `portalLen` ويقوم بتقسيم `msg.data` دون التحقق مما إذا كان المخزن المؤقت يحتوي على حرف إنهاء NUL أو عدد كافٍ من البايتات. قد يؤدي هذا إلى مشكلة في التوافر عن بُعد حيث يقوم المهاجم بإرسال حركة مرور Postgres مشوهة إلى خدمة خاضعة للمراقبة، مما يؤدي إلى تعطل الوكيل وإيقاف عملية جمع بيانات القياس عن بُعد.

تقوم أداة OpenTelemetry eBPF Instrumentation بتصدير نص خطأ Redis الخام كرسالة حالة النطاق. ونظرًا لأن ردود أخطاء Redis قد تحتوي على قيم حساسة أو بيانات يسيطر عليها المهاجمون، فإن هذا السلوك قد يؤدي إلى تسريب الرموز المميزة أو المعلومات الشخصية القابلة للتعريف (PII) أو أي مدخلات سرية أخرى إلى الخلفيات الخاصة بالقياس عن بُعد. بالإضافة إلى ذلك، فإنه يسمح بحقن نص غير موثوق به في أنظمة التحليل النهائية. تحدث هذه المشكلة لأن الدالة `getRedisError()` تقوم بقص مخزن الأخطاء الخام وتخزينه مباشرةً في `request.DBError.Description`، والذي يتم إرجاعه لاحقًا كرسالة حالة مُصدَّرة لـ Redis spans عندما تكون حالة span غير صفرية، دون أي تنقية بخلاف قص CRLF.

يقوم OpenTelemetry eBPF Instrumentation (OBI) بإعادة تشغيل نتائج استشعار BPF في ملاحظات الرسم البياني عن طريق تكرار العملية مرة واحدة لكل عدد تشغيل مسجل. في الأنظمة المزدحمة، قد يصبح الفرق في عدد مرات التشغيل كبيرًا جدًّا، مما يتسبب في قضاء مُصدِّر المقاييس وقتًا مفرطًا من وحدة المعالجة المركزية (CPU) في حلقة ضيقة خلال كل فترة جمع. يحدث هذا لأن الدالة `calculateStats()` تحسب `deltaCount` على أنه الفرق بين `bp.runCount` و`bp.prevRunCount` دون تطبيق حد أقصى. ثم يقوم أداة التصدير بالتكرار عبر `probeMetrics` وتنفيذ حلقة بناءً على `metric.count`، مستدعيًا الدالة `BpfProbeLatency()` لكل نتيجة مسجلة على حدة. ونتيجة لذلك، يصبح استهلاك وحدة المعالجة المركزية (CPU) متناسبًا مع عدد نتائج المسبار بدلاً من عدد سلاسل المقاييس، مما قد يؤدي إلى مشكلة في التوافر في مسار المقاييس الداخلية عند تتبع أحمال العمل ذات الحجم الكبير.

يستخدم مسار الاحتياطي لمخزن الرسائل لكل وحدة معالجة مركزية (CPU) مخزنًا احتياطيًا سعة 256 بايت، لكنه يحتفظ بحجم الحمولة الأصلية، التي قد تصل إلى 8 كيلوبايت. في حالة حدوث عدم تطابق في وحدة المعالجة المركزية (CPU) بين سياقي المنتج والمستهلك، يمكن للنظام القراءة إلى ما وراء المخزن المؤقت الاحتياطي، مما يؤدي إلى تسرب البيانات المجاورة إلى نظام القياس عن بُعد. تؤثر هذه المشكلة بشكل خاص على مسار تتبع HTTP عندما يكون نشر السياق ممكّنًا، ومسار `tpinjector` sock msg نشطًا، ويتم تكوين التقاط المخزن المؤقت الكبير لـ HTTP بحجم غير صفر. تتضمن التفاصيل الفنية `fallback buf` في `msg buffer t` واستخدام `real size` لقراءة بيانات الحمولة من `u buf`، مما يتسبب في قراءة زائدة عند استخدام المخزن المؤقت الاحتياطي الأصغر حجمًا.

يوجد تسرب في الذاكرة في `CappedConcurrentHashMap` المخصص المستخدم لتتبع حالة TLS في Java. تقوم الدالة `remove()` بحذف الإدخالات من الخريطة، لكنها تفشل في إزالة المفاتيح المقابلة من قائمة الانتظار مرتبة حسب ترتيب الإدراج. في بيئات JVM المجهزة بأدوات القياس التي تعمل لفترات طويلة مع تقلب متكرر في الاتصالات، تنمو هذه القائمة دون حدود، مما قد يؤدي إلى فترات توقف طويلة لعملية جمع القمامة أو استنفاد ذاكرة الكومة، مما ينتج عنه خطأ `OutOfMemoryError`.

يستخدم مسبار ioctl الخاص بـ Java TLS الدالة `bpf probe read` بشكل غير صحيح بدلاً من `bpf probe read user` عند قراءة مؤشرات ioctl التي يتحكم فيها المستخدم. يحدث هذا داخل خطاف kprobe `do vfs ioctl`، الذي يعامل الحجة الثالثة لـ ioctl على أنها مخزن مؤقت منظم ويقرأ حقولًا مثل بايت العملية من `arg`، وبيانات الوصف الوصفية للاتصال من `arg + 1`، وطول الحمولة من `arg + 1 + sizeof(connection info t)`. إذا كان الطول أكبر من الصفر، يتم تمرير المؤشر إلى الدالة `handle buf with connection()`. نظرًا لأن المؤشر ينشأ في مساحة المستخدم، فإن استخدام `bpf probe read` يسمح لعملية محلية مجهزة بأدوات الرصد بتوفير مؤشر للنواة، مما يتيح تسريب الذاكرة الموجودة في النواة إلى أنظمة القياس عن بُعد. وينتج عن ذلك ثغرة أساسية في الكشف عن ذاكرة النواة المحلية في عمليات النشر التي تدعم بروتوكول TLS في Java.

يقوم مُثري السجلات (log enricher) بمعالجة مخازن `writev` بشكل خاطئ، حيث يقرأ فقط الإدخال الأول من `iovec` بينما يستخدم إجمالي `iov iter.count` كطول النسخ. عند تمكين حقن السجلات، يمكن أن يؤدي استدعاء `writev` متعدد المقاطع المصمم خصيصًا إلى قيام البرنامج بقراءة الذاكرة والكتابة فوقها بما يتجاوز المقطع الأول. يحدث هذا لأن الدالة ` fill iov()` تحلّ فقط `struct iovec` واحدًا، في حين أن الدالة ` write()` تستخدم إجمالي عدد البايتات عبر جميع المقاطع. يمكن أن يؤدي هذا الخلل في أمان الذاكرة إلى تلف مخازن التطبيق المجاورة، أو تسرب الذاكرة إلى أحداث السجل، أو عدم استقرار العملية.

يمكن أن تؤدي رسائل MongoDB غير الصحيحة إلى حدوث حالات ذعر غير مكتشفة في محلل TCP الخاص بـ MongoDB، مما يسمح لمهاجم بعيد غير مصدق عليه بتعطيل وكيل القياس عن بُعد والتسبب في رفض الخدمة. يعمل المحلل على حمولات شبكة خام يسيطر عليها المهاجم قبل التحقق الكامل من صحة المدخلات، مما يعني أن رسالة واحدة مصممة خصيصًا يمكنها إنهاء عملية جمع البيانات القياسية للعملية أو العقدة المتأثرة. تشمل التفاصيل الفنية حالات الذعر المتعلقة بحدود الشرائح في الدالتين `parseOpMessage()` و`parseSections()` عند معالجة حزم OP MSG المقطوعة أو أقسام تسلسل المستندات غير الصحيحة، بالإضافة إلى حالة ذعر في وقت التشغيل في الدالة `parseFirstField()` بسبب تأكيد نوع غير مُتحقق منه على `field.Value` عند معالجة مستندات BSON غير الصحيحة.

يسمح ثغرة في مسار حقن وكيل Java لمهاجم محلي يتحكم في حمل عمل Java بالكتابة فوق ملفات مضيف عشوائية عندما يكون حقن Java ممكّنًا وتعمل أداة القياس بامتيازات مرتفعة. كان أداة الحقن تثق في متغير `TMPDIR` من العملية المستهدفة واستخدمت دلالات إنشاء ملفات غير آمنة، مما يتيح تجاوز حدود نظام الملفات وتدمير الملفات باستخدام الروابط الرمزية.