edición general
150 meneos
2510 clics
Un grave fallo concede acceso root en todas las distribuciones de Linux

Un grave fallo concede acceso root en todas las distribuciones de Linux

Se ha detectado una nueva vulnerabilidad, bautizada como Dirty Frag, que permitiría a los atacantes obtener privilegios de administrador de la mayoría de las distribuciones de Linux que se utilizan actualmente. Para conseguirlo, únicamente sería necesario hacer uso de un único comando.

| etiquetas: dirty frag , vulnerabilidad , linux , root
Comentarios destacados:              
#11 Por suerte ésas vulnerabilidades se han encontrado para usuarios con acceso FÍSICO a las máquinas...
O sea, si te dejas la sesión abierta y alguien va a tu teclado ... Es grave, pero tiene un alcance limitado.
Pero es filosofía UNIX que quien tiene el hardware es el dueño, así que cualquiera puede manipular un ordenador que tiene en sus manos...
Sin ésa vulnerabilidad ( o la de copy fail ) , alguien que tenga acceso físico a tu máquina, puede entrar con una Live ISO y chroot a tu sistema y hacer lo mismo, y esto nunca ha sido un grave problema...
Falta ver cuando se encuentre una de acceso remoto que permita ejecución de ése código, ahí ya estaría más jodida la cosa .. pero por ahora no es el caso ...

Así que sí, #4 , Linux sigue siendo más seguro que Windows... Aparte de que ya se están parcheando...
Debian está parcheado. Y es una vulnerabilidad local
#2 Debían, pero no todos.
#5 es un error del núcleo y el núcleo ya ha sacado la corrección hace mucho tiempo.
#24 un error nuclear
#29 se dice nucelar{lol}
#2 Además, creo que hace falta que este presente cierto módulo del kernel que no siempre está.
#12 En este caso son varios los módulos implicados creo.
Y en el otro caso, el módulo se cargaba sobre la marcha cuando se necesitaba, era trivial forzar su carga.
#2 Debian rules!
No la votaré porque es interesante, ahora bien, que diga "Linux, cada vez más expuesta" es bastante atrevido. Ni aún con las vulnerabilidades detectadas es sencillo exponer las distribuciones. Código abierto y software libre, muchísimos más pros que contras.
El comando:  media
#3 ¡Ja! ¡Inténtelo Ud. mismo! xD

(un amigo mío lo tenía)
#3 Qué tiempos!!!
#3 Aaah, qué recuerdos.. mi primer juego pirata en CD
Ni un miserable enlace a ningún documento oficial, ni detalle alguno del comando que causa este fallo. El periodismo de baratillo de internet, tan mediocre como siempre y tan irrelevante como siempre.
#36 No es buena práctica hacerlo si el parche no está publicado y distribuido.
#36 #39 Esto se publicó ayer viernes, a eso del mediodía (yo me enteré un par de horas después, cosas de currar en seguridad):

github.com/V4bel/dirtyfrag

Solo afecta con acceso local. Cualquier usuario logeado.
Aquí el vector más importante es cualquier container de origen incierto que te la pueda liar, o que usurpen alguna actualización como la que liaron con Trivy hace poco.

Mitigation, como root ejecutas esto y ya:
sh -c "printf 'install esp4 /bin/falseninstall esp6 /bin/falseninstall rxrpc /bin/falsen' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"
#31 Hay mil casos de uso donde el usuario se logea al sistema y si no se pueden explotar fallos de seguridad en servidores y contenedores para correr un shell. El fallo de seguridad es gordo y minificarlo no es positivo para la seguridad de Linux.
#38 fallo-seguridad.min.js {0x1f601}
Joder, menuda seguridad... :palm:
Por suerte ésas vulnerabilidades se han encontrado para usuarios con acceso FÍSICO a las máquinas...
O sea, si te dejas la sesión abierta y alguien va a tu teclado ... Es grave, pero tiene un alcance limitado.
Pero es filosofía UNIX que quien tiene el hardware es el dueño, así que cualquiera puede manipular un ordenador que tiene en sus manos...
Sin ésa vulnerabilidad ( o la de copy fail ) , alguien que tenga acceso físico a tu máquina, puede entrar con una Live ISO y chroot a tu sistema y…   » ver todo el comentario
#11 Bueno, un acceso remoto por SSH también vale...
#20 #14 #16 Exacto, pero para todos esos casos primero hay que tener un usuario LOGUEADO con lo cuál la superficie de ataque queda bastante reducida... Pero como dice #20, cualquier trampa para obtener ejecución, ahora se convierte en un peligro alto, por suerte no hay , a día de hoy, muchas. #16 , creo que primero hay que poder 'tirar' comandos , que no es fácil, pero sí, habrá que vigilar todos los servicios que sean susceptibles de poder ejecutar código. Y para #14, si, acaban de convertir 'cualquier usuario ' en root ... Pero primero hay que conseguir un usuario...

