Ho notato oggi che Adobe Desktop Services monitora costantemente / etc / passwd.

Sarebbe il punto? Le password non sono memorizzate in / etc / passwd, quindi perché un'app controlla / etc / passwd? Quali informazioni potrebbero tentare di monitorare?

Adobe Desktop Service non guardava il tuo / etc / passwd. La libreria di sistema di Apple era.

La libreria di sistema di Apple voleva conoscere il tuo nome utente in modo che potesse trovare la tua home directory. Ha quindi deciso che il modo migliore per capire il tuo nome utente era quello di cercarlo /etc/passwd. Adobe Desktop Service voleva solo conoscere il percorso della home directory e (correttamente) utilizzato? il framework CoreFoundation per questo. Ecco perché la chiamata appare durante il processo di Adobe.

Dettagli

Nel tuo screenshot, la voce Chiamante dice qualcosa di simile _fsi_get_user. Questo è il simbolo di una subroutine privata in una delle librerie di sistema di macOS libsystem_info.dylib, situata in /usr/lib/system.

Il codice sorgente pubblico della _fsi_get_userfunzione rivela la seguente logica:

if (geteuid() == 0)
{
  // […]
}
else
{
  f = fopen(_PATH_PASSWD, "r");
  _fsi_get_validation(si, VALIDATION_PASSWD, _PATH_PASSWD, f, &va, &vb);
  fmt = 1;
}

Guardando il codice decompilato in libsystem_info.dylib(ad esempio, utilizzando Hopper Disassembler) si conferma che _PATH_PASSWDè effettivamente il nome del file /etc/passwd. (Il codice sorgente più in basso file_module.cspiega anche perché c'è una chiamata a fstatsubito dopo fopen: l'implementazione di _fsi_get_validation? Fa questo per capire l'ultimo tempo di modifica del tuo /etc/passwd.)

In altre parole: Adobe non stava guardando il tuo file passwd; La libreria di sistema di Apple era.

Collegare i punti

Esistono molte pile di chiamate che possono collegare il codice di Adobe Desktop Service alla _fsi_get_userfunzione. Un po 'di analisi statica suggerisce il più plausibile? candidato sarebbe NSHomeDirectory, una classe di utilità in Foundation.framework.

Guardando il binario di Adobe Desktop Service si rivela che in effetti chiama [NSHomeDirectory UTF8String]:

*100032ac4   call   imp___stubs__NSHomeDirectory
*100032ac9   mov    rsi, qword [0x10008a178]  ; "UTF8String"
*100032ad0   mov    rdi, rax
*100032ad3   call   qword [_objc_msgSend_100088350]

L'implementazione di Apple NSHomeDirectoryci porterà quindi /etc/passwdabbastanza rapidamente. La mia ipotesi plausibile sulla catena più probabile di chiamate di funzioni sarebbe:

Adobe Desktop Service → [NSHomeDirectory UTF8String](in Foundation.framework) → NSHomeDirectoryForUser→ CFCopyHomeDirectoryURLForUser(in CoreFoundation.framework) → _CFCopyHomeDirURLForUser→ getpwuid(in libsystem_info.dylib, riesportato via libSystem.B.dylib) → si_user_byuid(è qui che Apple decide in fase di runtime quale sorgente verrà utilizzata. Ad esempio, se l'ID utente è compreso tra 1 e 499 , /etc/passwdverrai consultato al posto dei servizi di directory. ) → file_user_byuid→ _fsi_get_user.

A dire il vero, ho analizzato ulteriormente il servizio binario Adobe Desktop e, come previsto, non contiene alcun riferimento a /etc/passwd. (Non ho verificato se Adobe Desktop Service fa altre cose losche, comunque.)

L'intera analisi sarebbe stata un po 'più semplice se si fosse effettivamente fatto clic su una delle voci prima di creare lo screenshot. La tua app avrebbe quindi mostrato la relativa traccia dello stack nell'angolo in basso a destra (sono le linee in cui si dice Stack Trace ). Ma hey, mi sono divertito molto a capirlo, e ho imparato molto in quel modo!

Verifica

Per confermare che la mia analisi è corretta, potresti voler fare clic su una delle /etc/passwdvoci nell'app Strumenti e trovare i termini NSHomeDirectorye file_user_byuidda qualche parte nella traccia dello stack.

Dalle informazioni nella schermata, il programma non sta cercando di "monitorare" il contenuto del file. Richiede invece ripetutamente i metadati relativi al file (ovvero esiste il file, quanto è grande, quando è stato creato, ecc.).

Solo Adobe può dirti perché hanno codificato il loro programma come hanno fatto.

Tuttavia, tieni presente che ci sono più spiegazioni logiche del perché hanno fatto quello che hanno fatto - ciò non implica alcuna attività di "spionaggio" o "nefasta".

Ad esempio questo particolare programma demone (ad es. Servizio in background) potrebbe costantemente verificare l'esistenza di / etc / password al fine di determinare che (a) non è in modalità sandbox, e (b) non è privato delle sue autorizzazioni in modo che sia proibito esamina quel file.