Heap overflow en sudo permite conseguir privilegios de root localmente [ENG]

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

[#11 Idomeneo]

#7 En Unix hay usuarios normales, que tienen poderes limitados, y el usuario root, que es el usuario administrador. El programa sudo permite bajo ciertas condiciones que ciertos usuarios (elegidos por el administrador) tengan permisos de root. El fallo en sudo del que habla el meneo hacía que cualquier usuario pudiera tener permisos de root, a pesar de no ser de los "elegidos".

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.

[#43 pawer13]

#11 por completar un poco más: viene a ser la abreviatura de "superuser do". El usuario root (raíz) es también llamado administrador o superusuario

[#56 Desactivado]

#11

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.

[#71 Far_Voyager]

#11 Imagino que si uno es el único usuario no debería haber demasiados problemas si sudo se usa sólo para actualizaciones e instalaciones de progrsmas desde la terminal.

[#94 Desactivado]

#11 Mi duda es, si entran como usuario apache o www-data que no suele tener sudo aplicado, es un FE web, y ejecutan esto, podrían tener acceso como root a todo el sistema, no? Por lo tanto "un fallo tonto" no creo que sea...

[#97 Idomeneo]

#94 Efectivamente el caso que dices no es un fallo tonto para nada.

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

[#114 Desactivado]

#97 Ah vale, entendido. Solo un apunte, puedes entrar como www-data, ya hablando de cara a un servidor (aunque un servidor local para pruebas incluso también podrías). Basta con encontrar un file input mal filtrado que te permita subir cualquier tipo de archivo o hacer un bypass de los filtros que se aplican, ejecutas un netcat una vez subido el fichero y ale, como www-data, luego ejecutas el heap overflow y estamos apañaos

[#20 hexion]

Ya está solucionado en Debian y derivados como Ubuntu:

* 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 record to TS_LOCKEXCL in
plugins/sudoers/timestamp.c.
- debian/patches/CVE-2021-3156-1.patch: reset valid_flags to
MODE_NONINTERACTIVE for sudoedit in src/parse_args.c.
- debian/patches/CVE-2021-3156-2.patch: add sudoedit flag checks in
plugin in plugins/sudoers/policy.c.
- debian/patches/CVE-2021-3156-3.patch: fix potential buffer overflow
when unescaping backslashes in plugins/sudoers/sudoers.c.
- debian/patches/CVE-2021-3156-4.patch: fix the memset offset when
converting a v1 timestamp to TS_LOCKEXCL in
plugins/sudoers/timestamp.c.
- debian/patches/CVE-2021-3156-5.patch: don't assume that argv is
allocated as a single flat buffer in src/parse_args.c.
- CVE-2021-3156
* debian/control: added tzdata to Build-Depends so that the time zone
data directory is present during builds.

[#77 noexisto]

#20 Zemos los mejores. Ole!

[#17 llorencs]

#14 Todo dios?

[#47 chavi]

#17 No. Dios no usa sudo.

[#48 llorencs]

#47 Bueno, pero el resto de los mortales usa sudo para convertirse en dios A dios no le hace falta porque ya es dios

Me dirás que tú no usas sudo para administrar tu máquina?

[#59 chavi]

#48 No. No lo uso.

Cuando yo administro mi máquina soy Dios. No un sucedáneo.

[#66 llorencs]

#59 Pero por ejemplo algunos sistemas operativos como Ubuntu ni siquiera implementan root. Lo tienes que activar.

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.

[#68 chavi]

#66 TODOS los sistemas tienen root. Otra cosa es que no tengan la contraseña habilitada.

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

[#90 snkarcade]

#66 Exactamente. Por ejemplo Manjaro, KDE Neon o Ubunta MATE, que son las que uso actualmente.

[#12 convidat78]

#7 Porque sudo es una herramienta que viene instalada en muchas distribuciones linux, permite ejecutar un programa como si fueses otro usuario (en particular se usa para ejecutar programas como administrador, "root") siempre que tengas permiso. Pues bién, la vulnerabilidad permite que cualquiera que haya iniciado sesión en el sistema pueda ejecutar cualquier comando como root, vamos que puede hacer lo que quiera en el sistema.

[#10 Desactivado]

#9 Lo han portado desde OpenBSD a Linux.

https://github.com/slicer69/doas

[#16 llorencs]

#10 doas? La primera vez que lo veo. En que se diferencia de sudo?

[#18 Desactivado]

#16 Más simple, tanto en uso como sintaxis de configuración.

[#37 Poignard]

#18 más simple que sudo?
sudo "hazme un sandwich"

a ver si puedes hacer eso doas

[#54 mr_x]

#18 Te puedo comprar que tenga un lenguaje más “natural”, pero configurar sudo es bastante simple...

https://geekland.eu/configurar-sudo-en-linux/

[#1 noexisto]

La que está liando el unicode con los emoticonos

[#3 Idomeneo]

#1 No sé si lo pillo. ¿Es una referencia a CVE-2018-15120?

editado:

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

[#4 Desactivado]

#1 #3 Unicode no es nueva ni mucho menos. Por cierto, ojalá doas triunfe sobre sudo.

[#8 Idomeneo]

#4 Lo sé, por eso he puesto "nueva" entre comillas.

[#9 noexisto]

#4 pero eso es para BSD, no?

[#40 frg]

#4 "doas" no es un sustituto de sudo. En entornos sencillos, puede que sea la alternativa. En entornos mínimamente complejos, con varios usuarios y una alta granularidad, no te queda otra que usar sudo.

[#49 chavi]

#40 Vaya que no.....
En esos entornos es donde sudo es peor idea.

su -
work
exit

[#108 zancudo]

#49 Te habla de alta granularidad, y en tu ejemplos tú te conviertes en dueño y señor del castillo... después de leer tus afirmaciones me da la sensación de que no has usado sudo nunca y no te has molestado en aprender a usarlo.

[#75 meneandro]

#4 #31 El problema de sudo es que viene muy mal configurado por defecto (hacer que un usuario administrador sea directamente root es un peligro en si mismo; lo suyo es darle permisos específicos para cosas específicas a usuarios específicos según sus necesidades... si quieres permitir ser root aun usuario, permítele hacer sudo su root y listos).

En realidad sudo es muy modular y muy fino y bien configurado muy seguro.

[#110 chavi]

#75 suyo es darle permisos específicos para cosas específicas a usuarios específicos

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.

[#6 noexisto]

#3 Era una referencia a “in theory, however, no command-line argument can end with a single backslash character..” pero básicamente para animar a comentar

[#41 frg]

#14 ¿Quien no usa sudo?

[#5 aspen]

Iba a buscar algún comentario que dijera que el titular le suena a chino, pero ya veo que en Menéame, el paraíso de los informáticos, el friki y el raro soy yo

[#7 VdeBendito]

#5 Me ha encantado tu comentario porque venía por el mismo motivo. ¿Alguien podría explicarnos por qué ese fallo es tan importante? Como si fuese de letras, por favor.

[#13 derp]

#5 #7 "sudo" significa "super user do". Sirve para ejecutar una instrucción con privilegios de administrador, o lo que es lo mismo, como si fuésemos el usuario "root" *. Algunas instrucciones no pueden ejecutarse si no se hace de esta manera si somos un usuario digamos normal

Si escribes "sudo ", se te solicitará la contraseña del súper usuario (llamado "root"), lo que viene siendo un usuario con privilegios de administrador. Si introduces correctamente la contraseña se inicia una sesión efímera como root, que se cierra tan pronto como la orden termina de ejecutarse. Este usuario puede hacer literalmente cualquier cosa que quiera, como si quiere ejecutar la orden "bórrame todos y cada uno de los archivos que haya en el disco duro, sistema operativo incluido". Él coge y lo hace, cualquier otro usuario recibiría un error

Según esta vulnerabilidad podría usarse el comando sudo de manera "maléfica" para impersonar a otro usuario

* Cuando se habla de "rootear" un Android es precisamente esto, permitir que se inicie la sesión del sistema operativo como usuario "root" (administrador) de manera que se tiene acceso a todo el potencial del sistema

[#19 angat]

#13 pequeño detalle: sudo (al menos en debian) no pide la contraseña del usuario root, pide la contraseña del usuario actual.

[#21 derp]

#19 Cierto. En Ubuntu yo meto la del usuario actual, pero coincide con la de root así que no había reparado en ese detalle

[#24 Lito]

#21 no tiene mucha lógica que tengas que meter la contraseña de root ya que entonces todos los usuarios con algún permiso en sudo tendrían directamente la contraseña de root y podrían ser root en su totalidad. Incluso ahora ya es raro que en sistemas remotos root tenga siquiera contraseña.

[#25 derp]

#24 Me debe estar funcionando porque meto la del usuario actual. Cada vez me pregunto menos el porqué de las cosas cuando funcionan

[#29 Avantasia]

#24 #13 #19 Por puntualizar
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 diseño y poco defecto pero es configurable también en el sudoers y puede pedir una u otra clave.

La idea del sudo no es tanto que puedas hacer X sino que quede registrado y tengas que autenticarte, obviamente el mismo efecto de ejecución se podría conseguir poniendo todos los ejecutables +s y nadie con dos dedos de frente lo hace, ese paso de que tengas que poner la clave impide, por ejemplo, que programas automatizados ejecuten comandos con privilegios de otro usuario sin tu intervención, o que si alguien encuentra una vulnerabilidad y entra al sistema con tus permisos (pero sin conocer tu pass) no pueda escalar privilegios.

La clave de root está deshabilitada por defecto en Ubuntu y algunos sistemas más, es una moda horrible que empezó Ubuntu para que los usuarios no-tan-técnicos , que eran los destinatarios principales de la distribución originalmente no utilizaran el usuario root todo el tiempo y tuvieran que autenticarse para ejecutar comandos como root si o si, una especie de UAC para Linux, de ahí lo extendido de esta configuración por defecto: "root deshabilitado+un grupo de administracion en el sudoers para ejecutar cosas como root"

[#62 chavi]

#29 Mis diez.

+10

[#79 noexisto]

#29 Creo que solo en 2-3 ocasiones en 15 años habré creado un root es escritorios míos y me apabulla la cantidad de nuevos linuxeros que lo preguntan y/o se mosquean cuando se les pregunta ¿para qué? no sé, igual vienen de android

[#61 chavi]

#24 En sistemas remotos root no debe permitir el acceso.

Pero una vez dentro con un usuario sin privilegios puedes adquirirlos cuando los necesites.

[#34 Ed_Hunter]

#19 Eso es totalmente configurable, puedes hacer que pida la contraseña del usuario, la de administrador o ninguna, y puedes configurar las ordenes que se pueden ejecutar mediante sudo, qué usuarios pueden usarlas y en qué condiciones puede hacerse.

[#53 limondelcaribe]

#19 sudo su

[#64 chavi]

#53 ¿Por qué no solo su ?

Eres de esos que tiene el administrador deshabilitado ???

[#93 snkarcade]

#64 Muchos no necesitamos habilitar la cuenta root. Con un usuario y el comando antes escrito, das permiso a tu usuario a usar los permisos de root con tu cuenta . Luego das exit y vuelves a tu cuenta normal.

(Siempre hablando en entornos de escritorio, no empresarial, claro)

[#100 chavi]

#93 das permiso a tu usuario a usar los permisos de root con tu cuenta

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.

[#60 chavi]

#19 Es que si pidiera la contraseña de root pasaría de ser una herramienta prescindible a una herramienta inútil.

[#78 meneandro]

#13 sudo es "su do", sustituye/suplanta temporalmente un usuario y luego hace lo que sea como si fuera ese usuario. Para nada es un "super user do" porque es genérico (igual que suplantas root puede configurarse para suplantar apache, administrador, paquito o el usuario que sea).

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.

[#30 ochoceros]

#7 SUDO es como si trabajases en una gran compañía y cada vez que llames a alguien para pedir algo, a este le salga el identificador del número del dueño de la empresa y oiga su voz en lugar de la tuya.

[#28 Pichaflauta]

#5 yo sé que sudo es superusuario en linux y root es raiz, y permite es un verbo. Y para de contar jaja

[#27 edetano]

En Ubuntu la actualización la ya está disponible problems resuelto

[#50 limondelcaribe]

#27 Y esa es una de las magias de Linux

[#2 Desactivado]

Muy fea esta vulnerabilidad. Por suerte es complicada en remoto, porque primero hay que pasar el filtro del SSH y/o firewall, pero con la cantidad de sistemas conectados de cualquier manera a internet, vamos a tener risas los próximos meses.

[#14 chavi]

#2 Quien usa sudo?

[#15 menjaprunes]

#14 por lo visto ni el Tato

[#22 hexion]

#14 Mucha gente. Y aunque no lo uses directamente, si tienes un sistema Linux (o incluso algunos Unix) es probable que venga instalado por defecto y por lo tanto sea vulnerable.

[#46 chavi]

#22 No en Debian.

[#87 hexion]

#46 No he dicho que todas lo lleven por defecto. Pero incluso cuando no viene por defecto está en los repos y hay gente que lo usa.
Yo lo usaba hasta el OpenSolaris por ser más configurable que pfexec, no te digo más.

[#88 chavi]

#87 No lo dudo.

[#31 ruinanamas]

#14 Yo, de toda la vida, mala praxis? Quizás por desconocimiento visto los comentarios. Alguien explica porqué no usarlo?

[#35 arturios]

#31 mala praxis no, y menos para un usuario doméstico, pero un usuario normal en un entorno laboral no debería tener permisos de sudo, que para eso le pagan al admin.

[#42 frg]

#35 ¿Y como te crees que el admin consigue permisos de administración para gestionar los sistemas?, ¿y como crees que el admin deja al usuario X rearrancar un aplicativo, tras algún cambio?

[#51 chavi]

#42 sudo es útil para casos concretos muy específicos.

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.

[#55 frg]

#51 Que el usuario X gestione el arranque y reinicio de algunos servicios es lo normal, y que muchos servicios se arranquen como root (a ver como te crees que funcionan los scripts de systemd o los que se encuentren en /etc/init.d), es también lo normal.

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.

[#58 chavi]

#55 Que el usuario X gestione el arranque y reinicio de algunos servicios es lo normal

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 realizar tareas de administración lo mejor es SER el administrador

tareas que se hacen con un usuario diferente al que te logeas.
Si quieres hacer tareas con un usuario diferente solo se justifica si eres administrador. Y si eres administrador puedes convertirte en el usuario que desees.

sudo tiene su utilidad. Pero es mucho más específica y mucho menos general de lo que la gente piensa.

[#81 frg]

#58 ¿Solo los debe administrar el administrador?

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 regla en el sudoers para dicho aplicativo, que el usuario X tiene que realizar tareas con el usuario de aplicativo Y, se genera regla, que la utilidad de monitorización que funciona con su usuario tiene que mirar un comando con un usuario determinado, se genera regla, ..., y así hasta la nausea.

[#83 chavi]

#81 En sistemas medianamente grandes, tienes un montón de gente administrando aplicativos
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 le puede dar un "uso general" pero que cualquier persona con dos dedos de frente solo la utilizaría para propósitos muy específicos, sobre todo en sistemas "medianamente grandes".

Si el aplicativo "tal" necesita acceder a cierto comando como root
Pues entonces o es una mierda de aplicativo, o es un aplicativo que SOLO debería gestionar el administrador.

Dame un ejemplo.

[#85 frg]

#83 ¿Rearancar un apache o cualquier aplicación que escuche en un puerto privilegiado te parece que no necesita root?, ¿gestionar las páginas estáticas de un servidor web, por ejemplo, lo tiene que hacer un administrador?, si en la máquina quieres saber quien se conecta, cada usuario que gestione cualquier cosa tiene su usuario, y luego usa sudo para realizar tareas con el usuario del aplicativo, ¿esto solo lo puede hacer el administrador?

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.

[#89 chavi]

#85 Rearancar un apache

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 la máquina quieres saber quien se conecta,
Eso solo le interesa al administrador

cada usuario que gestione cualquier cosa tiene su usuario
A qué le llamas "Cualquier cosa" ?

sudo para realizar tareas con el usuario del aplicativo
No he negado la utilidad de sudo para tareas muy específicas y concretas. Si como herramienta para administrar.

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.
Es justo en esos entornos en los que sudo es un PROBLEMA en lugar de una solución. Muchas veces es una ñapa para mantener equipos administrados de modo negligente.

Que el programador de una web necesite sudo para modificar o actualizar código de su web es un ejemplo claro. Eso es una barbaridad.

[#92 frg]

#89 ¿Programador? Sigo diciendo que no se en dónde has trabajado, pero intuyo que en sitios muy pequeños.

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.

[#101 chavi]

#92 Si tienes multitud de máquinas, y tienes a varios equipos (BBDD, aplicaciones web, middleware, ...) trabajando, no todo lo hace el administrador

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

[#95 txotin]

#58 Estas hablando de tu caso concreto y de tus costumbres, pero casos de uso hay muchos y muy variados, sobre todo cuando hablamos de sistemas. En todos los sabores de unix el uso de sudo es un standard, mientras que acceder al sistema como root y trabajar normalmente como ese usuario está totalmente desaconsejado, y se hace así por razones muy bien fundadas y documentadas al alcance de todo el que se quiera informar sobre ellas.

[#99 chavi]

#95 también es un standard el uso de rm.....

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.

[#104 txotin]

#99 Hay las mismas posibilidades de perder la clave de juan que la de root, que por otra parte es un problema que tiene poco que ver con sudo. De hecho uno de los casos de uso con los que mas me encuentro es usuarios sin clave que acceden mediante clave pública y usan sudo para reiniciar servicios que deben ser arrancados por root al abrir puertos por debajo del 1024. Y digo usan, no he dicho escriben.

Estas juzgando buenas practicas usadas ampliamente mirándolas a través del embudo de tus necesidades y tus costumbres.

[#33 arturios]

#14 cualquiera que use linux.

[#45 chavi]

#33 Yo no.
Ni casi nadie que use Debian. No es necesario para nada.

Los Ubunteros son otra cosa...

su - & work & exit

[#63 molekiller]

#45 con sudo puedes limitar los privilegios y lo que permites ejecutar, con su - no. Para el PC de casa vale, para la empresa no.

[#67 chavi]

#63 Claro que vale para la empresa. Lo que es una locura es estar autorizando usuarios con sudo.
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.

[#69 molekiller]

#67 No todo es root o usuario plano, a veces necesitas que un usuario "operador" pueda ejecutar 3 comandos específicos con privilegios, pero nada más, no necesita ser root. Eso lo puedes hacer con sudo, y nadie ha dicho que lo apliques al usuario juanperez, sino a operador01.

[#72 chavi]

#69 Puntualmente. En casos muy especiales. A veces en situaciones determinadas y para tareas muy específicas.

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)

[#38 Poignard]

#14 quien usa sudo?? en serio?

[#44 frg]

#38 ¿En serio?, ¿quien no lo usa? En entornos mínimamente complejos, todo tiene sudo.

[#74 Poignard]

#44 no has entendido mi tono.... no ves que le contesto a uno que está preguntado lo mismo

[#82 frg]

#74 Nop, no te he escuchado con claridad. Será que te expresas con la mascarilla puesta, o que tengo el volumen del sonotone bajo.

[#84 Poignard]

#82 o que eran las 7 de la mañana y todavía no te regaba bien la almendra, vete tu a saber

[#86 frg]

#84 No descarto ninguna de las dos opciones. La edad, el alcohol y las drogas no perdonan

[#76 noexisto]

#14 Yo pero me avergüenzo y nunca reconoceré haberlo escrito

[#91 Idomeneo]

#14 Tú estás pensando "¿quién usa sudo en el escritorio?" y efectivamente, es estándar en Ubuntu y no lo es en Debian.

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.

[#102 chavi]

#91 , sudo es la forma estándar de administrar un sistema remoto en algunos servicios en la nube
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.

[#32 arturios]

#2 a mi me acaba de decir debian que lo actualice al ser una actualización de sistema crítica, me ha llamado la atención y ahora esta noticia.

_{Añado: q4os, un derivado de debian, también, a ver la raspi...}

[#52 chavi]

#32 Debian por defecto no trae sudo

[#96 arturios]

#52 no recuerdo haberlo instalado y la iso de debian era oficial y comprobada la suma, o igual si, a saber, el caso es que lo uso todos los días que quiero instalar algo y no me apetece perder el tiempo con synaptic.

[#98 chavi]

#96 No, sudo no viene configurado en debian.

[#112 luisfeser]

#32 +1
Cuando lo vi ya me imaginaba que había alguna vulnerabilidad

[#23 Desactivado]

Ejecutando los dos ejemplos da error.
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.

[#26 Desactivado]

#23
Tras actualizar:
usage: sudoedit [-AknS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p
prompt] [-T timeout] [-u user] file ...

[#39 MuSubDe]

¿Recordais cuando en meneame las noticias eran casi todas asi con alguna salpicada de politica o similar? ains, que buenos tiempos....me hago viejo

[#70 garabullo]

#39 Barrapunto...

[#36 freelancer]

Que sería de nosotros sin sudo
https://imgs.xkcd.com/comics/sandwich.png

[#65 chavi]

#36 Estaría bien poder cambiar el "Ok Google" por "sudo"....

[#57 sillycon]

Lo he dicho anteriormente, precísamente en la anterior vulnerabilidad (CVE-2019-14287).
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.

[#80 meneandro]

#57 No es peligroso de por si (salvo vulnerabilidad como esta), es su (en general) configuración por defecto de suplantar a root con todos sus poderes la peligrosa.

[#73 porlacausa]

A veces hay que lanzar comandos como otros usuarios www-data, por ejemplo. Ahí lo uso bastante. Aunque, como root, no sé muy bien la diferncia entre hacerlo así o lanzar: su www-data -c "lo que sea"

[#107 sillycon]

#73 Pues la diferencia es mucha. Con sudo (si no hay configuración adicional) el comando se ejecuta como root, y con "su [usuario] -c", el root ejecuta el comando como el usuario indicado.