Un sistema expuesto pero bien configurado, no debería tener más riesgo que el hecho de que un usuario quiera hacer daño, y si ya es usuario, algún filtro ya ha pasado ..
#31 bueno, no te creas... hay sistemas (p.e. en las universidades) donde hay cientos de alumnos con acceso shell limitado que si no se parchea podrían acceder a todo el sistema
#14 ¿Puedes acceder por SSH sin tener un usuario previamente?
Porque eso sigue limitando mucho el acceso.
#65 Puedes acceder con ataque por fuerza bruta o aprovechando una vulnerabilidad en un servicio.

Pero eso ya es aprovechar otra vulnerabilidad.....

Si, no es como una vulnerabilidad remota, pero es importante.
#11 También significa que cualquier vulnerabilidad que haya en un servicio que esté publicado, por ejemplo un servidor web, un servidor de tiempo, etc, permitiría en combinación con la vulnerabilidad de este meneo obtener privilegios de superusuario.
#16 Exactamente. Una vulnerabilidad que no proporcionaba privilegios de root, ahora es como si lo hiciera.
Aunque si consigues acceso local, el lograr root en muchos casos, solo es cuestión de tiempo en realidad.
#11 Las inyecciones de código en plataformas vulnerables (pasa constantemente en Wordpress o Nextcloud por poner dos ejemplos conocidos) permiten la ejecución de comandos como usuario del servidor web por un atacante sin acceso físico ni ssh.

Si se alinea un escalado de privilegios y una inyección de código en poco dias, el desastre está servido.

Que el fallo esté parcheado no significa ni que ya se encuentre en todos los canales de distribución ni que los sysadmins lo hayan aplicado a su infraestructura.
#11 Pregunta no sé si tonta ¿se puede encriptar el disco pa que ni con una live iso puedas entrar sin la contraseña?
#44 El núcleo no creo que se pueda, supongo que una vez cargado el núcleo podrás cifrar el resto. Desconozco cuál será el tamaño mínimo del núcleo que permitiría algo así, nunca he cifrado mis discos duros, ya me ha costado bastante recuperar datos cuando meto la pata en discos no cifrados :-(
#44 Sí. De eso se trata. Con una live iso puedes acceder al sector de arranque, pero no puedes leer la partición encriptada sin la contraseña de la partición (no tiene nada que ver con la de root).
#11 no estoy de acuerdo con que si hay acceso físico estás jodido siempre. la live solo la puedes usar si el arranque desde CD/usb está activo en la BIOS/uefi. Cosa que se desactiva siempre en entornos serios, además de poner contraseña a la configuración para no poder modificarla. Si te pones tonto incluso contraseña de aalrranque.

Además como menciona #44 si tienes el disco cifrado con la contraseña en el TPM o teniendo que escribirla a mano en el arranque tampoco pueden acceder al contenido del disco.
#11 estás vulnerabilidades vienen muy bien para rootear dispositivos de fabricantes que vienen con Linux aunque capados como televisores, routers, productos domóticos, etc...

En realidad es una noticia bastante buena.
#11 creo que también puede ser acceso tenido, si tienes alguna vulnerabilidad que permita que ejecuten comandos, como un un servidor web con alguna configuración errónea que permita subir un archivo y ejecutarlo, etc, porque se puede hacer con un usuario con pocos privilegios
#11 Que te afecte es más fácil de lo que parece, sin acceso físico a la máquina.

Un ataque a la cadena de suministro como el de Trivy de hace unas semanas. Si darte cuenta te bajas un container "sucio" y te puede intentar usar esta vulnerabilidad. Da igual que uses containers sin root y sin privilegios. La única manera de evitarlo es corriendolos en VMs, o con un k8s debidamente reforzado.
#11 Qué ha dicho Miguel Bosé?
#4 De las mejores del mundo.
Ninguna empresa creo que se acerque.
#4 Ningún sistema es invulnerable. Ni informático ni de ningún otro tipo. Lo seguro que es un sistema no lo define que tenga fallos, sino como se responden a estos. En aviacion ya se sabe: múltiple redundancia, auditación en múltiples fases, análisis de incidentes y accidentes y actualización de procedimientos...

