¿Qué tan segura es la “Entrada segura del teclado” en la Terminal de Mac OS X?

La "entrada segura del teclado" se asigna a la función EnableSecureEventInput cuyo concepto se describe aquí . Básicamente, las aplicaciones no acceden al hardware en sí mismas; obtienen eventos (por ejemplo, sobre pulsaciones de teclas) del sistema operativo. Algunos elementos del sistema operativo deciden qué aplicación obtiene qué eventos, en función de sus derechos de acceso y el estado de la GUI (hay detalles según la aplicación que se encuentre "en primer plano").

Las aplicaciones pueden "espiarse" entre sí, lo que significa (en este caso) que una aplicación que se ejecuta en la máquina puede solicitar al sistema operativo que le envíe una copia de todos los golpes de tecla, incluso si están diseñados para otra aplicación, y / O inyectar eventos sintéticos propios. Esta es una característica : permite cosas como "billeteras de contraseñas" (que ingresan una contraseña como si la hubiera escrito el usuario, desde el punto de vista de la aplicación) o el "Visor de teclado" ( el teclado basado en GUI que le permite "escribir" caracteres con el mouse y también muestra qué teclas se están presionando en cualquier momento). EnableSecureEventInput bloquea esta función para la aplicación que la llama. Intentalo ! Ejecute Terminal.app, habilite el "Visor de teclado" y vea que habilitar la "Entrada segura del teclado" evita que el Visor de teclado haga su trabajo.

Todo este enrutamiento de eventos se realiza en un proceso de espacio de usuario que se ejecuta como root . Este se basa en la separación de procesos impuesta por el kernel: el proceso de usuario normal no puede jugar a voluntad con la memoria asignada para un proceso raíz. El núcleo mismo desconoce el concepto de "evento" a nivel de usuario. La gestión de eventos, en particular la aplicación (o no) de EnableSecureEventInput , se realiza mediante un código que no es del kernel.

Un extracto interesante de la página enlazada arriba es el siguiente:

  

La implementación original de EnableSecureEventInput fue tal que cuando un proceso habilitó la entrada de entrada segura y tuvo un enfoque de teclado, los eventos de teclado no se pasaron para interceptar procesos. Sin embargo, si el proceso de entrada segura se trasladó a un segundo plano, el sistema continuaría pasando los eventos del teclado a estos procesos de intercepción, ya que el enfoque del teclado ya no era un proceso de entrada seguro.

     

Recientemente, se encontró un agujero de seguridad que hizo posible que un proceso de intercepción capturara eventos del teclado, incluso en los casos en que se habilitó la entrada segura de eventos y el proceso de entrada segura de eventos se realizó en segundo plano. La solución para este problema es dejar de pasar eventos de teclado a cualquier proceso de intercepción siempre que un proceso haya habilitado la entrada segura de eventos, ya sea que ese proceso se encuentre en primer plano o en segundo plano. Esto significa que un proceso que habilita la entrada segura de eventos y deja la entrada segura de eventos habilitada durante la duración del programa, puede afectar a todos los procesos de intercepción del teclado, incluso cuando el proceso de evento seguro se ha trasladado al fondo.

Esto significa que el sistema de enrutamiento de eventos realmente se equivocó en la primera entrega de la función. Ahora se supone que esto debe ser arreglado.

Incluso suponiendo que el enrutamiento del evento ahora es correcto y seguro, lo que significa que la semántica de EnableSecureEventInput realmente se aplica, entonces debe comprender que esto es completamente relativo al sistema de separación de procesos. Cualquier proceso raíz puede inspeccionar y modificar a voluntad la memoria de todos los demás procesos y, en particular, ver todos los eventos; y un proceso raíz también puede conectarse al kernel e inspeccionar los datos reales del teclado sin pasar por alto la noción de evento. Un registrador de teclas que se puede instalar como root hará exactamente eso, y la "Entrada segura del teclado" estará indefensa contra él. Consulte esto para obtener una prueba de concepto de código abierto.

Por lo tanto, la "Entrada segura al teclado" es segura solo contra los atacantes que podrían ejecutar un código propio en la máquina, pero no pudieron escalar sus privilegios locales hasta el nivel raíz. Este es un escenario bastante restrictivo, porque la escalada de privilegios locales tiende a ser posible en general:

• El proceso local puede ver gran parte de la máquina, por lo que el "perímetro de seguridad" a defender es enorme en ese caso. Evitar la intrusión de los atacantes remotos es mucho más fácil y, sin embargo, ya es bastante difícil.

• Apple tiende a mostrar algunos falta de reactividad en el caso de agujeros locales de escalamiento de privilegios.

Resumen: Me parecería demasiado optimista creer que la "Entrada segura del teclado" brinda suficiente seguridad contra los registradores clave en, digamos, las computadoras públicas compartidas. No es una característica mala, pero cumple sus promesas solo si la raíz y el kernel están libres de alteraciones maliciosas, y ese es un gran "si".