Me di cuenta hoy que Adobe Desktop Services está supervisando constantemente / etc / passwd.
¿Sería el punto? Las contraseñas no se almacenan en / etc / passwd, entonces ¿por qué una aplicación monitorearía / etc / passwd? ¿Qué información podrían estar tratando de monitorear?
La biblioteca del sistema de Apple quería saber su nombre de usuario para que pueda encontrar su directorio personal. Luego decidió que la mejor manera de averiguar su nombre de usuario era buscarlo en /etc/passwd . Adobe Desktop Service solo quería saber la ruta a su directorio de inicio y (correctamente) usó el marco CoreFoundation para eso. Es por eso que la llamada aparece en el proceso de Adobe.
En tu captura de pantalla, la entrada Caller dice algo así como _fsi_get_user . Este es el símbolo de una subrutina privada en una de las bibliotecas del sistema macOS, libsystem_info.dylib , ubicada en /usr/lib/system .
El código fuente público del% La función _fsi_get_user revela la siguiente lógica:
if (geteuid() == 0)
{
// […]
}
else
{
f = fopen(_PATH_PASSWD, "r");
_fsi_get_validation(si, VALIDATION_PASSWD, _PATH_PASSWD, f, &va, &vb);
fmt = 1;
}
Al observar el código descompilado en libsystem_info.dylib (por ejemplo, al usar Hopper Disassembler), se confirma que _PATH_PASSWD es de hecho el nombre de archivo /etc/passwd . (El código fuente más abajo en file_module.c también explica por qué hay una llamada a fstat inmediatamente después de fopen : la implementación de _fsi_get_validation hace eso para averiguar la hora de la última modificación de su /etc/passwd .)
En otras palabras: Adobe no estaba mirando tu archivo de contraseña; La biblioteca del sistema de Apple era.
Hay muchas pilas de llamadas posibles que pueden conectar el código del Servicio de Adobe Desktop a la función _fsi_get_user . Un poco de análisis estático sugiere que el candidato más plausible sería NSHomeDirectory , una clase de utilidad en Foundation.framework .
Mirar el binario de Adobe Desktop Service revela que, de hecho, llama a [NSHomeDirectory UTF8String] :
*100032ac4 call imp___stubs__NSHomeDirectory
*100032ac9 mov rsi, qword [0x10008a178] ; "UTF8String"
*100032ad0 mov rdi, rax
*100032ad3 call qword [_objc_msgSend_100088350]
La implementación de NSHomeDirectory de Apple nos llevará a /etc/passwd con bastante rapidez. Mi suposición basada en la cadena más probable de llamadas a funciones sería:
Adobe Desktop Service → [NSHomeDirectory UTF8String] (en Foundation.framework ) → NSHomeDirectoryForUser → CFCopyHomeDirectoryURLForUser (en CoreFoundation.framework ) → _CFCopyHomeDirURLForUser → getpwuid (en libsystem_info.dylib , reexportado a través de libSystem.B.dylib ) → si_user_byuid (aquí es donde Apple decide en el tiempo de ejecución qué fuente va a usar. Por ejemplo, si su ID de usuario está entre 1 y 499, se consultará a su /etc/passwd en lugar de a Servicios de directorio. ) → file_user_byuid → _fsi_get_user .
Para estar más seguros, analicé aún más el servicio binario de Adobe Desktop Service y, como se esperaba, no contiene una referencia única a /etc/passwd . (Sin embargo, no he comprobado si Adobe Desktop Service hace otras cosas dudosas).
El análisis completo hubiera sido un poco más fácil si hubieras hecho clic en una de las entradas antes de crear la captura de pantalla. Tu aplicación habría mostrado el seguimiento de pila relevante en la esquina inferior derecha (son las líneas donde dice Seguimiento de pila ). Pero bueno, me divertí mucho al descubrirlo, ¡y he aprendido mucho de esa manera!
Para confirmar que mi análisis es correcto, es posible que desee hacer clic en una de las entradas /etc/passwd en su aplicación de Instrumentos y encontrar los términos NSHomeDirectory y file_user_byuid en algún lugar del seguimiento de la pila.
A partir de la información en su captura de pantalla, el programa no está tratando de "monitorear" el contenido del archivo. En su lugar, solicita repetidamente los metadatos sobre el archivo (es decir, si el archivo existe, qué tan grande es, cuándo se creó, etc.).
Solo Adobe puede decirte por qué han codificado su programa de la forma en que lo hicieron.
Sin embargo, tenga en cuenta que hay múltiples explicaciones lógicas de por qué hicieron lo que hicieron, eso no implica ninguna actividad de "espionaje" o "nefasta".
Por ejemplo, este programa de daemon en particular (es decir, el servicio en segundo plano) puede verificar constantemente la existencia de / etc / password para determinar que (a) no está en un espacio aislado, y (b) no se le quitan sus permisos para que Está prohibido examinar ese archivo.
Lea otras preguntas en las etiquetas applications adobe