BandaAncha.eu

  • 🔍 en 📰 artículos ⏎
  • 🔍 en 💬 foros ⏎
  • 🔍 en 👇 este 💬 foro ⏎
  • 🔍 en 👇 este 💬 tema ⏎
Regístrate Regístrate Identifícate Identifícate

Gravísimo fallo de seguridad en macOS High Sierra

butanito
3

Según se ha publicado, se puede acceder a todo el contenido de un Apple que tenga instalado macOS High Sierra (incluído instalar aplicaciones) a pesar de no conocer la password de acceso.

Sólo hay que poner root en el usuario dejando la contraseña en blanco, y tras varios intentos permite el accesso como por arte de magia.

Más info en español aquí: clipset.20minutos.es/apple-macos-grave-f…-login-root/

superllo
1

Si fuera Google lanzaría la actualización y se actualizarían el 10% de los dispositivos.

🗨️ 1
redline2001

Ya esta el parche para eso, relax : )

BocaDePez
BocaDePez

Eso que dices es falso. MS por muy mala prensa que tenga habría sacado al parche antes de publicarse el fallo.

🗨️ 2
BocaDePez
BocaDePez

Dejémoslo en que Microsoft no es constante en el asunto de lanzar actualizaciones.

BocaDePez
BocaDePez

En este caso no se ha solucionado antes de ser publicado simplemente porque se ha publicado antes de comunicarlo a Apple. A Microsoft o cualquier otra empresa le hubiera pasado igual y un día para arreglarlo tras ser publicado no está mal.

BocaDePez
BocaDePez

Aunque hayas soltado la tontería del día, gracias por el enlace Apple fanboy.

BocaDePez
BocaDePez

Crear el usuario «root» sin contraseña. xD

🗨️ 4
vukits

el usuario ya está creado, pero deshabilitado..

pero a nadie se le ocurrió poner contraseña

🗨️ 3
BocaDePez
BocaDePez
1

Sí bueno, el uid 0 es usado igualmente. Pero no está creado en la base de datos de usuarios y grupos (/etc/passwd y compañía). Al introducir la contraseña por primera vez lo añade a la BD sin contraseña alguna. Entonces pruebas una segunda vez con la contraseña en blanco y te deja entrar.

🗨️ 2
vukits

la verdad, parece como un feature,más que un bug 😂

🗨️ 1
BocaDePez
BocaDePez
1
BocaDePez
BocaDePez

El fallo es morrocotudo, pero al menos, en mi caso, entiendo que no pasa absolutamente nada, porque el equipo sólo lo uso yo, y desde internet no pueden hacer nada, ¿no? En fin, instalaremos el parche.

🗨️ 1
BocaDePez
BocaDePez

También sirve para sesiones de escritorio remoto.

Que el equipo sólo lo uses tú es una cosa.

Que estés absolutamente solo allí donde lo tengas es otra.

BocaDePez
BocaDePez

Llegáis tarde. Dejad de desinformar. La información debe ser completa; de otro modo es desinformación. Este problema quedó solucionado ayer, un día después de ser descubierto. No está mal.

🗨️ 2
BocaDePez
BocaDePez

No es que esté mal, es que un fallo como ese es una auténtica vergüenza aunque se parchee al día siguiente.

sierpinski

El problema queda solucionado si se actualiza. Está bien que se le dé visibilidad para que la gente instale la actualización.

BocaDePez
BocaDePez

Por cierto, el problema solo aparecía si no habías cambiado nunca el password de root (dejas el que viene por defecto), si lo habías cambiado no tienes ese problema, de hecho la solución "casera" para evitar este fallo simplemente es cambiar el password del root.

BocaDePez
BocaDePez

El el segundo fallo del bloqueo de compartir archivos ya está también arreglado, un días tras producirse. De nuevo, ha sido rápido.

mceds

Curiosidad: en una instalación típica del servidor SSH en OS X, ¿se permiten los accesos con el usuario root "por defecto"? Lo que sería PermitRootLogin=yes en el /etc/ssh/sshd_config de una instalación típica de Linux.

Porque una cosa combinada con la otra sería bastante divertido...

🗨️ 2
sierpinski

OS X no lleva el servidor ssh corriendo por defecto

🗨️ 1
mceds

Correcto. Por eso he dicho "en una instalación típica". Si está ya instalado, pues en una "activación".