Tres vulnerabilidades del kernel (ya parcheadas) desveladas este finde

[h]Fin de semana animado en el planeta linux con tres nuevas vulnerabilidades (una era “severa”).
Han hecho los deberes y están parcheadas… Haz los tuyos: actualiza tu sistema [/h]
Para que nadie se estrese: Los parches se aplican solos actualizando nuestro sistema. :wink:
No debemos hacer nada más que actualizar nuestro sistema como lo hacemos siempre:

  • Por vía gráfica con nuestro gestor de actualizaciones
  • O utilizando las ordenes para actualizar el sistema
sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade

El sudo dist-upgrade solo servirá para debian SID o Kali,
Ponerlo no te matará o no creará errores en Ubuntu o debian. :slight_smile:
Este punto aclarado, nos vamos a interesar ahora en estas tres brechas.
Las pongo en orden, la primera es la más “critica”, la ultima es la más ligera, una vulnerabilidad “parcial”
[h]CVE-2016-8655: Carrera de pollos sin cabezas en la función packet_set_ring [/h]
La expresión “carrera de pollos sin cabezas” es mía y supongo que no es muy correcta :smiley:
El termino exacto en inglés es simplemente “condición de carrera”

¿De que se trata?
Es bastante malvado y si se pone de pie se puede “crashear/congelar” un sistema y se puede hasta inyectar comandos que requieren privilegios de administrador (sin tener los derechos)
No concierne muy directamente un usuario “normal” que tiene una distribución GNU-Linux en su computadora.
Pero es muy problemático para los servidores, sobre todo los que emplean un sistema de acceso remoto para compartir recursos en la nube…
Este tipo de servers están en la linea de fuego, un usuario sin privilegios puede hacer mucho daño.
La “carrera de polló sin cabezas” se baza en la “paralelización” de procesos normalmente condicionados entre ellos.
Muy simple.
Imaginas que tienes un proceso B programado para ejecutarse después que se acabe un proceso A
Lo que se puede hacer con esta brecha es hacer que B se ejecuta cuando A se ejecuta.
El proceso B se va a lanzar y va a usar muy rápido muchos recursos… para nada… Los procesos lanzados en paralelo están fuera de control y se entiende de sobra que esto no puede acabar bien…
… Esto acaba en una carrera de uso recursos entre procesos sin sentido y el sistema acabará reventando.
En detalles:

Todo reside en la posibilidad de crear espacios para los nombres de redes sin privilegios.
La experiencia demuestra que los desarrolladores de distribuciones deberían sistemáticamente prohibir esto por defecto.

  1. CVE-2016-8655 Linux af_packet.c race condition (local root) by Philip PETTERSON @ Seclist/*]
  2. commit 84ac7260236a49c79eede91617700174c2c19b0c by David S. MILLER @ Kernel.org/*]

[h]CVE-2016-6480: Condición de carrera resultando en una DOS[/h]
Esta brecha es menos chunga porque no permite inyectar comandos, es vandalismo puro.
Se debe a la posibilidad dejada a un usuario no root de modificar el tamaño de valores admitidos, dejando el sistema en situación de double-fecth que acabará provocando un crash
En este caso la función culpable es ioctl_send_fib que se encuentra en drivers/scsi/aacraid/commctrl.c
Más información:

  1. race condition in af_packet packet_setsockopt and packet_set_ring. @ Canonical/*]

[h]CVE-2016-6828: DOS, brecha parcial (impacto menor)[/h]
La brecha no se considera como severa pero podría resultar en una de-conexión forzada.
Se baza en funciones propias al protocolo TCP.
Un usuario sin derechos de administrador podría conseguir mandar paquetes ACK mal-formados y podría provocar des-conexiones arbitrarias.
Molesto sin ser preocupante…

  1. CVE-2016-6828 @ Red Hat/*]

En el articulo utilizado cómo fuente (ver hipervínculo al final de este post) podemos leer

[quote]The good news is developers are looking very closely at Linux’s core code for possible security holes. The bad news is they’re finding them.
At least the best news is that they’re fixing them as soon as they’re uncovered.[/quote]
*La buena noticia: Los desarrolladores miran muy de cerca el código de linux.
La mala noticia: Es cuando encuentran brechas (y una buena cosa es que se arreglen estos fallos enseguida) *
Antes de todo decir que los artículos de Steven J. Vaughan-Nichols son siempre exactos y de mucha cualidad y conoce muy bien todo lo que gira alrededor de las preguntas de seguridad en Linux.
Pero creo que se equivoca cuando dice que es “mala noticia” cuando se encuentra una brecha.
Diría todo el contrario: Es también una buena noticia.
La brecha existe y sale de la sombra, no hay más espacio para un “exploit zero days” (un código malicioso que explota una brecha desconocida)
Esta claro que jode a los administradores de redes que están en primera linea y deben reaccionar muy rápido. .
No seamos cándidos: Un buen sistema basado en Linux y bien actualizado es mucho más seguro que un Windows pero tampoco es perfecto.
Esto no existe: Un sistema perfecto sin ningunas brechas posibles.
. Así que a darle caña y a colaborar… No queda otra.
En este caso mejor ver el vaso a mitad lleno que a mitad vació: ¿Una brecha nueva encontrada? ¡Que bien!
Gracias a su modo de funcionamiento y a la idea de trabajo “open source”, la “comunidad linux” lo tiene arreglado en un instante y nuestro sistema es pocas horas después más seguro que antes.
No es ser iluso decir que el modelo funciona y que la velocidad con la cuál se resuelven las brechas en linux es su fuerza, no tiene equivalente.
Lo que es iluso es pensar que puede haber un sistema perfecto sin ningunas brechas posibles.
Estas vulnerabilidades no nos conciernen a nuestra escala de usuario/administrador en su red domestica.
Si se usan es fácil de verlas mirando los procesos que están corriendo su sprint (sin hablar de que un crash del sistema no pasa desaparecido :smiley: )
En todos casos mejor actualizarse en cuanto antes.

Fuente

  1. Three serious Linux kernel security holes patched by ** Steven J. VAUGHAN-NICHOLS** @ ZDnet/*]

Lo voy a apuntar y hacer la actualizacion manana :cool: todavia no pienso que la nsa o la cia va avenir esta noche en mi kernel :stuck_out_tongue:

¡Inconsciente!
Si tienes un crash del sistema en la noche ya sabes el porqué :smiley: