Una vulnerabilidad en Sudo, una de las utilidades más relevantes de Linux, permite ejecutar comandos con acceso raíz, incluso cuando estos no están autorizados por el usuario. Dicha vulnerabilidad omite la política de seguridad de sudo, permitiendo así que otros usuarios o programas ejecuten comandos root.
|
etiquetas: vulnerabilidad , sudo , root , linux , seguridad 
Primero, para la gente que no entiende el problema, tranquilo. Si no has entendido el problema a la primera, es que no estas afectado, porque para que el ataque sea posible este requiere una configuracion bastante compleja de sudo. Sudo no permite impersonar solo al usuario root, en realidad permite impersonar a cualquier otro usuario (con los permisos adecuados, claro)
Normalmente sudo esta configurado de una forma que dice:
- El usuario A puede ejecutar como si fuera el usuario B las siguientes aplicaciones X.
En el 99.99% de los casos, usuario B es 'root', pero podria ser otro usuario, por ejemplo 'peter', y sudo estar configurado para decir:
- El usuario 'john' puede ejecutar como 'peter' la aplicacion 'ls'
Este caso es mucho mas raro, pero existe. Aun asi, este caso no es el que comenta la vulnerabilidad, sino otro mas raro aun. Sudo tambien permite declarar excepciones, por ejemplo algo como:
- El usuario 'john' puede ejecutar como 'todos los usuarios menos root' la aplicacion ls.
Aqui es donde ocurre el problema. En este caso, john puede saltarse la excepcion que tiene puesta, y efectivamente convertir los permisos en:
- El usuario 'john' puede ejecutar como 'todos los usuarios' la aplicacion ls
Esto es asi porque si john dice que quiere ejecutar ls como root, sudo le dice que tururú, pero si le dice que quiere ejecutar ls como el usuario '-1', sudo se queda un poco pillado, y en vez de fallar, ejecuta ls como root. Tambien ocurre con el usuario 4294967295.
Por que pasa esto?
Lo primero, esos dos estan bastante relacionados. A la hora de trabajar con numeros, un ordenador tiene que saber si esta trabajando con numeros con signo o sin signo. Internamente, ambos se representan igual (en 32 bits), -1 es el valor si decides interpretarlo con signo y 4294967295 si decides interpretarlo sin signo.
El siguiente motivo es que este es justamente el ultimo valor que se puede utilizar para usuarios en linux (curiosamente la pagina www.linfo.org/uid.html contiene un error diciendo que se pueden usa el 4294967296, se han pasado en 1)
I saw another thread and apparently it requires the user performing the sudo to have permission to run commands for all users (and not just root). So the default configuration isn’t exploitable as it is set up to just allow users in the sudo group to run commands as root.
En la noticia en inglés original lo explica, cosa que no hace la noticia en español para darle más sensacionalismo.
Edit: Veo que #9 ya lo ha comentado
Simplemente con un man sudo tenías la información.
No te preocupes. Sólo es explotable si tienes una entrada con esta forma:
Usuario máquina=(ALL, !root) comando
Lo cual es raro porque generalmente las entradas en sudo son para dar privilegios de root. Estas líneas no vienen por defecto.
En cualquier caso si te preocupa haz un update y arreglado.
Y si depende de ti, sudo hay que evitarlo.
Al haber dos claves distintas el usuario tiene muy claro cuando está haciendo algo peligroso. La clave de usuario para operaciones normales y la de root para cosas que requieren saber lo que haces.
Vale, ya me cayo
sudo u#-1 I'd -u
sudo -u#4294967295 id -u
Magia!
En la primera línea falta un - antes de la u, que sino el editor de menéame lo interpreta como un tachado
bastaría con modificar el archivo sudoers para eludir dicha política de seguridad
Y eso no es ninguna vulnerabilidad. La función de sudo es justamente esa. El archivo sudoers no puede modificarse a no ser que ya tengas permiso de root.
El problema real es el siguiente: Cuando uno ejecuta comandos con sudo, no necesriamente solicita al sistema convertirse en root sino que se puede solicitar convertirse en otros usaurios también (a veces es útil para comprobar si las cosas funcionan con ese usuario).
Dentro de los parámetros de sudo, en lugar de usar el nombre de un usuario se puede indicar el id (un número que lo identifica internamente). El fallo consiste en que si se especifica -1 o 4294967295, el programa lo convierte en 0, que es el id del usuario root.
¿En qué nos afecta esto? En el 99% de los casos en nada, porque sólo es importante cuando se ha configurado sudo para permitir la ejecución de un programa en particular y no todo como es lo usual. A demás, el uso extensivo de sudo es cosa de Ubuntu, Debian y derivados. Otras distribuciones no usan sudo para eso sino una clave separada para root.
Cabe aclarar también que, como es usual en el softwar libre, la vulnerabilidad ya ha sido corregida (versión 1.8.2) apenas se sido corregida y está en cada distribución incluirla en sus actualizaciones.
O puedes mirar en tu gestor de software qué versión del paquete tienes instalada.
El sistema de permisos y grupos debería ser suficiente para asegurar el acceso seguro para cualquier tarea. Si necesitas hacerlo más granular usando sudo, posiblemente es un error de diseño. Son muy pocos los casos donde no hay otra opción.
Y meter sudo es añadir una superficie de ataque asin de grande, no solo por la aplicación en si, sino porque la gente no la usa bien.
En distros de escritorio es casi inevitable, porque el Unix no se diseñó para eso.
Que yo sepa, aa que pide es la clave del propio usuario, no de root.. Justamente la función de sudo es poder ejecutar cosas con privilegios de otro usuario sin saber su clave.
De hecho, en las distribuciones basadas en Ubuntu, el usuario root no tiene clave (o sea que no te puedes loguear como root).
De hecho, en las distribuciones basadas en Ubuntu, el usuario root no tiene clave (o sea que no te puedes loguear como root)
Te puedes loguear como root con sudo su root, o sudo -i, aunque no tenga password.
En sistemas que van dirigidos a todo tipo de usuarios como Ubuntu, veo normal que se llegue a un compromiso de este tipo entre seguridad y comodidad de uso. SI vas a usar linux en sistemas más "serios" o "profesionales" lo lógico es que sepas configurar la seguridad de tu sistema y mires bien estas cosas.
"ejecutar comandos con acceso raíz," ---- hay que joderse..
No necesitas "login" y "logout"....
Si, tienes razón.
$ sudo -u#4294967295 id -u
[sudo] password for test:
test is not in the sudoers file. This incident will be reported.
$ cat /etc/debian_version
6.0.10
si añado el usuario test a sudoers para ejecutar alguna orden, por ejemplo
test ALL=(root) NOPASSWD: /usr/sbin/service
tampoco funciona
$ sudo -u#4294967295 id -u
[sudo] password for test:
Sorry, user test is not allowed to execute '/usr/bin/id -u' as #4294967295 on xxxxxx.
Ejemplo: estoy preparando un programa en php y quiero asegurarme de que va a poder leer determinado archivo. Entonces hago un su o un sudo para convertirme en usuario apache, y después intento un cat del archivo. Obviamente eso sólo se puede hacerse desde root porque el usuario apache no tiene clave para poder hacer su.
De todas formas tienes razón en que el sudo es muy versátil, pero en Ubuntu se lo usa muy mal porque permite al usuario hacer cualquier cosa y no comandos específicos.
Imagínate que lanzas una aplicación calculadora, si la lanzas como root esa aplicación puede hacer lo que quiera, si quiere hacer algo raro (por ejemplo encriptar el HD) te pedirá root y tu dirás... NI DE COÑA...
¿No es más simple usar un comando para no tener que estar constantemente con otra sesión de root abierta?
Más que nada porque eso puede darte problemas que confundas el usuario y lances una aplicación desde root.
Normalmente GNU (¿posiblemente para ser posix compliant?) tiene estandarizados ciertos parámetros que funcionan para todos los comandos, como por ejemplo:
--help
--version
Salu2
Voy a tomar como norma votar negativo (errónea o sensacionalista) este tipo de artículos; aunque algunos usuarios de MNM puedan entender que con ello intento ocultar "información que deja en mal lugar a los OS del tipo Linux
www.sudo.ws/alerts/minus_1_uid.html
Seguro que puedes hacer lo mismo con grupos sin añadir algo que puedes no configurar bien por error.
Umm ¿hay la lista de nombres de los desarrolladores de.las versiones de sudo afectadas?
Yo lo tengo todo deshabilitado. Está instalado porque es dependencia de algunos paquetes pero no tengo ni una regla. Para las veces que tengo que tocar la configuración del sistema, me paso a root con un "su" y listos.
Cuando digo "loguar" me refiero a cuando estás en un prompt de "Login:" y tecleas el usuario y su clave.
En sistemas que van dirigidos a todo tipo de usuarios como Ubuntu, veo normal que se llegue a un compromiso de este tipo entre seguridad
Es que no es para nada necesario. Mageia es una distribución muy amigable para el usuario novato (diría que incluso más que Ubuntu) y resuelve todo sin necesidad de sudo. Usa polkit para permitir operaciones como configuración de red por ejemplo sin tener que poner ninguna clave. Para instalar actualizaciones de software usa la clave del usuario y sólo para instalar software nuevo pide la clave de root.
De esa forma queda bien claro que cuando tecleas la clave de root vas a hacer algún cambio importante mientras que si te pide la de tu usuario es para hacer algo poco peligroso, y si no te pide clave es algo bastante inofensivo.
Eso no justifica la necesidad de sudo. Sin sudo: Te haces root+haces tu trabajo+sales de root....
Me parece simplemente comodidad.... si eres disciplinado.
¿Preguntarle a quién?
Pero todo tiene sus ventajas, inconvenientes y nivel de paranoia aplicable.
Eso me parece lo más interesante.
Claro que a veces es útil que un usuario pueda, por ejemplo, hacer un backup que requiere permisos de root. En ese caso se permite al usuario sólo ejecutar ese comando como root.
Lo que es mala idea es permitir al usuario ejecutar cualquier cosa como root (como hace Ubuntu). Para eso le das la clave de root y listo.
(Si, ya lo he buscado y todas las respuestas son sobre ¿Como saber la versión de linux que tengo?)
Como actualizar sudo a la última versión?
Como la anterior
Uno se acostumbra a la gran laguna de linux, quien da la información SIEMPRE sobre entiende que todo el que la la lee la la entiende y sabe buscar soluciones.
-Porque puedes configurar sudo para dar privilegios a los usuarios que necesites (no necesariamente permisos de root, puede ser usado para suplantar otros usuarios, por ejemplo, el de administración de x).
-Porque una vez puesta la clave, te otorga los permisos durante algo de tiempo (pero te los quita automáticamente luego), de manera que si vas a ejecutar varias tareas seguidas no te pida varias veces seguidas la clave. Y además está controlado por sesión, de manera que aunque otra persona entre con ese mismo usuario, al estar en otra sesión no tiene mágicamente permisos extra; igualmente esto que es muy cómodo puede ser visto como un problema de seguridad, pero si alguien que usa sudo se va de su equipo sin bloquearlo antes, creo que el problema de seguridad en realidad tiene patas...
-Porque puedes configurar sudo para dar privilegios a esos usuarios pero sólo a comandos concretos, de manera que como mucho, se exponga a ser un problema de seguridad para eso en concreto y no para todo el sistema. Por ejemplo, podemos dar permisos a un usuario para monitorizar ciertos logs y reiniciar el servicio X, sin tener que darle más permisos de administración.
El problema es que las distros lo usan a discrección, dando a los usuarios acceso de administración a todo, realmente haciendo que a todos los efectos un usuario del sistema sea root (por eso mucha gente lo ve como si fuera un "reemplazo" del su y para nada lo es).
Sudo no es más que una herrmamienta que suele estar configurada para que usuarios puedan ejecutar comandos como si fueran root (y por lo tanto, potencialmente romper cosas). Es muy potente y bien configurada puede ser una forma muy segura de que cualquier usuario pueda administrar sin problemas cualquier parte del sistema sin por ello afectar a otras partes del sistema (o sea, un control más fino y concreto de los privilegios).
Dependiendo del sistema, no está configurado (o sea, ningún usuario puede usar sudo) o lo está para un subconjunto de los usuarios (posiblemente sólo el administrador del sistema, para que pueda usar su propia cuenta y no root). El fichero de configuración del sudo se llama /etc/sudoers, edítalo y mira a ver qué líneas hay, si está todo comentado o si hay usuarios con permisos para ejecutar sudo.
Una regla muy recomendable es no permitir a ningún usuario al que le demos permisos acceso de escritura al /etc/sudoers...
La gracia del sudo es que puedas darle privilegios de root (o del usuario X) a otro usuario para ejecutar cosas concretas (durante un tiempo de sesión limitado). Por ejemplo, podrías permitir a manolo crear bases de datos postgres como si fuera el usuario postgres (pero sin tener que darle las credenciales de postgres), pero no privilegios para borrarlas (que si tendrías si le dejas ser postgres).
El problema es que las distros directamente dan todos los privilegios de root a los usuarios administradores, lo cual, concuerdo contigo, es un error.
Yo me refiero a que permitir modificar el /etc/sudoers a cualquiera y por lo tanto añadir los privilegios que le de la gana es básicamente darle la clave de root.
O simplemente, ejecutar un script de otro usuario que lista datos, mientras todo ello está en su home, donde tú ni tienes permisos ni privilegios. Así, tú sigues sin tener permisos para entrar en su home, ni ver o manipular sus datos, pero puedes ejecutar el script que te saca sólo lo que él quiere que tú veas. No hace falta meter a root en estos berenjenales siempre, sudo es mucho más versátil y nadie parece saber usarlo bien.
Si, ese es el punto de sudo (aunque todo el mundo lo use mal). El punto de ubuntu, si no recuerdo mal, es que root no tiene password y la única forma que tienes de administrar el sistema es usando sudo (lo cual es un poco absurdo).
Soy el jefazo y tengo en mi home datos. Quiero que pepito extraiga mensualmente datos, pero no quiero que entre en mi home y tenga posibilidad de ver o manipular nada de lo que hay ahí. Así pues, me creo un script que saca sólo los datos necesarios para ese informe o lo que sea y con sudo le doy permisos a pepito sólo para ejecutar ese script como si lo hiciera mi usuario. Así él puede extraer esos datos de mi home sin acceder a mi home
Soy administrador web y necesito poder levantar y bajar el servidor web (cosa que sólo puede hacer root y el usuario administrador de web apache), así pues vía sudo me permiten ejecutar como apache los comandos para arrancar y parar.
Soy usuario de monitorización y sé que hay un server que está pasando por problemas porque se satura y hay que reiniciarlo. Sólo root puede reiniciar. Vía sudo, me han dado permisos para poder reiniciar el server (pero para nada más).
Me he creado un perfíl administrador de equipos, de manera que todos los que estén en el grupo puedan tener privilegios de acceso a ciertas rutas restringidas (/etc, por ejemplo), pero no puedan hacer ciertas operaciones (por ejemplo, cambiar los ficheros de configuración de redes)
Sudo permite cosas muy quirúrjicas y se usa para matar moscas a cañonazos.
Gracias, buena explicación.