Quanto è sicuro il controllo di accesso Keychain di OS X?

Question

Quanto è sicuro il controllo di accesso Keychain di OS X?

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

8

Su OS X, quando un'applicazione richiede l'accesso a una voce di portachiavi, l'utente viene chiesto se concedere o negare quell'accesso.

Presumibilmente, il sistema salva non solo il percorso binario, ma anche il suo hash nella voce ACL che viene creata dopo che l'utente ha confermato la richiesta; secondo Apple , questo protegge contro binari modificati guadagnando l'accesso ai password e / o certificati utente.

È davvero sufficiente per impedire a un utente malintenzionato con autorizzazioni dell'utente (ma non di superutente) di recuperare tutte le password memorizzate?

Su Linux, ad esempio, c'è la variabile di ambiente LD_PRELOAD che può essere utilizzata per caricare librerie dinamiche aggiuntive che sovrascrivono alcune funzioni di libreria standard con codice personalizzato; usando ciò, sembrerebbe possibile cambiare il codice che viene eseguito all'interno di un dato binario senza modificare l'eseguibile di base stesso.

C'è un meccanismo simile su OS X che permetta un simile attacco (forse uno dei metodi citati qui )?

keychain macosx

posta lxgr 30.10.2013 - 14:24

fonte

3 risposte

Leggi altre domande sui tag keychain macosx

Due prende la crittografia PHP bidirezionale - quale è preferibile? Come condividere in modo sicuro la chiave tra due dispositivi remoti?

score 1 · Answer 1

Il limite di sicurezza è root, cioè securityd eseguito come root. Se securityd e ACL sono implementati correttamente, non c'è modo per un'altra applicazione di accedere alla chiave dal portachiavi. Tuttavia, Mac OS X ha avuto diverse vulnerabilità di escalation dei privilegi che consentirebbero a un utente malintenzionato locale di accedere a securityd e quindi all'elemento dal portachiavi. È ragionevole supporre che un utente malintenzionato moderatamente / altamente qualificato possa ancora trovare l'escalation dei privilegi esistente 0 giorni.

score 0 · Answer 2

per quanto ne sappiamo, gli sviluppatori di OSX provano davvero a proteggere e crittografare i dati nel portachiavi, e come altre applicazioni (firefox, anche quelle di Windows), puoi accedervi con una password, l'unico vero attacco che lavoro al momento, è keylogging quando si accede a cose come un portachiavi, o da bruteforcing / dizionario attacca il campo "password", dal momento che quelle aplpications non hanno una funzione "lockout" dopo cioè 5 tentativi in 1 minuto

score 0 · Answer 3

A quanto ho capito, securityd è il processo che interpreta & applica gli ACL del portachiavi. Il codice / le librerie nella tua applicazione comunicano con securitd tramite messaggi xpc. Securityd è quello che apre il file portachiavi, quindi l'inserimento del codice o il bypass della libreria dyld nell'applicazione chiamante non sarà in grado di modificare la quantità di accesso che si può avere. Come dice fel1x, ciò lascia irrompere / sovvertire la sicurezza. So che launchd ha un codice speciale per gestire securityd, in quanto non rilancerà securityd se si blocca, è necessario riavviare per ripristinare il sistema. Potrebbero esserci anche altre protezioni. Una semplice escalation di root potrebbe non essere sufficiente per sovvertire securityd.