¿Qué tan seguro es el control de acceso de Llavero de OS X?

7

En OS X, cuando una aplicación solicita acceso a un elemento de Llavero, se le indica al usuario si otorga o niega ese acceso.

Supuestamente, el sistema guarda no solo la ruta binaria, sino también su hash en la entrada de ACL que se crea después de que el usuario confirma la solicitud; según Apple , esto protege contra binarios modificados que tienen acceso a contraseñas de usuario y / o certificados.

¿Es esto realmente suficiente para evitar que un atacante con permisos de usuario (pero no de superusuario) recupere todas las contraseñas almacenadas?

En Linux, por ejemplo, existe la variable de entorno LD_PRELOAD que se puede usar para cargar bibliotecas dinámicas adicionales que sobrescriben algunas funciones de biblioteca estándar con código personalizado; Usando eso, parece ser posible cambiar el código que se ejecuta dentro de un binario dado sin modificar el ejecutable base en sí mismo.

¿Hay un mecanismo similar en OS X que permita este tipo de ataque? (quizás uno de los métodos mencionados here )?

    
pregunta lxgr 30.10.2013 - 14:24
fuente

3 respuestas

1

El límite de seguridad es root, es decir, securityd se ejecuta como root. Si securityd y su ACL se implementan correctamente, no hay forma de que otra aplicación acceda a la clave desde el llavero. Sin embargo, Mac OS X ha tenido varias vulnerabilidades de escalamiento de privilegios que permitirían a un usuario local atacante acceder a securityd y, por lo tanto, al elemento del llavero. Es razonable suponer que un atacante moderadamente / altamente calificado aún podría encontrar la escalada de privilegios existente 0 días.

    
respondido por el fel1x 17.08.2014 - 20:30
fuente
0

por lo que sabemos, el desarrollador de OSX hace un gran esfuerzo para proteger y cifrar los datos en el llavero, y al igual que otras aplicaciones (Firefox, incluso Windows Auth), puede acceder a él con una contraseña, el único ataque real que podría el trabajo en este momento, es un registro de teclas al acceder a algo como un llavero, o mediante un ataque de diccionario / ataque por fuerza bruta al campo de "contraseña", ya que esas aplicaciones no tienen una función de "bloqueo" después de 5 intentos en 1 minuto

    
respondido por el Lighty 20.05.2014 - 13:36
fuente
0

Según tengo entendido, securityd es el proceso que interpreta & hace cumplir el llavero ACLs. Los códigos / bibliotecas en su aplicación se comunican con securitd a través de mensajes xpc. Securityd es el que abre el archivo de llavero, por lo que la inyección de código o la omisión de la biblioteca dyld en la aplicación que realiza la llamada no podrá cambiar la cantidad de acceso que pueda tener. Como lo menciona fel1x, eso deja irrumpir / subvertir a securityd. Sé que launchd tiene un código especial para tratar con securityd, ya que no reiniciará securityd si se bloquea, debe reiniciar para recuperar el sistema. También puede haber otras protecciones. Una simple escalada de raíz puede no ser suficiente para subvertir a securityd.

    
respondido por el Leland Wallace 15.02.2016 - 05:43
fuente

Lea otras preguntas en las etiquetas