Balíček eject zneužitelný k lokální eskalaci práv (CVE-2017-6964) (diskuse)

[pc2005]

Eject je i pro normální mass storage zařízení. Používám ho pro čtečku tak o 2 řády častěji než CD/DVD. Nejsem si jistý, ale nejspíš jo, měl by jít i pro SATA disky. Jestli jde i pro páskové mechaniky si už nepamatuju, ale ty maj hooodně starý drivery, možná to vysouvaj jinak.

[Tom K]

Taky jsem ho na mass storage používal, ale nebavilo mě neustále hledat ejectnuté microsd po zemi. Takže dávám přednost klasickému umount.

[pc2005]

umount odpojí partišnu, ale eject odpojí elektriku.

[Jardík]

Mě zase hledat na zemi ejectnutou flashku ...

[Petr Tomášek]

-    setgid(getgid());
-    setuid(getuid());
+    if (setgid(getgid()))
+        return 1;
+    if (setuid(getuid()))
+        return 1;

Hm, zajímavé. Můžete mi někdo vysvětlit, jak je možné zvnějšku ovlivnit, aby se root nemohl sám změnit na jiného uživatele?

[tatar]

This unfortunately doesn't account for a FAILED call to setuid(), which would then perform the parsing as root.

[Petr Tomášek]

No, tak to je snad každému jasné, ale jak toho dosáhneš (aby setuid() skončilo neúspěšně) jako user, který volá setuid binárku "eject", jsi tím nijak nevysvětlil...

[tatar]

No to je pravda lebo som bol prirychly pri odpovedi. Ale v podstate je to len zneuzitelna chyba a nie zneuzita.... a ten kto to vie ten to nepovie. Ale predpokladam, ze pretecenim spravnej pamati dokazu takuto dieru zneuzit.

[.]

Jaké přetečení? Když ani zdaleka netušíš, o co jde, tak mlč.

[Ivan]

mozna by to mohla byt nejaka race condition, kdy uid zmizi z /etc/passwd (NIS). Uznavam ale, ze je to hodne divoky scenar.

[Petr Tomášek]

OK, takže je jasný, proč se Debian vzdal práva na informační embargo

[Michal Kubeček]

Syscall nekontroluje existenci UID v /etc/passwd nebo NIS.

[Hans1024]

Ja jsem se nad tim taky podivoval a myslim ze na BSD by to nebylo zneuzitelne, protoze jedinny error setuid je

     [EPERM]            The user is not the superuser and the requested uid or
                        euid is not the process's real, effective, or saved
                        UID.

ale pak jsem se podival na Linuxovy manpage

       EAGAIN The call would change the caller's real UID (i.e., uid does
              not match the caller's real UID), but there was a temporary
              failure allocating the necessary kernel data structures.

       EAGAIN uid does not match the real user ID of the caller and this
              call would bring the number of processes belonging to the real
              user ID uid over the caller's RLIMIT_NPROC resource limit.
              Since Linux 3.1, this error case no longer occurs (but robust
              applications should check for this error); see the description
              of EAGAIN in execve(2).

       EINVAL The user ID specified in uid is not valid in this user
              namespace.

       EPERM  The user is not privileged (Linux: does not have the
              CAP_SETUID capability) and uid does not match the real UID or
              saved set-user-ID of the calling process.

a asi by nejak slo zpusobit "temporary failure allocating the necessary kernel data structures".

[Michal Kubeček]

Tam je jen jedna alokace ze slabu, tam selhání dost dobře vynutit nepůjde (a pokud ano, tak už stejně nebude pořádně fungovat půl systému). Ale možná by šlo soustředit se na ten test validity uid předávaného setuid() a změnit mapování UID pro příslušný user namespace mezi voláním getuid() a setuid().

[Yarda]

No a pokud mi něco neuniklo, tak i když toho roota nakonec nějak dostanu failnutím setuid/gid, tak výsledek bude jen ten, že to bude parsovat obsah /dev/mapper/control jako root a ne obyčejný user. Takže to chce ještě najít nějakou zneužitelnou chybu v tom parseru a nějak tam injectnout malformed data...