Quanto è sicuro "Secure Keyboard Entry" nel terminale di Mac OS X?

37

Utilizzo Terminal da Mac OS X da anni, ma in qualche modo ho mancato di individuare questa funzione:

Ora mi sto chiedendo come funziona davvero, ed è sicuro al 100%? Se non lo è, quale tecnica potrebbe essere utilizzata per ottenere ancora i tasti?

    
posta Ivan Kovacevic 28.12.2013 - 17:39
fonte

1 risposta

54

"Secure Keyboard Entry" si associa alla funzione EnableSecureEventInput il cui concetto è descritto qui . Fondamentalmente, le applicazioni non accedono all'hardware stesso; ottengono eventi (ad esempio sui tratti chiave) dal sistema operativo. Alcuni elementi nel sistema operativo decidono quale applicazione ottiene quali eventi, in base ai relativi diritti di accesso e allo stato della GUI (ci sono dettagli a seconda di quale applicazione è "in primo piano").

Le applicazioni possono "spiare" l'una sull'altra, il che significa (in questo caso) che un'applicazione in esecuzione sulla macchina può chiedere al sistema operativo di inviarla una copia di tutti i tratti chiave anche se sono pensati per un'altra applicazione, e / o iniettare eventi sintetici propri. Questa è una funzione : consente cose come "portafogli password" (che immettono una password come se fosse stata digitata dall'utente, dal punto di vista dell'applicazione) o "Visualizzatore tastiera" ( la tastiera basata su GUI che consente di "digitare" i caratteri con il mouse e mostra anche quali tasti vengono effettivamente premuti in qualsiasi momento). EnableSecureEventInput blocca questa funzione per l'applicazione che la chiama. Provalo ! Esegui Terminal.app, attiva il "Keyboard Viewer" e verifica che l'abilitazione di "Secure Keyboard Entry" impedisca al Keyboard Viewer di svolgere il suo lavoro.

Tutti questi routing degli eventi vengono eseguiti in un processo dello spazio utente eseguito come root . Questo si basa sulla separazione del processo imposta dal kernel: il normale processo utente non può giocare a piacimento con la memoria allocata per un processo di root. Il kernel stesso non è a conoscenza del concetto di "evento" a livello utente. La gestione degli eventi, in particolare l'imposizione (o meno) di EnableSecureEventInput , è fatta dal codice non del kernel.

Un estratto interessante della pagina collegata sopra è il seguente:

The original implementation of EnableSecureEventInput was such that when a process enabled secure input entry and had keyboard focus, keyboard events were not passed to intercept processes. However, if the secure entry process was moved to the background, the system would continue to pass keyboard events to these intercept processes, since the keyboard focus was no longer to a secure entry process.

Recently, a security hole was found that made it possible for an intercept process to capture keyboard events, even in cases where secure event input was enabled and the secure event input process was in the background. The fix for this problem is to stop passing keyboard events to any intercept process whenever any process has enabled secure event input, whether that process is in the foreground or background. This means that a process which enables secure event input and leaves secure event input enabled for the duration of the program, can affect all keyboard intercept processes, even when the secure event process has been moved to the background.

Ciò significa che il sistema di routing degli eventi ha effettivamente sbagliato nella prima parte della funzione. Ora dovrebbe essere risolto.

Anche supponendo che il routing degli eventi sia ora corretto e sicuro, il che significa che la semantica di EnableSecureEventInput è realmente applicata, quindi devi capire che questo è completamente relativo al sistema di separazione dei processi. Qualsiasi processo di root può ispezionare e modificare a piacimento la memoria di tutti gli altri processi, e in particolare vedere tutti gli eventi; e un processo di root può anche collegarsi al kernel e ispezionare i dati effettivi dalla tastiera ignorando completamente la nozione di evento. Un key logger che può essere installato come root farà esattamente questo, e "Secure Keyboard Entry" non avrà difese. Vedi questo per una prova di concetto opensource.

Quindi "Secure Keyboard Entry" è sicuro solo contro i malintenzionati che potrebbero ottenere l'esecuzione di un codice proprio sulla macchina, ma non possono scalare i loro privilegi locali a livello di root. Questo è uno scenario piuttosto restrittivo, in quanto l'escalation dei privilegi locali tende ad essere possibile su base generale:

  • Il processo locale può vedere gran parte della macchina, quindi il "perimetro di sicurezza" da difendere è enorme in quel caso. Prevenire le intrusioni da parte di attaccanti remoti è molto più semplice, e tuttavia già abbastanza difficile.

  • Apple tende a mostrare alcuni mancanza di reattività nel caso dei buchi di escalation dei privilegi locali.

Riepilogo: Trovo eccessivamente ottimistico credere che "Secure Keyboard Entry" fornisca una sicurezza sufficiente contro i keylogger su, ad esempio, computer pubblici condivisi. Non è una brutta caratteristica, ma soddisfa le sue promesse solo se root e il kernel sono privi di alterazioni dannose, e questo è un "if" molto grande.

    
risposta data 29.12.2013 - 15:42
fonte

Leggi altre domande sui tag