Un fallo que lleva 10 años escondido a simple vista permite ejecutar código como otro usuario usando sudo. En la mayoría de configuraciones por defecto esto implica poder escalar privilegios a root
|
etiquetas: sudo , unix , linux , root , heap , overflow
Una pesadilla si administras máquinas en las que tienes usuarios en los que no confías. Un fallo tonto si tú eres el único usuario de tu máquina.
Una pesadilla si administras máquinas en las que tienes usuarios en los que no confías. Un fallo tonto si tú eres el único usuario de tu máquina.
Has dicho UNIX en lugar de Linux ... tú vas a ser de una edad ya respetable.
P.S. Yo empecé a currar con UNIX y XENIX (y luego con SunOS, Solaris y HP-UX) antes de que hubiera Linux.
Si por la razón que sea alguien logra entrar como www-data (normalmente no se puede), es una cagada gorda, y si combinas eso con el fallo de sudo, entonces la cagada es completa.
Cuando decía "fallo tonto" estaba hablando sobre todo de un sistema de escritorio típico, donde el único usuario eres tú y no ofreces servicios al exterior (no tienes puertos abiertos en el router, etc).
* SECURITY UPDATE: dir existence issue via sudoedit race
- debian/patches/CVE-2021-23239.patch: fix potential directory existing
info leak in sudoedit in src/sudo_edit.c.
- CVE-2021-23239
* SECURITY UPDATE: heap-based buffer overflow
- debian/patches/CVE-2021-3156-pre1.patch: check lock record size in
plugins/sudoers/timestamp.c.
- debian/patches/CVE-2021-3156-pre2.patch: sanity check size when
converting the first… » ver todo el comentario
Me dirás que tú no usas sudo para administrar tu máquina?
Cuando yo administro mi máquina soy Dios. No un sucedáneo.
En la Raspberry, lo mismo. Root no exist a menos que lo habilites. Es decir, la tendencia de las distros es que se use sudo.
Y si, es Ubuntu. Que le vamos a hacer.
Y raspberry.
Y algunos otros.
Sobre todo, sistemas domésticos. Y NO. La tendencia no es "a que se use sudo".
github.com/slicer69/doas
sudo "hazme un sandwich"
a ver si puedes hacer eso doas
geekland.eu/configurar-sudo-en-linux/
Edit: Bueno, creo que sí lo pillo: Que siguen saliendo vulnerabilidades "de las de toda la vida" sin ser por culpa de tecnologías "nuevas" (como unicode).
En esos entornos es donde sudo es peor idea.
su -
work
exit
En realidad sudo es muy modular y muy fino y bien configurado muy seguro.
EXACTAMENTE. El uso de sudo debe ser la excepción y no la regla.
Su uso se justifica prácticamente solo por la existencia de software mal desarrollado o mal configurado.
Si escribes "sudo <orden>", se te solicitará la contraseña del súper usuario (llamado "root"), lo que viene siendo un usuario con privilegios de administrador. Si… » ver todo el comentario
sudo permite ejecutar comandos como otro usuario, pero este "otro usuario" no tiene que ser root, eso se define en el /etc/sudoers
La clave que te pide, por defecto, es la del usuario que llama a sudo. su es un comando que permite ejecutar una sesión como otro usuario (tampoco es solo como root, que también hay esa confusión habitual, es como cualquier otro usuario) y su si te pide la clave del usuario como el que quieres ejecutar la shell. Esto es así por… » ver todo el comentario
+10
Pero una vez dentro con un usuario sin privilegios puedes adquirirlos cuando los necesites.
Eres de esos que tiene el administrador deshabilitado ???
(Siempre hablando en entornos de escritorio, no empresarial, claro)
EXACTO. Y eso es un problema. Que pasa si alguien tiene conocimiento de la pass de ese usuario ?????
Encima puede conectarse remotamente....
sudo no necesita exit.... a no ser que uses sudo para hacer sudo bash, lo cual ya es el colmo de los despropósitos.
Otra cosa es que por defecto en muchas distros venga configurado para suplantar a root, pero eso es una fuente de problemas de seguridad y por eso muchos desaconsejan su uso.
Yo lo usaba hasta el OpenSolaris por ser más configurable que pfexec, no te digo más.
El sistema lo gestiona el administrador. En Linux es root.
Que el usuario X pueda parar y reiniciar servicios es una idea pésima. Y que necesite ser root para arrancar y parar aplicaciones es una idea aún peor.
En cualquier entorno mínimamente complejo tienes sudo a patadas, y no solo para ejecutar tareas como root, sino también para tareas que se hacen con un usuario diferente al que te logeas.
Servicios como cuales?
que muchos servicios se arranquen como root
Claro. Pero esos servicios solo los debe administrar el administrador.
En cualquier entorno mínimamente complejo tienes sudo a patadas
Pues en mi sistema no está. Y administro una red de más 300 equipos con todo tipo de servicios, muchos de ellos virtualizados.
no solo para ejecutar tareas como root
Para… » ver todo el comentario
En sistemas medianamente grandes, tienes un montón de gente administrando aplicativos, y hay que gestionar infinidad de excepciones, para que no todo el mundo sea administrador, y para tener un seguimiento de las tareas que se hacen como tal.
sudo es una herramienta con multitud de aplicaciones, y mucho menos específica de lo que crees. Si el aplicativo "tal" necesita acceder a cierto comando como root, se le genera una… » ver todo el comentario
Las aplicaciones NO se deben ejecutar con permisos de administración ni deben necesitarlos para funcionar. Y mucho menos en "sistemas medianamente grandes"
Dime ejemplos de esos "aplicativos" que necesitan "root" para ser administrados.
sudo es una herramienta con multitud de aplicaciones, y mucho menos específica de lo que crees
sudo es una herramienta que se… » ver todo el comentario
No se que máquinas gestionas, pero en cuanto tienes equipos de más de una persona, y necesitas un mínimo de control, sudo es la solución.
Tarea del administrador. Un usuario jamás tendría por qué rearrancar el apache.
o cualquier aplicación que escuche en un puerto privilegiado
Ninguna aplicación de usuario debería escuchar en un puerto privilegiado. Por eso se llaman "puertos privilegiados"
¿gestionar las páginas estáticas de un servidor web, por ejemplo, lo tiene que hacer un administrador?
Para eso no se necesita sudo para nada. Están los permisos y las ACL
si en
… » ver todo el comentario
Si tienes multitud de máquinas, y tienes a varios equipos (BBDD, aplicaciones web, middleware, ...) trabajando, no todo lo hace el administrador, y no todos los que tienen que trabajar en las máquinas tienen que ser administradores de todo.
P.D.: Los programadores no huelen las máquinas.
Ni las BBDD, ni las aplicaciones web requieren para nada privilegios de administrador a poco bien configurados que estén los sistemas.
Y el middleware que lo pida es una puta mierda.... y si. En esos casos habría que usar sudo PARA ESE MIDDLEWARE en exclusiva
Los que tienen que trabajar en las máquinas NO TIENEN QUE SER ADMINISTRADORES DE NADA..... El que admiinistra es el administrador, no el usuario.
P.D.: Los programadores no huelen las máquinas.
Será por el coronavirus...
Y cuidado con él.
acceder al sistema como root y trabajar normalmente como ese usuario está totalmente desaconsejado,
Por supuesto. Es una locura. Nadie en su sano juicio hace eso:
su - & administrar & exit
Un ejemplo: Tienes al usuario juan con el que te conectas alegremente por ssh (porque como root no puedes) y luego una vez conectado usas sudo para hacer tareas de administración.....
Que ocurre si la contraseña de juan se ve comprometida ?????
Ocurre que pierdes el control de tu máquina, porque de facto, juan ES root.
No es una "cuestión de costumbres", hay constumbres más seguras, menos seguras y temerarias.
Estas juzgando buenas practicas usadas ampliamente mirándolas a través del embudo de tus necesidades y tus costumbres.
Ni casi nadie que use Debian. No es necesario para nada.
Los Ubunteros son otra cosa...
su - & work & exit
Eso es un síntoma de administración negligente.
El uso de sudo debería ser muy puntual y específico, no "para administrar". Para administrar está el administrador.
El administrador SOLO debe administrar. Un usuario NUNCA debe administrar. Ni sudo ni leches.
No todo es Ubuntu en la vida.
Pero generalmente, sudo es completamente innecesario e incluso inconveniente (sobre todo si le das a un usuario TODOS los privilegios que es lo más habitualmente se hace)
Pero si miramos más allá del escritorio, sudo es la forma estándar de administrar un sistema remoto en algunos servicios en la nube. Por ejemplo, cuando creas una máquina virtual con Debian en Google Cloud, tienes que poner un usuario normal al que accedes mediante ssh con clave pública, y ese usuario puede convertirse en root usando sudo sin contraseña.
Cuando tienes cientos o miles de máquinas, esa es la forma en la que luego herramientas como ansible te permiten ser root en todas esas máquinas sin volverte loco.
Una idea pésima. Es el equivalente a permitir a root el acceso remoto. No hay diferencia.
tienes que poner un usuario normal al que accedes mediante ssh con clave pública, y ese usuario puede convertirse en root usando sudo sin contraseña.
Para eso no es necesario sudo, tienes su - CON contraseña, que es más seguro.
Sin embargo, esta configuración me convence más. El "atacante" además de conocer la password del usuario necesita acceder antes a su equipo. Pero si lo consigue, tiene root en la máquina Google Cloud.
Añado: q4os, un derivado de debian, también, a ver la raspi...
Cuando lo vi ya me imaginaba que había alguna vulnerabilidad
malloc(): corrupted top size
Avortat (s'ha bolcat la memòria)
double free or corruption (out)
Avortat (s'ha bolcat la memòria)
El sudo sin actualizar, por cierto. Miro las actualizaciones y el sudo está para actualizar.
Tras actualizar:
usage: sudoedit [-AknS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p
prompt] [-T timeout] [-u user] file ...
imgs.xkcd.com/comics/sandwich.png
Sudo es peligroso, hay que evitar utilizarlo siempre que sea posible, y si es imprescindible hay que configurarlo con mucho cuidado. Es una superficie vulnerable justo donde es más peligroso.
La diferencia es que la anterior vulnerabilidad era jodida de explotar ya que había que tener el sudo configurado de una forma muy peregrina que no tenía nadie, pero esto es un desbordamiento de buffer de toda la vida.
Yo vivo bastante bien sin sudo en la mayoría de mis sistemas. Un uso cuidadoso de los usuarios, permisos y grupos es suficiente el 95% de los casos. Incluso el sticky bit es menos peligroso.