Tecnología, Internet y juegos
164 meneos
2844 clics
Heap overflow en sudo permite conseguir privilegios de root localmente [ENG]

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

| etiquetas: sudo , unix , linux , root , heap , overflow
75 89 1 K 404
75 89 1 K 404
Comentarios destacados:              
#11 #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.
«12
  1. La que está liando el unicode con los emoticonos :roll:
  2. 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.
  3. #1 No sé si lo pillo. ¿Es una referencia a CVE-2018-15120?

    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).
  4. #1 #3 Unicode no es nueva ni mucho menos. Por cierto, ojalá doas triunfe sobre sudo.
  5. 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 :-)
  6. #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
  7. #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.
  8. #4 Lo sé, por eso he puesto "nueva" entre comillas. :-)
  9. #4 pero eso es para BSD, no?
  10. #9 Lo han portado desde OpenBSD a Linux.

    github.com/slicer69/doas
  11. #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.
  12. #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.
  13. #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 <orden>", 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
  14. #2 Quien usa sudo?
  15. #14 por lo visto ni el Tato :-D
  16. #10 doas? La primera vez que lo veo. En que se diferencia de sudo?
  17. #14 Todo dios?
  18. #16 Más simple, tanto en uso como sintaxis de configuración.
  19. #13 pequeño detalle: sudo (al menos en debian) no pide la contraseña del usuario root, pide la contraseña del usuario actual.
  20. 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.
  21. #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
  22. #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.
  23. #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.
  24. #24 Me debe estar funcionando porque meto la del usuario actual. Cada vez me pregunto menos el porqué de las cosas cuando funcionan :shit:
  25. En Ubuntu la actualización la ya está disponible problems resuelto
  26. #5 yo sé que sudo es superusuario en linux y root es raiz, y permite es un verbo. Y para de contar jaja
  27. #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"
  28. #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.
  29. #14 Yo, de toda la vida, mala praxis? Quizás por desconocimiento visto los comentarios. Alguien explica porqué no usarlo?
  30. #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...
  31. #14 cualquiera que use linux.
  32. #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.
  33. #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.
  34. Que sería de nosotros sin sudo
    imgs.xkcd.com/comics/sandwich.png
  35. #18 más simple que sudo?
    sudo "hazme un sandwich"

    a ver si puedes hacer eso doas
  36. #14 quien usa sudo?? en serio?
  37. ¿Recordais cuando en meneame las noticias eran casi todas asi con alguna salpicada de politica o similar? ains, que buenos tiempos....me hago viejo
  38. #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.
  39. #14 ¿Quien no usa sudo?
  40. #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?
  41. #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
  42. #38 ¿En serio?, ¿quien no lo usa? En entornos mínimamente complejos, todo tiene sudo.
  43. #33 Yo no.
    Ni casi nadie que use Debian. No es necesario para nada.

    Los Ubunteros son otra cosa...

    su - & work & exit
  44. #22 No en Debian.
  45. #17 No. Dios no usa sudo.
  46. #47 Bueno, pero el resto de los mortales usa sudo para convertirse en dios :-D A dios no le hace falta porque ya es dios :-D

    Me dirás que tú no usas sudo para administrar tu máquina? :-D
  47. #40 Vaya que no.....
    En esos entornos es donde sudo es peor idea.

    su -
    work
    exit
  48. #27 Y esa es una de las magias de Linux
  49. #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.
  50. #32 Debian por defecto no trae sudo
  51. #18 Te puedo comprar que tenga un lenguaje más “natural”, pero configurar sudo es bastante simple...

    geekland.eu/configurar-sudo-en-linux/
  52. #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.
  53. #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.
  54. 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.
  55. #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.
  56. #48 No. No lo uso.

    Cuando yo administro mi máquina soy Dios. No un sucedáneo.
  57. #19 Es que si pidiera la contraseña de root pasaría de ser una herramienta prescindible a una herramienta inútil.
  58. #24 En sistemas remotos root no debe permitir el acceso.

    Pero una vez dentro con un usuario sin privilegios puedes adquirirlos cuando los necesites.
  59. #29 Mis diez.

    +10
  60. #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.
  61. #53 ¿Por qué no solo su ?

    Eres de esos que tiene el administrador deshabilitado ???
  62. #36 Estaría bien poder cambiar el "Ok Google" por "sudo".... xD xD xD xD xD
  63. #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.
  64. #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.
  65. #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".
  66. #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.
  67. #39 Barrapunto...
  68. #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.
  69. #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)
  70. 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"
  71. #44 no has entendido mi tono.... no ves que le contesto a uno que está preguntado lo mismo
  72. #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.
  73. #14 Yo pero me avergüenzo y nunca reconoceré haberlo escrito :-D
  74. #20 Zemos los mejores. Ole!
  75. #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.
  76. #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 :-S
  77. #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.
  78. #58 ¿Solo los debe administrar el administrador? xD

    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.
  79. #74 Nop, no te he escuchado con claridad. Será que te expresas con la mascarilla puesta, o que tengo el volumen del sonotone bajo. :-D
  80. #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.
  81. #82 o que eran las 7 de la mañana y todavía no te regaba bien la almendra, vete tu a saber
  82. #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.
  83. #84 No descarto ninguna de las dos opciones. La edad, el alcohol y las drogas no perdonan :-D
  84. #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.
  85. #87 No lo dudo.
  86. #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.
  87. #66 Exactamente. Por ejemplo Manjaro, KDE Neon o Ubunta MATE, que son las que uso actualmente.
  88. #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.
  89. #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.
  90. #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)
  91. #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...
  92. #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.
  93. #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.
  94. #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).
  95. #96 No, sudo no viene configurado en debian.
  96. #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.
  97. #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.
«12
comentarios cerrados

menéame