1 votos

¿Son realmente seguros los permisos de la ARDAgent?

Estoy corriendo en El Capitán 10.11.6 parcheado con las últimas actualizaciones de seguridad en el momento de escribir este artículo.

Hace poco hice una reparación de permiso en el volumen de root:

sudo /usr/libexec/repair_packages --verify --standard-pkgs /

Me he dado cuenta de la siguiente entrada en el registro:

Advertencia: El archivo SUID 'System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent' ha sido modificado y no será reparado.

Intrigado, investigué en el binario, y aterricé en este página (entre otras).

Esto me hizo un poco paranoico, así que busqué de nuevo, y encontré este página, donde la respuesta aceptada me asegura que Utilidad del disco probablemente no "sabe" que el archivo ha sido parcheado por razones de seguridad.

Como soy un poco testarudo, comprobé la propiedad/permisos reales de ese binario en mi sistema:

-rwsr-xr-x 1 root wheel 1.1M Mar 6 19:15 ARDAgent

Parece un grupo ( rueda ) y todos los demás puede ejecutar el binario.

Mi pregunta: ¿es realmente seguro, para una aplicación vulnerable a la ejecución arbitraria/maliciosa y escalada de código?

¿No debería al menos chmod a a-x ?

1voto

user91500 Puntos 6355

No parece haber nada inusual, o inherentemente inseguro, con su ejecutable ARDAgent o sus permisos. Su propuesta de arreglo hará que su sistema sea un poco más seguro, pero podría hacer más daño que bien. Probablemente no vale la pena.

Con chmod a-x la ganancia en seguridad sería muy pequeña; una actualización de software podría simplemente reiniciar la bandera, dejándote con una falsa sensación de seguridad; definitivamente romperás el ARD; también podrías olvidarte de volver a activar el SIP, o incluso romper futuras actualizaciones del sistema.

Lo que ha sucedido

Resumamos primero lo que ha sucedido con respecto a ARDAgent en el pasado.

  • En 2008, las bibliotecas de la OSA (una parte de Mac OS X) tuvieron un problema de escalada de privilegios Root ( CVE-2008-2830 ), lo que permitiría a los atacantes ejecutar un AppleScript arbitrario usando una aplicación privilegiada.

  • Una forma popular de demostrar CVE-2008-2830 fue usar la aplicación ARDAgent como diputado confuso para ejecutar código arbitrario de AppleScript con privilegios elevados.

  • Esa explotación fue posible porque ARDAgent utilizó las bibliotecas de la OSA (que contenían el error en ese momento) y porque está diseñado para funcionar con derechos de superusuario.

  • El mensaje de advertencia SUID de la Utilidad de Discos es muy probablemente causado por un pequeño descuido introducido con OS X 10.5. La advertencia del SUID solía molestar Los usuarios de Mac ya en 2007 Los primeros informes aparecieron el día 10.5, y el CVE-2008-2830 ni siquiera había salido a la superficie. Así que no creo que la advertencia tenga nada que ver con el error, la hazaña, o con el posterior parche de Apple.

  • En la actualidad, CVE-2008-2830 se ha fijado durante casi una década. No he visto informes desde entonces sobre ninguna otra vulnerabilidad que involucre a ARDAgent.

Su modelo de amenaza

Dejando a un lado toda esa historia, pasemos a aclarar el escenario de amenaza que probablemente tenga en mente; siéntase libre de editar su pregunta en caso de que me equivoque.

  • Para modelar las amenazas, asumamos que ARDAgent 3.9.2 (la versión que navega con El Capitán) tiene otro vulnerabilidad no relacionada, una que no se conoce públicamente en la actualidad pero que podría ser descubierta y explotada por un atacante.

  • En el peor de los casos, esa vulnerabilidad sería un problema de ejecución remota de código (RCE); un atacante podría entonces ser capaz de explotar el fallo en la red para obtener ejecución de código (debido al fallo) y privilegios de superusuario (debido al bit setuid) de una sola vez. Esta es una amenaza un tanto realista.

  • Si el atacante ya tiene la ejecución del código local con privilegios normales, la escalada se puede lograr probablemente por los mismos medios.

  • No estamos interesados en un atacante que ya tiene privilegios de superusuario en primer lugar; tal atacante ya tendría un control completo sobre todo el sistema, y no ganaría nada atacando a ARDAgent.

Mitigación de riesgos

Si corres chmod a-x contra el ejecutable según su sugerencia (que sólo es posible con SIP desactivado), el atacante pierde: launchd ya no dirigirá al agente, y el atacante local tampoco lo hará. Ha reducido con éxito la superficie de ataque, aunque sólo en una pequeña fracción.

Impacto del arreglo

En MacOS, hay muchos procesos con privilegios de superusuario, ya sea con o sin setuid. El hecho de que hubiera un error en ARDAgent hace una década no lo hace inherentemente menos seguro que los otros programas. En promedio, otros procesos son igual de probables como ARDAgente para tener una vulnerabilidad crítica no descubierta.

Lo harás. perder las funciones de escritorio remoto de Apple (si los tienes activados). También podrías encontrarte con un la futura actualización de MacOS falla porque las banderas podrían haberse convertido en parte de una afirmación de firma previa a la actualización (no muy diferente de la advertencia del SUID de hace una década, pero esta vez Apple podría elegir hacerlo un error). Lo más probable es que para entonces ya hayas olvidado tu arreglo, así que tendrás que reinstalarlo.

Aunque las actualizaciones del sistema funcionen, podrían simplemente reiniciar el bit de ejecución cuando se envíe la siguiente versión de ARDAgent, dejándote con una falsa sensación de seguridad.

También existe el riesgo de olvidándose de volver a activar el SIP (que introducirá mucho más riesgo del que acaba de mitigar). Y por último, hay un pequeño riesgo de cometer un pequeño error discreto mientras chmod ding, por ejemplo rwsrw-rw- - lo que significa que cada usuario obtiene nada menos que privilegios de root de forma gratuita.

Alternativas

Algunas sugerencias para mitigar el riesgo de una manera más segura:

  • Reduzca la superficie de ataque deshabilitando los servicios que no necesita. Aunque esto no siempre protege contra los ataques de escalada (un atacante con ejecución de código local podría lanzar el agente directamente), ayudará a prevenir la RCE.

  • Re-activar SIP si está desactivado, y déjalo activado.

  • Buscar y eliminar, archivos no de sistema propiedad de Root que tienen bits setuid/setgid establecidos sin una buena razón. Si necesitas dejar los bits activados, asegúrate de que los archivos nunca se puedan agrupar o escribir en el mundo.

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X