Si prefieres ir con la compañía que nunca ha reportado nada, suerte. Lo inteligente es elegir la que tiene altos estándares, con auditoría propia y externa que reporta múltiples problemas y pone los medios y el interés por corregirlos.

Los que no reportan problemas... miedito me dan.
#35 Ningún sistema es invulnerable. Ni informático ni de ningún otro tipo.

Propaganda! Los portaaviones gringos son invulnerables. Y sus aviones también. Las lavadoras es por un inepto uso realizado por el becario del barco. Que para colmo es informático.
De momento en Debian sólo trixie parcheada:

security-tracker.debian.org/tracker/CVE-2026-43284
#19 ahí dice que bullseye, trixie y sid, si es que sé leer.
#25 Pues sí. Cuando puse el enlace sólo estaba trixie (bueno, y sid, pero nunca lo cuento).
#25 Para entendernos. No está parcheada la versión de pruebas ni las versiones anteriores a la estable anterior.
La estable actual y la anterior están oa
parchesdas.
#19 Trixie es la versión estable. La que se debe usar en producción
Teniendo el codigo accesible podrian decirnos que fallo cometieron los que programaron estos modulos o la parte del nucleo que no trataba el posible problema con los modulos.
Los núcleos afectados están por debajo de la versión 5.
Ya nadie usa eso. Ahora la versión que se distribuye es la seis y pico.
#22 La 7 si eres cool :troll:
Menos mal que Linux a nivel de escritorio no está muy extendido porque esto es una cagada gorda gorda por mucho que algunos le quieran quitar importancia.

Además puede unirse a otros exploits para hacerte con el control de root de manera remota.
Fallo mío
Y nosotros cada vez mas dependientes de cualquier SO.
Ed un caso tan concreto y complicado, y además ya parcheado, que, no sé por qué, me huele que cierta comapñía estará dando publicidad a estad cosas sobre mediante.

Alguien ha conseguido entrar en sus sistemas con esto? Porque en los míos no va.
No me jodas, ahora tengo que compilar un kernel otra vez? En fin sarna con gusto... :foreveralone:

Posponemos entonces el año de linux en el escritorio a 2027? :troll:
#37 Compiqué ???
#37 no creas, la abundancia de vulnerabilidades parece ser un requisito imprescindible para triunfar en el mercado.
Ya falta menos para linux en el escritorio. Ya podemos jugar a los juegos de Windows, y empezamos a tener sus bugs
Yo no uso Windows desde 2005 porque no es más que un imán de virus. Yo uso Linux, so pringaos... oh, espera...
#6 oh, espera, ya se pueden parchear
#7 ¿Ves pringado windowsero como yo soy mucho más mejor y más listo por usar Linux?
#6 pues yo soy más y mejor porque para jugar Fortnite puedo hacerlo solo desde mi Windows 10 Lite Pro Hacker Edition que me bajé to wapo y solo con un crack ruso me salto las actualizaciones esas de seguridad y las activaciones. Porque Windows es gratis si te lo curras. No la cosa esa de Linus que es comunista y da menos fps en Steam.
#6 Creo que no veo un virus en Windows desde 2005....
#6 en windows las vulnerabilidades vienen con cada actualización, aquí la noticia es que se ha corregido con una
Curioso Meneame. Cuando es una vulnerabilidad de Windows todo a echar bilis

Cuando es una cagada de Linux ejjqueee ya está parcheado ejjqueee es local ejqueeeee ejjjqueeee solo acceso fisico ejqueeee mi abuela va en bicicleta ejjqueeee

Y el código abierto si nadie lo mira si nadie lo revisa es una gran montaña de mierda lista para ser explotadas por hackers

El chiste se cuenta solo
#21 Curioso Meneame. Cuando es una vulnerabilidad de Windows todo a echar bilis
Deja de inventarte películas.
#21 El chiste se cuenta solo
Deberías poner un emoticono o alguien podría pensar que tu comentario iba en serio.
#21 En Windows lo que sale es el destrozo que hacen sus propias actualizaciones. Las vulnerabilidades de Windows no se pueden encontrar estudiando el codigo ni puedes parchearlo tú mismo porque tienes que esperar a que lo haga Microsoft y eso si hace algo.
#21 Curioso Meneame. Cuando es una vulnerabilidad de Windows todo a echar bilis

Si fuera así, estaríamos echando bilis continuamente

menéame