edición general
339 meneos
3692 clics
Bug 0-day  en kernel de Linux permite escalar privilegios. [ENG]

Bug 0-day en kernel de Linux permite escalar privilegios. [ENG]

Se ha detectado una vulnerabilidad en el kernel de Linux que permite escalar privilegios para conseguir acceso root, y que existe en el kernel desde hace 3 años. Algunas plataformas Android también están afectadas por el bug.

| etiquetas: bug , linux , kernel , android
Comentarios destacados:                            
#23 #1 Por mi experiencia profesional, de ya unos cuantos años, la respuesta del usuario típico de cada SO a una noticia de este tipo es:

- MacOS: pa que quieres saber eso jaja saludos
- Windows: yo ke se tio xDxd
- Linux: toca actualizar

He visto a fanboys de todo pelaje, pero nunca me he encontrado a ningún fanboy de Linux interesado en encubrir un fallo en el kernel para exculpar no sé muy bien el qué.

Aunque, para ser honesto, también debo reconocer que tampoco me he encontrado a muchos fanboys de MacOS o Windows... que supiesen lo que es un kernel... :-D
«12
  1. No entiendo mucho, pero espero que esta llegue a portada al igual que llegó esta:

    www.meneame.net/story/elevacion-privilegios-sencilla-1-todos-windows-l
    A no ser que venga el comando pingüinero a tumbarla. :-D
  2. Ufff, ya no duermo tranquila hasta que no se solucione este asunto
  3. Debe ser errónea. Los bugs de seguridad solo ocurren en Windows.
  4. Menos mal que linux sólo lo usan cuatro frikis pajilleros
    Enviado desde mi Android
  5. #3 No sólo ocurren en windows, Linux también tiene. Lo que pasa es que en linux se corrigen hoy y se descubren la semana que viene. Lo importante es el tiempo de reacción.
  6. Imagino que el parche llegará en pocas horas.
  7. #4 ¿Hoy Android sí es Linux?
  8. #9 parece que hay un 66% de androids afectados
    As of the date of disclosure, this vulnerability has implications for approximately tens of millions of Linux PCs and servers, and 66 percent of all Android devices (phones/tablets).
  9. #1 siendo un 0-day, cualquier admin de sistemas linux preferiría que estuviese en portada.
  10. The vulnerability affects any Linux Kernel version 3.8 and higher. SMEP & SMAP will make it difficult to exploit as well as SELinux on android devices.

    Si tienes un kernel de esos, pues a actualizar.
  11. #5 Viaje al futuro con... GNU/Linux!!!
  12. #9 Cuando se trata del kernel Linux, siempre es Linux. En este caso se trata de un bug en el kernel Linux; así que cualquier dispositivo que tenga instalado un kernel Linux 3.18 o versiones superiores, está afectado.
    Cuando el fallo está en el núcleo, da igual como se llame el OS que use ese núcleo. No hay discusión en esto.

    Otra cosa es cuando falla algún componente del OS Android y aparece alguien preguntando cosas como "Hoy Android no es Linux??".

    Linux es el nombre de un núcleo que utilizan muchos sistemas operativos del tipo "UNIX".

    Todo lo demás no es Linux, será "ponga aquí el nombre/Linux"; para indicar que usa el kernel Linux.
  13. Es lo que tiene un kernel que ocupa una burrada, comparado con microkernels. Eso y que no integran PaX.

    Y encima si tienes docker también te afecta porque corre en el kernel, no es un hypervisor real lo que separa los contenedores.
  14. #4 y la mayoria de los servidores de internet
  15. #10 ¿Otra vulnerabilidad crítica en Android que la mayoría de los móviles nunca llegarán a tener parcheada? Genial...

    Va a ser mejor meterlo en una jaula de Faraday excepto cuando necesite llamar.
  16. #13 GNU/Dislexia. Ahora, compatible con Linux.
  17. #10 Entiendo que ese 66% de teléfonos Android llevan una semana con el bug corregido por lo que dice #5
  18. #1 Por mi experiencia profesional, de ya unos cuantos años, la respuesta del usuario típico de cada SO a una noticia de este tipo es:

    - MacOS: pa que quieres saber eso jaja saludos
    - Windows: yo ke se tio xDxd
    - Linux: toca actualizar

    He visto a fanboys de todo pelaje, pero nunca me he encontrado a ningún fanboy de Linux interesado en encubrir un fallo en el kernel para exculpar no sé muy bien el qué.

    Aunque, para ser honesto, también debo reconocer que tampoco me he encontrado a muchos fanboys de MacOS o Windows... que supiesen lo que es un kernel... :-D
  19. #21 Si, claro, y luego te levantas del sueño y ves todo lo que mueve Red Hat y Canonical.
  20. #24 Si claro, con soporte fresquito y pagando, con un SLA para la solución de problemas.
    Al final lo barato GNU sale caro.
  21. #26 Sí, como el fallo de AD del otro día, el cual hay que tirar el arbol AD y muchas veces el dominio DNS asociado abajo.

    ¿A cuanto sale el soporte de semejante cagada?
  22. #27 Si la empresa que tiene el problema tiene soporte activo con Microsoft, vamos a lo mismo $$$$, con un tiempo de respuesta decente, te puedo asegurar que se mueven muchos culos para solucionarlo.
  23. #17 Para explotar esa vulnerabilidad tienes que tener acceso físico al sistema y además que estén instaladas las herramientas de compilación.

    No solo eso, ese acceso a la máquina tiene que ser largo :-) si le máquina tiene uno de los últimos modelos de microprocesador i7, el atacante necesita media hora!!
  24. #21 Perdona, pero llevo diez años en esto y no he visto esa escena con GNU/Linux en la vida (y me he movido mucho). Tu estas confundiendo un administrador de sistemas que maneje GNU/Linux con soltura con un "cuñao de" coleccionista de PC Actual. No nos desviemos...
  25. #30 Ehem, oye que no quiero seguir con la polémica, pero es que me los encuentro semana sí y otra nó, que no les cabe en la cabeza que su endiosado Debian les esté dejando tirados y que la sombra del paro les ponga histéricos y con malos modos.
  26. #1: el comando pingüinero

    Parece una canción de los Def Con Dos.
  27. #1 Esa es la pequeña diferencia entre el software abierto y el cerrado,en el software abierto se publican los fallos para encontrar soluciones y en el software cerrado las empresas ocultan sus bugs hasta que se hacen demasiado evidente.
  28. #31 Pues chico, diles que se pongan las pilas y vayan a donde quieren contratar administradores de Debian. Que me parece que confundes "no quieren contratar" con "no quieren contratar linuxeros". Mira la que esta cayendo y aqui estoy, pegandome con Debian, JBoss y familia...
  29. #23: Relacionada:
     media
  30. #34 vale, veo que eres un crack, ¿esa solución con la que estás "pegandote" está en un entorno de producción de una empresa donde si se cae puede perder mucha pasta? ¿es una institución académica o fundación?
    Te contrato y te pago lo que no está escrito si me aseguras cero euros de perdidas con una solución sin soporte y en la que solo puedo confiar en tu capacidad.
  31. #35 La de Mac es optimista, está dando por hecho que la actualización incluye ese dispositivo... :troll:
  32. #16 la mayoría de los servers de internet, manejados claro esta por los mismos 4 frikis pajilleros :troll:
  33. #28 En el caso de AD las pérdidas por el servicio sin estar en activo (al ser más monolítico) son más numerosas.
  34. #36 crees que con windows se puede hacer lo que dices?
  35. #23 Tu si que eres un fanboy.
  36. #39 Pues mira que han publicado el código fuente y hay negocios con servidores windows a los que doy soporte, hasta ahora: cero problemas de este tipo reportados.
  37. #40 Sí se puede, la presión de un contrato de soporte y un SLA es muy efectiva.
  38. #17 acabo de leer el parche, no termino de entender tu comentario

    Efectivamente, necesitas tener acceso al sistema, pero no veo por que no puedes hacerlo con un acceso remoto
    Segundo, tampoco veo para que necesitas compilar el exploit en la maquina objetivo. Lo compilas en otro lado y copias el binario

    Mañana si tengo tiempo analizare el problema en detalle
  39. #29 Bueno, es un overflow a un Int a base de incrementar uno a uno su valor. Estas cosas llevan su tiempo
  40. #52 Hay muchas circunstancias donde yo puedo tener acceso remoto como usuario a una máquina pero no tener acceso de administrador. Algunos ejemplos:

    Puedo tener acceso de lectura al servidor (logs y similar), pero no para ser root
    O puede que codigo que yo creo se despliegue en un servidor en una cuenta de usuario
    O puede ser el ordenador donde hacía practicas en la universidad, donde tenía cuenta de usuario pero no de root (obviamente)
    O ser un telefono android donde el root esta desactivado (aunque no este de acuerdo con esta política)
    O quiza el ordenador del trabajo donde no me dan admin porque lo gestionan en IT
    O uno de los servidores de sourceforge (recuerdo que antes te daban acceso ssh)
    O meter el codigo en un ejecutable y convencer a un usuario para que lo ejecute, como no es root, cree que el daño que puede hacer el programa es minimo (cosa que no es cierta si tiene cosas como usuario importantes)
    Y por ultimo, y no porque no haya más, puede que tenga un exploit de tipo remote code exeuction que combinado con este me da remote root
    No se, yo la lista la veo muy larga
  41. #55 basicamen hoy menos del 0.1% de los servidores tienen abierto llamadas de sistema desde php.
    Basicamente estamos hablando de expltar una vulnerabilidad desde otra vulnerabilidad
  42. Al igual que ayer con el fallo de windows, vamos a intentar hacer una explicación sencilla por si alguien sin mucha experiencia quiere entender como funciona esto (gente con experiencia, no os lanzeis a mi cuello, este comentario no es para vosotros)

    El kernel es dios, con poder para hacer cualquier cosa en nuestro sistema. Para poner un buen ejemplo en nuestra sociedad, digamos que el kernel es un banco. Como banco tiene un montón de trabajadores, dinero y similar. Una de las cosas que tiene son cajas de seguridad, muchas cajas de seguridad. El banco es bastante paranoico para evitar robos, por lo que no nos va a dejar entrar dentro de la zona segura del banco, ahi solo pueden entrar los trabajadores del mismo. Sin embargo, el banco pone a disposicion de los usuarios ciertos servicios. Uno de ellos (entre una multitud ingente) es almacenar tu carne del videoclub). Pero claro, el banco no te va a dejar entrar en la camara segura para recuperar el carné, lo que te dice es que tiene un empleado llamado Jose que es el que se encarga de traer y llevarte el carné.

    Para ello, el banco coje una caja de seguridad (la 2237, por ejemplo) y la reserva para tu carne de videoclub y te da la llave de la caja que en su llavero pone el 2237. Mientras tanto, el banco apunta que esa caja esta ocupada y jose apunta en su libreta que tu tienes una copia de dicha llave. Cada vez que quieres ir al videoclub, solo tienes que ir al banco, avisar a jose, mostrarle la llave que apunta a la caja 2237 (mostrarle le basta, el banco tiene una llave maestra) y el amablemente te acompaña al videoclub para enseñar ahi tu carne y todo funciona. Si algun día quieres dejar de utilizar ese servicio, jose borra tu nombre de la libreta y el banco dice que la caja 2237 esta libre para usar por cualquiera de los otros trabajadors y servicios del banco

    Ahora bien, esto es un engorro, no porque tengas que pasar por el banco antes de ir al videoclub, sino porque acabas de casarte y tu esposa también tiene un carne para el videoclub. Dado que los carnés son familiares, no necesitais dos, os vale con uno, por lo que decidís que a partir de ahora utilizareis el vuestro. Vais juntos al banco llamais a jose y se lo explicais. Tu mujer a partir de ahora no va a usar el carne que ella tenia guardado, sino el tuyo. Jose dice que no hay problema, le pide a tu señora que le devuelva la llave que ella tenía con su caja y le entrega una copia de la llave 2237. Adicionalmente, apunta en la libreta que ha…   » ver todo el comentario
  43. #25 Pa que, si puede soltar la cuñadarería del día, y pasar página.
  44. #17 solo necesito tener acceso a una shell, por ejemplo ssh.
    Que no esten las herramientas de compilación me la sopla, compilo en mi pc y lo ejecuto en remoto.

    solo necesita las librerias : ldd cve_2016_0728
     linux-vdso.so.1 (0x00007ffeda3cb000)
     libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0x00007f8f00cd5000)
     libc.so.6 => /usr/lib/libc.so.6 (0x00007f8f00931000)
     /lib64/ld-linux-x86-64.so.2 (0x00007f8f00ed9000)

    que ademas puedo compilar de manera estatica, para que este incluidas en el ejecutable.

    Por otro lado sino tengo acceso a ssh, no significa que no pueda aprovecharme de otra vulnerabilidad para conseguir ejecutar codigo en la maquina remota, por ejemplo con un shellexploit.

    Una escalada de privilegios es un asunto muy serio, como para que le restes importancia.
  45. #52 me parece lo más normal del mundo tener acceso no-root remoto a un servidor Linux. De hecho es root quien suele tener restringido el acceso remoto.

    Si "solo los admin" deberían acceder, qué gracia tiene tener un sistema de red multi-usuario.
  46. #23 Posss me paso a FreeBSD :-D :-D :-D
  47. Estoy seguro que mi flamante Samsung no está afectado... imposible tener mas Bugs a parte de los que ya trae de serie para espiar mi prolífica e interesante vida :-D :-D :-D :-D
  48. #55 Yep, justo lo que decía antes, ¿tienes un remote execution? ¡Whops, ahora es remote root!
  49. #63 Llevaría tiempo (por lo de hacer 2^32 llamadas), pero no veo por que esto no se podría utilizar para rootear móviles sin pasar por el bootloader
  50. #15 La de gente que he visto que solo jala la imagen de docker sin verificar y piensa que puede sustituir el manejador de paquetes de la distribucion. Con un poco de mala leche podria divertirme creando una imagen.
  51. #56 El 0.1% siguen siendo muchísimos servidores. Y hablamos que combinados es tener control total
  52. #33 que te publiquen un 0day no tiene nada que ver con el tipo de licencia d tu software.
  53. El ancho del embudo: van a por un bug contra GNU/Linux pero nos tragamos un millón de Windows.
  54. #72 hay más tipos de servicios que la web, para los que se requiere acceso ssh.
    Incluso en web, muchos servicios de hosting dan acceso ssh.
    Pero no sólo existen servidores para páginas web. En mi empresa por ejemplo el servidor linux local precisamente lo que no sirve es web, sirve cuentas ssh que se usan en un 90% para compilar código.

    Vamos, que hay vida más allá del hosting web pelado sin ssh ni nada.
  55. #44 Si tengo, una chica que me limpia la casa y me hace la plancha 2 días a la semana
  56. Sin duda es, de todos los que me he leído, el bug mejor explicado de todos. En un lenguaje claro, con ejemplos de código, empezando a explicar desde 0... Impresionante. Gracias por el envio @neuralgya me guardo la web en favoritos.

    #14 buena explicación pero no la quieren/pueden entender... ¡Y no lo harán nunca! Jajaja
  57. #36 En un gobierno autonómico, y hasta ahí puedo leer sin saltarme mi contrato.

    Y si tienes una empresa con presupuesto de informática, eres un kamikaze si utilizas una solución con cero soporte, habiendo equivalentes con empresas detrás que te dan soporte. El problema no es meter GNU/Linux, el problema es meter un GNU/Linux cualquiera en lugar de uno que de soporte a empresas, que los hay y muchos. O contratar a un admin cualquiera en vez de uno con experiencia demostrada y/o certificaciones. Que los hay y muchos, pero no les puedes pagar con cacahuetes, claro... Españistan way of life, y todo eso.
  58. #15 Lo suyo es usar Gnu Hurd :troll:
  59. #36 A donde hay que mandar el currículum y de qué sueldo hablamos :-> ?
  60. #19 Bueno, veo complicadillo que exploten este bug en Android, salvo que te instales tu mismo el exploit.... Una manera fácil de rootear el dispositivo?.... promete.
  61. #78 lo que quieres es una configuración posible, pero limitada en funcionalidad.
    En mi caso se quedaría corto, yo tengo scripts entre mi servidor local y el servidor remoto vía ssh para gestionar la web y la bdd sql.
  62. #17 Y puedes denegar la ejecución a las carpetas de usuario...
  63. #53 Además, en los UNIX/Linux el acceso remoto es el pan nuestro de cada día. Este tipo de vulnerabilidades son más serias en Linux que en Windows
  64. #52 No es lo mismo acceso sin privilegios que con ellos
  65. #21 Hombre... en toda mi vida profesional los servidores mas estables que he visto son precisamente los servidores Linux, eso si, distribuciones serias con un equipo de soporte competente detrás. Está claro que si pones a un becario sin experiencia como administrador de sistemas el ostión está practicamente asegurado, pero esto pasa con cualquier cosa, lo dices como si un Windows Server se administrase solo...
  66. #21 Unsuccessful troll is unsuccessful.
  67. #21 palabra de cuñadmin, dí que si!!
  68. #65 Ése es un punto muuuuuuuy interesante. ¿Cómo se podría explotar?
  69. #71 Es como lo de P0dem0s y PPS03...
    :calzador: :shit:
  70. #23 Cuando el usuario que opina tiene conocimientos técnicos o es al menos administrador de sistemas (de los de verdad, de los que viven de eso), no se suele tomar posición de fanboy. Y ni de coña encubren bugs con no se sabe qué oscuros intereses.
  71. #5 xD xD xD xD xD xD xD xD
    En Windows es habitual que si se hace público un bug, el parche o está en camino o ya se puede descargar. Bugs más complejos pueden tardar tiempo en corregirse, y eso es así en Linux, MacOS, Windows y el sistema que sea.
  72. #27 Los SLA de Red Hat valen una fortuna, se te ha ocurrido echarle un vistazo a los precios?

    Lo de fallos que te obliguen a tumbar sistemas o dejarte los cuernos solucionándolos es un clásico hables del sistema que hables. Aún tengo frescas en la mente cagadas de Apache, OpenSSL y por supuesto un buen puñado en Windows Server.
  73. #30 A lo que se refiere es que hay mucho converso advenedizo, de esos que son más radicales a la hora de defender Linux, pero luego su nivel como bien dices no pasa de Cuñao Google Avanzado.

    Profesionales de Linux los hay de primera y curtidos en mil batallas.
  74. #19 Mis colegas se extrañan cuando me ven con un móvil BQ (el nuevo M5). Es precisamente por estas movidas por lo que lo compré, te aseguran 2 años de actualizaciones desde la salida del dispositivo, y son frecuentes.
    Si no necesitara doble SIM habría pillado un Nexus, claro está.
  75. #53 Como si no se pudiese subir ya compilado, o en el peor caso subir las herramientas.

    Lo cual no te serviría de mucho si los lugares donde puedes escribir como usuario no tienen permiso de ejecución.
  76. Cada vez que sale algún fallo de este tipo me encuentro antes la actualización en el SO que la noticia que hable de ello.
    Eso sí, los payasos diciendo de forma sarcástica que solo hay fallos en Windows y nunca en Linux me los tengo que leer igual. Me pregunto de donde sale ese victimismo, no se de ningún linuxero que afirme que no haya ningún tipo de fallo en el kernel de Linux.
    Supongo que solo intentan ir de rebeldes y no saben ni como.
  77. #21 ¿ Sabes lo grasioso que resulta que digas eso en un sitio que corre bajo GNU/Linux y es uno de los sitios con más visitas de toda España?
  78. #74 Ella no depende de ti, dependes tú de ella xD
  79. #10 a ver si está el mio y puedo rootearlo sin necesidad de hacer todo el proceso. xD :troll:
  80. Que no, esto es mentira, es una falacia. en linux no hay bugs. xD
«12
comentarios cerrados

menéame