2 vulnerabilidades críticas en Sudo comprometen millones de sistemas Linux y Unix

Investigadores de ciberseguridad revelan 2 fallas graves de seguridad en Sudo, herramienta esencial en Unix y Linux para ejecutar tareas administrativas: CVE-2025-32462 (Error en la opción --host con más de 12 años de antigüedad: en Sudo de 1.8.8 a 1.9.17) y CVE-2025-32463 (Abuso de chroot y manipulación del entorno NSS, desde Sudo 1.9.14 (2023)). Permiten escalada de privilegios y afectan a múltiples distribuciones, incluyendo Ubuntu, Fedora y macOS Sequoia. La única solución efectiva es actualizar a Sudo 1.9.17p1 o versiones superiores.

[#47 ccguy]

#12 ah pues si en tu sistema ya está corregido, irrelevante sin duda.

[#9 winstonsmithh]

sudo su putamadre

[#20 lameth]

#9 Acabas de describir esto: si no metes sudo su no tienes casi problema.

[#1 Hombre_de_Estado]

Otras fuentes (yo la ví en Linux Magacine; mandé de Laboratorio Linux por ser de lo poco que ví en español, aunque no conocía esa fuente):
- www.linux-magazine.com/Online/News/Bugs-Found-in-sudo
- linuxsecurity.com/news/security-vulnerabilities/sudo-flaws-linux-privi
- www.hostzealot.com/blog/news/major-linux-distros-impacted-sudo-vulnera
- cybernews.com/security/critical-linux-sudo-flaw-discovered/
- www.scworld.com/news/two-bugs-for-linux-sudo-utility-patched-one-rated

Lo mando porque parece relevante, pero tampoco es que yo controle del tema. Si alguien se anima a comentar su importancia o dejar otros enlacecs, gracias por adelantado.

[#2 estreñido]

#1 Ya te contesto yo.

El titular es basura infecta.

Son dos vulnerabilidades que permiten escalar privilegios o ejecutar código arbitrario a un usuario que ya tenga acceso a la máquina.

La primera es algo más seria ya que podría permitir la ejecución de comandos que no tuvieras autorizados en el sudoers vía suplantando la confianza de host. Para aprovecharla tienes que tener un usuario con permiso para shell en el sistema objetivo. Esto limita muy y mucho el alcance de la vulnerabilidad. Se…   

[#8 frg]

#2 ¿No te quita el sueño? Si tienes los deberes hechos igual no de lo quita, pero en entornos donde tienes usuarios de mierda para hacer vete a sabes qué y donde no te han dejado actualizar pero tampoco te pagan el soporte extendido ....

Vale, no es una vulnerabilidad remota, pero es una escalada de privilegios disponible en muchísimas máquinas.

[#17 --838553--]

#8 ¿No te quita el sueño?
Creo que a nadie.

pero en entornos donde tienes usuarios de mierda para hacer vete a sabes qué
¿ Tienes alguno de esos ?

donde no te han dejado actualizar pero tampoco te pagan el soporte extendido ....
¿ De qué estás hablando ?¿ No te das cuenta que lo que dices no tiene ningún sentido ?

[#23 verocla]

#17 tiene pinta de entornos "xoño de la Bernarda".

[#70 frg]

#23 Los entornos estandarizados de muchos sitios, muchos, muchos.

[#69 frg]

#17 No tiene sentido no. La realidad es así. No todo el mundo vive en el país de la piruleta y las cosrs bien hechas.

[#32 estreñido]

#8 No me quita ni un segundo de sueño.

1. En una máquina de escritorio si alguien tiene acceso shell, también tendrá acceso físico a la máquina. ¿Qué más da entonces la vulnerabilidad?
2. En un entorno remoto mis usuario no tienen acceso shell. Los que pueden tener acceso shell porque se han delegado en ellos responsabilidades... se han delegado en ellos responsabilidades porque existe un control y confianza en ellos.

Realmente la primera vulnerabilidad no ha sido considerada ni media. Solo…   

[#34 avalancha971]

#8 usuarios de mierda para hacer vete a sabes qué

Usuarios de mierda por no saber hacer muchas cosas, hay muchos.

Ahora, usuarios de mierda que activamente sean capaces de aprovecharse del exploit y se dediquen a hacerlo (raro sería que no supieran que no deben hacerlo), pues me extrañaría tener alguno.

[#68 frg]

#34 Aparte que los usuasios son muy creativos, esos usuarios de mierda son los que primero caen ante amenazas externas, y los primeros que van a ser usados comi vector de ataque.

[#40 troll_hdlgp]

#8 "pero en entornos donde tienes usuarios de mierda para hacer vete a sabes qué y donde no te han dejado actualizar pero tampoco te pagan el soporte extendido"

En un entorno así estas vulnerabilidades son el menor de los problemas...

[#67 frg]

#40 No, en entornos así estas vulnerabilidades te dan miedo y son uno más de tus problemas.

[#55 Cuñado]

#8 A muchos que tienen responsabilidades reales probablemente sí. Ya sólo pensando en los miles de desarrolladores de cárnicas que tienen acceso a máquinas de desarrollo, staging e incluso producción en entornos corporativos, los miles de operadores de SOCs y NOCs con acceso a entornos de administración... Cualquier empresa, ya no digo grande, sino incluso mediana tiene usuarios externos en sus sistemas. Y eso ya sin pensar en accesos no autorizados escalando privilegios como si fuese la…   

[#58 chavi]

#8 El sudo es una mierda.

Así de claro.

Yo lo tengo desactivado desde hace muuuuucho tiempo.

[#61 sillycon]

#58 es una superficie vulnerable enorme. En escritorio al final no hay más remedio que ponerlo, muchas aplicaciones confían en que vas a iniciarlas como usuario y luego pasan a admin con sudo, pero en servidores, con un poco de maña, se puede vivir sin él.

[#66 frg]

#58 #61 Vale. Entonces, ¿qué usas?

En esos servidores que mencionas, ¿sólo trabajas tú?

A mi me resulta imprescindible.

[#73 chavi]

#66 ACL , AppArmor y permisos. Y el administrador usa la contraseña de root.

En algunas situaciones sudo puede ser útil, pero no en muchas.

Para que usas tu sudo ??

[#75 frg]

#73 Para todo. Desde proveer ciertos comandos a algunas aplicaciones y programas hasta permitir que ciertos usuarios puedan hacer ciertas cosas. Para Todo

[#77 chavi]

#75 Pues no es necesario. Y es mala idea.

Hay mejores formas de hacerlo. En casos extremos incluso recurriendo a contenedores

[#79 frg]

#77 Me es absolutamente necesario. No se como sustituyes lo que te da sudo con "ACL , AppArmor/selinux y permisos", cuando la única alternativa que vería viable es "polkit". Tampoco veo como "hay mejores formas de hacelo" y que tienen que ver los contenedores es todo esto.

[#82 chavi]

#79 Pon un ejemplo.
En caso de aplicaciones que necesiten permisos especiales de usuarios, si la cosa es muy complicada, se pueden poner a funcionar en un contenedor aisladas del resto del sistema.

[#83 frg]

#82 ¿Ejemplos? todos. Desde usuarios de terceros que tienen que poder levantar y parar ciertos servicios, o ejecutar ciertos comandos con privilegios bajo demanda, a aplicaciones que tienen que ejecutar algún comando con otro usuario (cualquiera aplicación de monitorización puede valer para el ejemplo), pasando por todo tipo de elementos de integración con otros sistemas, CI y similares.

No se que sistemas administras, ni en qué volumen, pero eso de "ponerlas en un contenedor" no es una solución para nada.

Repito, la única solución viable a sudo es polkit, y no se como se implementaría en sistemas heterogéneos con multitud de mierdas.

[#84 chavi]

#83 ejecutar ciertos comandos con privilegios bajo demanda,
¿ Por ejemplo ?

usuarios de terceros que tienen que poder levantar y parar ciertos servicios
¿ Por ejemplo ?

aplicaciones que tienen que ejecutar algún comando con otro usuario
Mal diseño de la aplicación. Si necesitan un usuario "normal" sudo sin problemas, pero si neesitan root a un container

Realmente no veo la necesidad de sudo en el 99% de los casos.

Y si, los contenedores son una muy buena solución. No veo el problema.

[#85 frg]

#84 Voy a dejar esta conversación porque o me estás vacilando o no has administrado más de dos máquinas en tu vida, y con el mismo software en ambas.

[#89 chavi]

#85 Ajá.
No tienes ejemplos.

En Debian por ejemplo no se instala sudo con el sistema.

¿A qué crees que se debe ?

[#90 frg]

#89 Si necesitas ejemplos de lo que he comentado es porque no tienes que tener esta conversación.

El ejemplo de Debian es del género ...

Mira las estadísticas de instalación del sudo, y eso contando que pocos sistemas empresariales enviarán el "Popularity contest"

Al ignore por merluzo.

[#94 sillycon]

#90 ignorame también a mí si quieres, porque aparte del tono de superioridad que usa, estoy de acuerdo con lo que dice.
Para varias de las necesidades que dices se pueden usar grupos, permisos, y el SUID bit.

[#95 frg]

#94 #93 Dios mío

¡Deseo concedido!

[#102 lolerman]

#90 Se puede vivir sin sudo. Necesitar sudo hasta para mear es un ejemplo de no tener los permisos bien establecidos. Si te piden ejemplos es por que piensan (igual que pienso yo) que es posible modificar uno de esos escenarios que te parecen imprescindibles para arreglar los permisos y que no necesites sudo.

En mi opinión sudo es popular por que en todos los manuales hacen referencia a él. Y el motivo de que hagan referencia a sudo es que los manuales no van a profundizar en los temas de los…   

[#93 sillycon]

#66 literalmente, sólo entro yo al sistema. El resto de los servicios tiene su propia gestión de usuarios.

[#42 Cuñado]

#2 La amenaza de una vulnerabilidad no se puede medir por sí sola. El riesgo no está únicamente en que un usuario autorizado pueda conseguir root en una máquina sino, sobre todo, en que un acceso no autorizado pueda escalar privilegios de una manera tan simple.

Por otra parte, que haya sido parcheada es parte del fair-play de la publicación de amenazas (generalmente el investigador reserva un CVE y suele coordinar su publicación con el afectado, salvo que éste que no colabore o el software ya…   

[#44 estreñido]

#42 Me parece muy bien tu parrafada:

www.incibe.es/incibe-cert/alerta-temprana/vulnerabilidades/cve-2025-32

La vulnerabilidad es BAJA (2.80).

Así que no me quita nada el sueño. De hecho cuando he contestado no la había leído bien. Aprovecharla necesita de tantos "debe" previos que me parece risible. Hay sistemas que pueden tener las condicionantes para poder aprovechar esa vulnerabilidad de SUDO? Sí, seguro que los hay. Pero aun así el atacante que quiera aprovecharse de…   

[#52 Cuñado]

#44 Me alegro por tu descanso, pero veo que no has entendido una mierda de lo que he dicho. De hecho, yo tampoco había leído bien... tus comentarios. Si no no habría perdido el tiempo comentando con alguien que cree que la explotabilidad de una amenaza se mide únicamente por su CVSS y que es capaz de decir en el mismo comentario que una amenaza es risible... reconociendo que muchas distribuciones hacen mal uso de sudo

En fin, es obvio que tienes menos calle que una alfombra. No pierdo…   

[#54 estreñido]

#52 Esa es la otra que necesita mucho más andamiaje para aprovecharse. Realmente son dos.

La cve-2025-32462 que es leve

Y la cve-2025-32463 que crítica (por la ejecución de código arbitrario) no por su facilidad de explotación. No es fácil explotar esta segunda.

Muchas distribuciones hacen mal uso de SUDO, pero no los sistemas mantenidos que pueden ser el objetivo de estos dos exploits donde el sudo se tiene que considerar bien configurado... porque si no está bien configurado ya no te hace ninguna falta escalar privilegios, solo el acceso shell.

Miedo tengo que tengas alguna responsabilidad de algún tipo.

[#57 Cuñado]

#54 Que no es fácil de explotar dice... Supongo que para alguien que sólo ha usado sudo para instalar algo en su máquina, no, desde luego.

Dudo que entiendas algo, pero para los que sí: github.com/pr0v3rbs/CVE-2025-32463_chwoot

[#62 sillycon]

#52 estoy con estreñido. Es una de tantas vulnerabilidades de sudo que sólo se puede explotar con una configuración concreta en un entorno determinado. Hay muchas otras más preocupantes.

[#64 Cuñado]

#62 Todas las vulnerabilidades requieren de una configuración concreta y un entorno determinado. La cuestión es que esta configuración y este entorno son muy comunes: sudoer con chroot. De hecho, no recuerdo ninguna empresa en la que haya trabajado que no haya tenido acceso a alguna máquina en algún entorno corporativo externo con una configuración de este tipo. Ahora mismo tengo varias y podría escalar a root sin mayor problema y como yo miles de personas sin salir de España.

De todos modos, el mayor peligro está en la escalada de privilegios de usuarios no autorizados.

Honestamente, el compañero que dijo que esta vulnerabilidad era "risible" (sic) no se ha peleado con la seguridad de un entorno corporativo en su vida.

[#97 frg]

#52 Ya me gustaría parchear, pero para la multitud de máquinas que tengo sin migrar por razones que ni te imaginas (bueno, seguro que las puedes imaginar) y que no me pagan esoporte extendido se van a quedar tal cual. Casi te puedo hacer un mapa del camino por el que van a entrar ... si es wue no están dentro.

[#46 ccguy]

#2 algunos sois la hostia, os debéis pensar que cuando llegan hasta la cocina es porque ya tenían algún tipo de acceso.

Aunque sean norcoreanos entrando en datos médicos de un hospital en España.

Deberías perder el sueño con una vulnerabilidad así.

[#48 estreñido]

#46 Una vulnerabilidad que se considera baja? qué necesita que tengas un sudoers donde esté especificado un host que no sea el del sistema ni ALL?

Esto no era importante y por eso no me quita el sueño. Las cosas importantes me quitan el sueño y las cosas que no puedo controlar también. Pero esto... esto no.

[#50 ccguy]

#48 las vulnerabilidades se van encadenando. Necesitarán X pero cada una acerca al atacante al objetivo.

[#53 estreñido]

#50 Y? Esta vulnerabilidad tiene un 2.8 de gravedad porque, incluso con acceso shell, para poder aprovecharla el sistema tiene que tener una serie de condicionantes que no se dan con normalidad. Te pongas como te pongas es una cosa menor que no es noticia.

Muchisimo más importante y crítica es esta:

www.incibe.es/incibe-cert/alerta-temprana/vulnerabilidades/cve-2025-47

Y seguro que si la envío no llega a portada ni en mil años.

[#65 ccguy]

#53 vale

[#59 thingoldedoriath]

#2 Sí, el titular es mierda para moscas que comen ese tipo de residuos...

[#60 TitereConCabeza]

#2 no estoy de acuerdo , me parece un problema bastante grave a todos los niveles , sobre todo en entornos de desarrollo a los que se tiene acceso a servidores CICD , como que los propios usuarios de equipos de empresas se puedan saltar restricciones, e incluso que se puedan robar esos equipos, escalar privilegios y acceder a los datos.

Una gran cagada a todas luces.

[#80 TripleXXX]

#2 La verdad es que las vulnerabilidades que necesitan acceso a la máquina apenas me preocupan, yo uso Linux para servicios de Internet y solo tenemos acceso a la shell desde la IP de la empresa.

[#98 frg]

#80

¡Eso es seguridad!

[#103 TripleXXX]

#98 Para una empresa pequeña donde solo dos personas tienen el certificado para ssh, pues abriendo solo los dos o tres puertos que públicas creo que no me tengo que asustar mucho más.

[#12 --838553--]

#1 Lo mando porque parece relevante,
Nada relevante.
Son errores corregidos desde hace mucho tiempo enmi sistema por ejemplo y supongo que de la misma manera en otros sistemas.
Aquí nadie sabe entender esos artículos.
¿ Tienes un línux ?

[#3 pcmaster]

La única solución efectiva es actualizar a Sudo 1.9.17p1 o versiones superiores.

Eso significa que el problema ya está solucionado.

[#5 atxesun]

#3 Pues sí que sí
sudo --version
Sudo versión 1.9.17p1

[#29 hexion]

#3 #5
Debian bookworm: 1.9.13p3
Ubuntu noble (24.04): 1.9.15p5
Ubuntu plucky (25.04): 1.9.16p2

A día de hoy, todas afectadas (no he mirado los repositorios "proposed" para Ubuntu, pero en cualquier caso la gente normalmente no los configura).

[#38 meneame]

#29 Tranquilo, aunque no sean la versión que comenta el artículo, las vulnerabilidades están parcheadas. Principalmente Debian (Ubuntu va detrás), parchea directamente la versión estable que esté usando esa versión Debian. Haz un apt changelog sudo y verás que está parcheado.

[#39 estreñido]

#29 Al menos Debian no está afectada. Pero supongo que saber como funciona Debian en su empaquetado ya no es tan sexy como antes:

sudo (1.9.13p3-1+deb12u2) bookworm-security; urgency=high

* Non-maintainer upload by the Security Team.
* Local Privilege Escalation via host option (CVE-2025-32462)

-- Salvatore Bonaccorso <[email protected]> Tue, 24 Jun 2025 09:29:50 +0200

Fue corregido el 24 de junio.

[#45 kurtz_B]

#39 corregido en oldstable el 26 de junio

[#49 hexion]

#29 #39 Fallo muy de novato el mío al no mirar en apt changelog y fiarme sólo de la versión, máxime en distribuciones que no son rolling con lo que... obviamente... parchean en vez de traer versiones nuevas.

Le echaré la culpa a que ha sido un lunes largo y estoy algo espeso.

[#43 troll_hdlgp]

#29 A día de hoy, todas p...s

Debian al menos, aunque Ubutu seguro que también tienen el repositorio especial security precisamente para estos casos donde seguro que ya tienen la versión parcheada.

edit: Si, ya están corregidos en security
security-tracker.debian.org/tracker/CVE-2025-32462
security-tracker.debian.org/tracker/CVE-2025-32463

[#72 comunerodecastilla]

#29 Debian@Bookworm: grep "upgrade" /var/log/dpkg.log
2025-07-01 11:14:52 upgrade sudo:amd64 1.9.13p3-1+deb12u1 1.9.13p3-1+deb12u2

Eso viene a decir que esa vulnerabilidad esta parcheada desde el 1 de julio (evidentemente eso dependera de cuando se actualizara el sistema).

[#6 a1984]

#3 Sí, pero la cantidad de servidores no actualizados que existen implica que no está solucionado en esos servidores.

[#13 --838553--]

#6 Bueno, si no le pones gasolina a tu coche, no anda y si tienes un servidor sin actualizar, no se actualiza.
No hay servidores críticos no actualizados. Si tienes un servidor sin mantenimiento, es que para ti no es crítico, por mucho que digas lo contrario.

[#16 a1984]

#13 Que no se trate como crítico no significa que no lo sea. En los míos intento esmerarme y aplicar buenas prácticas de forma automatizada, pero no hace falta tener mucha experiencia en el sector para saber que hay demasiadas negligencias.
.

[#21 --838553--]

#16 para saber que hay demasiadas negligencias.
Se es negligente con lo que no es crítico.
Si algo es crítico de verdad, no se pone a gestionarlo a una persona sin experiencia, malpagada y saturada de otros trabajos.
Si a los jefes les da igual, es que no es crítico para ellos.
Tu concepto de crítico no casa para nada con el mío. El mío dice que si es crítico, lo cuidas y si lo descuidas es porque para ti no tiene importancia. El tuyo dice que aunque se desatienda de manera negligente, se dice que es crítico y ya está.

- Hijos míos, sois lo más importante para mí.
.- Gracias Papá. Danos de comer, por favor.
- Veremos si me queda dinero después de comprar tabaco y a lo mejor os doy algo.

[#22 a1984]

#21 No, castel, yo lo que estoy diciendo que hay servidores que son críticos y no se tratan como tales, se les califique así o no por sus dueños.

Por desgracia, la definición de crítico no está relacionada con cómo se le cuida.

Si a los jefes les da igual, es que no es crítico para ellos.
Que no tengan conciencia de que efectivamente lo sea no hace que el servidor deje de ser crítico.

[#24 --838553--]

#22 Yo me estoy quitando de eso de cuidar la empresa más que sus propios dueños.
Llegué a la conclusión que es hacer el gilipollas.

Te entiendo perfectamente, eso sí. Si tú entiendes lo que yo digo, ya estaría.

[#28 a1984]

#24 Yo ya me quité hace años

[#30 --838553--]

#28 Pues a ti te será más fácil que a mí decir lo de "este servidor no es crítico por mucho que quieras catalogarlo como tal porque no se quieren poner medios".

[#37 a1984]

#30 En realidad es mucho más difícil: si tu participas de la asignación de medios a las tareas, pasas a tener responsabilidad directa sin balones que tirar (merecidamente) hacia arriba.

[#35 comadrejo]

#22 Cada poco tiempo contacta una empresa conmigo, a veces incluso empresas a las que les intente vender servicios de respaldo y recuperación, con un "incendio" de perdida de datos y la cosa transcurre mas o menos asi:

Empresa: Tenemos que solucionar esto porque es ultra critico.
Yo: ¿Hay copias.... plan de recuperación?
Empresa: No.
Yo: Entonces no es crítico. Bueno me pongo el casco de bombero a ver que se puede conseguir.

[#99 frg]

#21

Ni te imaginas como se gestionan los "servicios críticos". Hay miserias en todas partes y no se cuidan ni en personal ni en recursos, da lo mismo que hables de hospitales, aeropuertos, eléctricas, ...

[#33 estreñido]

#6 En cualquier de esos servidores sin mínimo soporte... todavía necesitas acceso al sistema con un usuario legítimo.

[#36 a1984]

#33 Sí, pero si el soporte es mínimo y el server está expuesto a internet, conseguir una shell hay bastantes papeletas de que sea viable, incluso sencillo.

[#41 estreñido]

#36 Un servicio expuesto a la internet abierta y sin soporte, esta vulnerabilidad de sudo es lo que menos importa. ¿Tienes realmente algún servidor abierto y con soporte mínimo?

[#78 a1984]

#41 No, pero el porcentaje de servidores que controlo representa una fracción infinitesimal de los que existen.

Sólo con los WP sin actualizar que existen a día hoy en internet ya sería preocupante.

[#86 chavi]

#36 Si te rompen el sistema para obtener una shell remota, lo de sudo es el menor de tus problemas.

[#111 a1984]

#86 Depende. Si por algún extraño motivo, a pesar de tener la vulnerabilidad de la shell, tienes un usuario con permisos restringidos, lo de sudo es la diferencia entre una avería y una liada bastante gorda.

[#10 alfema]

#3 dependerá de la distribución, en Mint 22, derivada de Ubuntu 24.04 LTS (Noble Numbat), todavía tenemos una versión vulnerable.

~$ sudo --version
Sudo versión 1.9.15p5

[#18 --838553--]

#10 Pásate a Debian. Así lo tendrás todo al día.

[#19 alfema]

#18 gracias, pero estoy muy cómodo con la versión Cinnamon de Mint.

[#63 sillycon]

#3 generalmente se anuncia cuando ya está parcheado, si no sería un 0-day.

[#76 cocococo]

#74 Me logueo como usuario normal para el entorno gráfico y uso "su" desde la consola o desde una tty solamente cuando tengo que configurar algo o hacer alguna actualización.

[#51 hrundil]

A mí no me afecta la vulnerabilidad porque mis sistemas están actualizados o usan alternativas a sudo como doas. Lo que sí que me preocupa son los millones de sistemas en los que están mis datos personales y que seguro que no actualizan para corregir estos errores.

[#107 frg]

#51 doas me parece un sudo limitado. Muchas veces se usa sudo configurado con logserver para auditar cuando le dejas a ciertos usuarios hacer cosas, algo muchas veces imprescindible.

[#27 cocococo]

Yo llevo casi toda la vida usando GNU/Linux y nunca he usado "sudo", siempre "su". Es que "sudo" ni lo tengo instalado.

[#56 navi2000]

#27 Algunos vivís la vida a tope!

[#87 chavi]

#56 Por qué exactamente ?

sudo no es mejor que su. Solo hay que usarlo bien.

¿ Cuanta gente usa sudo para hacer sudo su - ?

[#109 navi2000]

#87 Con "sudo su" eliminas un problema, pero hay otros. El principal es el control fino: con sudo controlas exactamente qué comandos estás ejecutando como root, mientras que si accedes con su, todo es root. Por ahí iba mi comentario. Si vas con mucho cuidado pensando cada comando que escribes, no debería ser un problema, pero todos sabemos que un día de pesadilla a las 4 de la madrugada, podemos equivocarnos y liarla parda. Y cuando la lías parda y encima eres root, la cosa puede acabar realmente mal.

[#74 Tribuno]

#27 No me digas que te logeas como root directamente.

[#88 chavi]

#74 su no es un login.

[#92 Tribuno]

#88 SU es login. El nombre viene de switch user.

[#96 chavi]

#92 No. No es "login".
SU permite adquirir los privilegios de un usuario durante un tiempo. No se usa para trabajar en el sistema. O no se debe usar.

No hay diferencia de fondo entre sudo y su.
De hecho un sudo su - es igual que un su - pero sin necesidad de conocer la password de administración.

[#100 frg]

#27 En tu casa da un poco igual. En entornos empresariales es, a mi parecer, imprescindible.

[#25 Jakeukalane]

#15 bueno, un fallo en sudo a la larga llega pero la gente que usa esos medios no deben de usar Linux porque se habrían dado cuenta de una actualización de sudo, como hice yo.
Mi punto es que los periodistas son lentos. Lleva corregido una semana.

[#7 Jakeukalane]

Es de hace semana y media aprox. Y yo pensando, es bastante grave, porque no salen noticias. Es que les cuesta

[#15 --838553--]

#7 No sé de qué hablas.
El ciclo de detectar errores y corregirlos es algo muy ágil y desarrollado al menos en el mundo línux. Errores y soluciones se deben estar publicando a decenas cada día. ¿ Quieres que todas salgan en las noticias ?
No le veo ninguna ventaja y sí una gran desventaja: personas como #0 se alteran y se ponen nerviosos pensando que si algo tiene un error, debe estar pasando algo gordo.

[#91 Lerena]

Es una vulnerabilidad o una feature de la NSA ?.
Por cierto, yo tengo Linux actualizado y me afecta. Al hacer "sudo -V" Me aparece sudo versión 1.9.15p5

[#101 frg]

#91 Mira el changelog, no vaya ser que hayan parcheado también la versión que utilizas, algo que suelen hacer todas las distribuciones con soporte en curso.

[#4 a1984]

..releyendo

[#14 diablos_maiq]

sudo, la utilidad del verano

[#71 geburah]

Bueno, antes tienes que llegar y esperar que ya no estén arregladas automáticamente.

Pero hay que llegar. Como de crítico es algo que requiere que ya te hayas conectado para escalar privilegios?

Mucho ruido para poder llegar a dar una noticia.

[#11 jjmf]

Cuanto comentario de gente sudando.

[#26 sudoer]

Ostras.... Voy a actualizarme.

[#31 luspagnolu]

#26 Una pregunta. Para aquellos que, como yo, tenemos Ubuntu y no dominamos demasiado, ¿cómo actualizamos? Muchísimas gracias.

[#81 sudoer]

#31 revisa primero la versión que tienes actualmente. Abre un terminal y ejecuta sudo -V.
Te dirá la versión y podrás ver si es una de las comprometidas. Si tienes activadas las actualizaciones desatendidas (unattended-updates) sudo debería actualizarse automáticamente.
Unattended-updates viene activado por defecto en ubuntu.