milo-d/cve-2016-6187_lpeExploit de kernel para CVE-2016-6187 (Escalada de privilegios local)
Exploit del Kernel para CVE-2016-6187 (Escalada de Privilegios Local) (versiones afectadas: < 4.6.5)
El exploit fue desarrollado contra un kernel 4.6 compilado personalizado + buildroot (kconfig próximamente) y derrota KASLR, SMEP, SMAP (KPTI no disponible para 4.6)
La vulnerabilidad explotada es un desbordamiento de un solo byte nulo en el montón en uno de los hooks LSM de AppArmor (setprocattr). Ver https://nvd.nist.gov/vuln/detail/CVE-2016-6187
Mediciones iniciales indican un 94.44% de probabilidad de obtener un shell root. En 1 de cada 18 casos, el exploit generará un kernel oops. Se necesita más trabajo para estabilizar completamente el kernel tras obtener acceso root.
Abusamos del desbordamiento de byte nulo para corromper el LSB de un puntero de freelist en kmalloc-128, permitiendo que apunte a un objeto ya asignado. Después, liberamos ese objeto asignado, provocando un escenario de doble libre.
Ahora podemos asignar dos estructuras superpuestas de la caché kmalloc-128. La primera estructura es un objeto con contenido que el espacio de usuario puede leer. Para eso, he elegido ip6_sf_socklist. La segunda estructura, que se asignará sobre ip6_sf_socklist, debe contener punteros del kernel - rfkill_data es una buena opción. Contiene un puntero al montón (lista vacía rfkill_data.events) y un puntero a datos globales hacia rfkill_fds (rfkill_data.list.prev). Una vez que rfkill_data está asignado sobre ip6_sf_socklist, podemos recuperar los punteros del kernel llamando a getsockopt(sock, IPPROTO_IPV6, MCAST_MSFILTER, gsf, &optlen). La base del texto del kernel se puede derivar de rfkill_fds.
Luego provocamos un segundo escenario de doble libre, pero esta vez abusamos del proceso de enlace de la cola de mensajes para sobrescribir el puntero de freelist y engañar al asignador para que nos devuelva un chunk de kmalloc-96 cuando en realidad solicitamos un chunk de kmalloc-128.
Podemos entonces aprovechar el desajuste de tamaño para desbordar el puntero de freelist de un chunk de kmalloc-96, dándonos la primitiva para asignar direcciones arbitrarias. En nuestro caso, apuntamos a la estructura ptmx_fops y sobrescribimos el callback ptmx_fops.unlocked_ioctl con un puntero a nuestro gadget de pivot de pila.
Llamar a ioctl en /dev/ptmx activa el gadget de pivot y pivotamos la pila hacia una pila falsa en kmalloc-128 donde ya hemos preparado nuestra cadena rop de primera etapa.
Dado que tenemos espacio limitado en la pila falsa de kmalloc-128 (no sabemos si el siguiente chunk estará en el mismo slab), la tarea de la cadena rop de primera etapa es copiar la cadena rop de segunda etapa desde el espacio de usuario al búfer de registro dmesg del kernel (__log_buf) y pivotar la pila hacia __log_buf.
La cadena rop de segunda etapa intenta luego reparar el kernel (restaurando ptmx_fops, ...) antes de llamar a commit_creds(prepare_kernel_cred(NULL)) para escalar privilegios.
Y finalmente sale del espacio del kernel mediante iretq y regresamos, con privilegios elevados, a nuestra subrutina execve("/bin/sh", 0, 0).
Los usuarios no privilegiados deben poder al menos abrir /dev/rfkill. Algunas distribuciones podrían no permitirlo. He comprobado Ubuntu y Fedora, ambas permiten a usuarios no privilegiados abrir /dev/rfkill (aunque Fedora usa SELinux en lugar de AppArmor)
La siguiente sección explica cómo reproducir la escalada de privilegios local en qemu-x86_64.
Primero, deberás obtener un initrd y un kernel bzImage. Hay dos formas:
La forma más fácil y rápida. Puedes encontrar todos los componentes necesarios en prebuilt/.
O, alternativamente, también puedes construir los componentes tú mismo. Simplemente descarga el kernel 4.6 y usa el archivo x86_64_vuln_kern_defconfig proporcionado en config/ para compilar el bzImage.
Para el initrd podrías, por ejemplo, usar buildroot. Solo asegúrate de establecer los permisos correctos para /dev/rfkill en tu init
chmod 664 /dev/rfkill
Esto es igual que en Ubuntu-16.04 y muchas otras distribuciones. Tampoco olvides compilar el exploit y ponerlo en tu initrd
make
Una vez que tengas los componentes, inicia la máquina vulnerable
./boot.sh <path/to/bzImage> <path/to/rootfs.cpio>
y ejecuta el exploit
./exploit
Puede que necesites ejecutar el exploit varias veces, dependiendo de si hemos anulado un LSB que ya era cero. También ten en cuenta que todavía existe una pequeña posibilidad (¿quizás 10%-20%?) de fallo tras obtener acceso root - estoy trabajando en ello.
Diviértete.
ptmx_fops para aumentar estabilidadkmalloc-128 para aumentar estabilidad