tl; dr No parece haber nada inusual, o inherentemente inseguro, con su ejecutable ARDAgent o sus permisos. De hecho, su solución propuesta hará que su sistema sea un poco más seguro, pero podría hacer más daño que beneficio. Probablemente no vale la pena.
Con chmod a-x, la ganancia en seguridad sería realmente pequeña; una actualización de software puede simplemente restablecer la bandera, lo que le da una falsa sensación de seguridad; definitivamente romperás ARD; También puede olvidar volver a habilitar SIP, o incluso interrumpir futuras actualizaciones del sistema.
Lo que ha sucedido
Primero resumamos lo que ha sucedido con respecto a ARDAgent en el pasado.
En 2008, las bibliotecas OSA (una parte de Mac OS X) tenían un problema de escalamiento de privilegios de raíz ( CVE-2008-2830 ), que permitiría a los atacantes ejecutar AppleScript de forma arbitraria utilizando una aplicación privilegiada.
Una forma popular de demostrar CVE-2008-2830 fue utilizar la aplicación ARDAgent como diputado confundido para ejecutar código AppleScript arbitrario con privilegios elevados.
Esa vulnerabilidad fue posible porque ARDAgent usó las bibliotecas OSA (que contenían el error en ese momento) y Porque está diseñado para ejecutarse con derechos de superusuario.
El mensaje de advertencia SUID de la Utilidad de Discos es muy probablemente causado por un descuido menor introducido con OS X 10.5. La advertencia de SUID solía molestar Usuarios de mac ya en 2007 ; Los primeros informes aparecieron el día 10.5, y CVE-2008-2830 ni siquiera había aparecido. Así que no creo que la advertencia tenga nada que ver con el error, la vulnerabilidad o el parche posterior de Apple.
En la actualidad, CVE-2008-2830 se ha solucionado durante casi una década. No he visto informes desde ninguna otra vulnerabilidad relacionada con ARDAgent.
Tu modelo de amenaza
Dejando a un lado toda la historia, avancemos para aclarar el escenario de amenaza que probablemente tengas en mente; Siéntase libre de editar su pregunta en caso de que esté equivocado.
Por el bien del modelado de amenazas, supongamos que ARDAgent 3.9.2 (la versión que se envía con El Capitán) tiene otro vulnerabilidad no relacionada, una que no se conoce públicamente a fecha de hoy pero que puede 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 aprovechar el error en la red para obtener la ejecución del código (debido al error) y los privilegios de superusuario (debido al bit setuid) de una sola vez. Esta es una amenaza un tanto realista.
Si el atacante ya tiene ejecución de código local con privilegios normales, la escalada probablemente se puede lograr de la misma manera.
No estamos interesados en un atacante que ya tenga privilegios de superusuario en primer lugar; tal atacante ya tendría control completo sobre todo el sistema y no ganaría nada al atacar a ARDAgent.
Mitigación de riesgos
Si tu corres chmod a-x contra el ejecutable según su sugerencia (que solo es posible con sorbo desactivado), el atacante pierde: launchd ya no ejecutará al agente, y el atacante local tampoco lo hará. Ha reducido con éxito la superficie de ataque, aunque solo sea por una pequeña fracción.
Impacto de la corrección
En macOS, hay muchos procesos con privilegios de superusuario, ya sea con o sin setuid. El hecho de que hubo un error en ARDAgent hace una década no hace que sea intrínsecamente menos seguro que los otros programas. En promedio, otros procesos son igualmente probables. Como ARDAgent tiene una vulnerabilidad crítica no descubierta.
Vas a perder las funciones de escritorio remoto de Apple (si los tienes habilitados). También podría encontrarse con un azar futura actualización de macOS fallada porque las marcas podrían haberse convertido en parte de una afirmación de firma previa a la actualización (no muy diferente de la advertencia de SUID de hace una década, pero esta vez Apple podría elegir convertirla en un error). Es probable que haya olvidado su solución para entonces, por lo que tendrá que volver a instalar.
Incluso si las actualizaciones del sistema funcionan, pueden simplemente restablecer el bit de ejecución al enviar la próxima versión de ARDAgent Dejándote con una falsa sensación de seguridad.
También existe el riesgo de olvidando volver a habilitar SIP (lo que introducirá mucho más riesgo de lo que acaba de mitigar). Y, por último, existe un pequeño riesgo de cometer un pequeño error discreto mientras chmod ding, por ejemplo rwsrw-rw- - lo que significa que cada usuario gana nada menos que los privilegios de raíz 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. Si bien es posible que esto no siempre proteja contra ataques de escalamiento (un atacante con ejecución de código local podría simplemente iniciar el agente directamente), ayudará a prevenir el RCE.
Re-habilitar SIP si está desactivado, y dejarlo habilitado.
Buscar y eliminar, archivos que no son del sistema que son propiedad de la raíz y que tienen establecidos setuid / setgid bits sin buena razon Si absolutamente necesita dejar los bits habilitados, asegúrese de que los archivos nunca sean de grupo o de escritura mundial.
