Múltiples nuevas vulnerabilidades de escape del sandbox en macOS

 (jhftss.github.io)
1 puntos por GN⁺ 2024-11-09 | 1 comentarios | Compartir por WhatsApp
  • En la investigación de escapes del sandbox de macOS, los servicios XPC de dominio PID, que se habían visto relativamente poco, surgieron como superficie de ataque y llevaron al descubrimiento de más de 10 nuevas vulnerabilidades
  • El objetivo principal no son los servicios Mach de los dominios System/User, sino los servicios XPC de tipo Application que se registran en el dominio PID al cargar una app o un framework
  • Los casos vulnerables incluyen CVE-2023-27944, CVE-2023-32414, CVE-2023-32404, CVE-2023-41077, CVE-2023-42961, CVE-2024-27864, CVE-2023-42977, entre otros; algunos se vinculan incluso con bypass de TCC, permisos relacionados con SIP e impacto en iOS
  • El punto de falla repetido fue que servicios no aislados, al procesar archivos, directorios, archivos comprimidos y DMG, no manejaban de forma segura el atributo extendido quarantine, las cadenas de rutas ni la verificación de permisos del cliente
  • La respuesta de Apple incluyó eliminar servicios XPC vulnerables, normalizar entradas, trasladar la validación al lado del servidor y exigir private entitlement, aunque todavía quedan 5 reportes pendientes de parche

Modelo de sandbox de macOS y objetivo del escape

  • En macOS, muchos procesos, incluidos servicios propios de Apple y apps de terceros, se ejecutan en un entorno de sandbox restringido
  • Aunque un atacante obtenga ejecución remota de código (RCE) en un proceso con sandbox, las capacidades de ejecución y los permisos de acceso a archivos están limitados, por lo que el siguiente paso es un escape del sandbox para obtener permisos más amplios

  • App Sandbox

    • Por los requisitos de Mac App Store, muchas apps se ejecutan con restricciones de App Sandbox
    • Una app con sandbox debe tener el entitlement com.apple.security.app-sandbox
    • Las restricciones se aplican durante la fase de inicialización de dyld, antes de la función main de la app
    • Al entrar en App Sandbox, la app queda contenedorizada y las operaciones de archivos se limitan a la ruta del contenedor de datos
    • Los archivos creados por una app con sandbox reciben por defecto el atributo extendido com.apple.quarantine
    • El perfil de sandbox incluye reglas que impiden eliminar este atributo extendido
    • Los permisos detallados de App Sandbox se definen en /System/Library/Sandbox/Profiles/application.sb
    • Se restringen la red, el hardware, el sistema de archivos y los servicios Mach accesibles
    • Los procesos hijos creados con fork heredan las restricciones de App Sandbox del padre
    • Los procesos ejecutados mediante LaunchService.framework no heredan las restricciones; por ejemplo, se puede ejecutar directamente una app del sistema sin sandbox con el comando del sistema open

  • Service Sandbox

    • Muchos servicios daemon de Apple se ejecutan en el contexto de Service Sandbox
    • Los perfiles de sandbox de servicios se encuentran principalmente en /System/Library/Sandbox/Profiles/*.sb y /usr/share/sandbox/*.sb
    • Las restricciones de Service Sandbox se aplican manualmente llamando a la API sandbox_init_XXX desde la función main del servicio
    • Los servicios que entran en Service Sandbox generalmente no quedan contenedorizados
    • Una diferencia importante es que los archivos creados en Service Sandbox no se marcan por defecto con quarantine
    • Si no se llama manualmente a las API relacionadas con quarantine, los archivos creados no reciben quarantine

Rutas existentes de escape del sandbox en macOS

  • Ataques a LaunchService.framework

    • Uno de los métodos comunes existentes consiste en atacar apps sin sandbox mediante LaunchService.framework
    • CVE-2021-30864 fue un caso de manipulación de la variable de entorno $HOME contra Terminal.app, una app del sistema sin sandbox
    • Al ejecutar Terminal, una carga maliciosa bajo $HOME/.profile controlable se ejecuta sin restricciones de sandbox
    • Otro escenario consiste en soltar una nueva app sin sandbox y luego ejecutarla
    • Sin embargo, una app recién soltada por una app con sandbox queda en quarantine y se bloquea su ejecución
    • Si se pueden soltar archivos o carpetas sin quarantine, se puede eludir por completo App Sandbox
    • CVE-2023-32364 fue un caso en el que se aprovechó que devfs no soporta atributos extendidos para soltar una carpeta sin quarantine

  • Ataques a servicios Mach accesibles

    • El segundo método común consiste en atacar servicios Mach listados en el perfil de App Sandbox
    • La información de los servicios Mach del sistema se almacena en /System/Library/xpc/launchd.plist
    • Con la API bootstrap_look_up se puede verificar desde una app con sandbox si es posible acceder a un servicio Mach específico
    • Estos servicios Mach existen en el dominio System o en el dominio User
    • El punto de partida de esta investigación es que hay más servicios XPC accesibles desde App Sandbox fuera de estos dos dominios

Nueva superficie de ataque: servicios XPC de dominio PID

  • Los servicios XPC pasados por alto existen en el dominio PID
  • A diferencia de los servicios XPC de los dominios System/User observados habitualmente, estos tienen tipo de servicio Application
  • Los servicios XPC de tipo Application se ejecutan cuando una app los solicita y terminan junto con la app solicitante cuando esta finaliza
  • Los servicios XPC de los dominios System/User solo son accesibles desde apps con sandbox si están definidos en application.sb
  • Todos los servicios XPC que requieren las apps y frameworks aparecen en el dominio PID de esa app
  • Muchos servicios XPC del dominio PID no esperan ser llamados desde apps con sandbox, por lo que pueden no tener comprobaciones de entitlement ni de sandbox sobre los clientes XPC entrantes

  • Caso de SystemShoveService.xpc

    • SystemShoveService.xpc es un bundle XPC dentro del framework privado del sistema ShoveService.framework
    • El tipo de servicio en Info.plist es Application y el identificador del bundle es com.apple.installandsetup.shoveservice.system
    • Si se carga /System/Library/PrivateFrameworks/ShoveService.framework desde una app con sandbox, el servicio XPC correspondiente se registra automáticamente en el dominio PID
    • SystemShoveService.xpc no verificaba al cliente XPC solicitante, por lo que podía explotarse para escapar de App Sandbox
    • Este servicio tenía el potente entitlement relacionado con SIP com.apple.rootless.install, por lo que también podía vincularse con un bypass de la protección SIP
    • La vulnerabilidad fue asignada como CVE-2022-26712, y los detalles están resumidos en un artículo anterior

  • Método de búsqueda

    • Todos los servicios XPC cuyo Service Type es Application son objetivos potenciales para escapes de App Sandbox
    • Se pueden encontrar enumerando los servicios XPC en frameworks del sistema y frameworks privados
      • /System/Library/Frameworks
      • /System/Library/PrivateFrameworks
    • Si existe un servicio XPC de dominio PID que no verifica a los clientes XPC entrantes, se puede intentar atacarlo de las siguientes formas
      • Soltar una carpeta de app sin quarantine para obtener un escape completo del sandbox
      • Soltar sin quarantine un archivo ZIP o DMG que contenga una app sin sandbox

2 vulnerabilidades solo beta

  • Beta-No-CVE-1: ejecución arbitraria de comandos en StorageKit

    • Apple registró esta vulnerabilidad en additional recognitions, pero no le asignó un CVE
    • Según Apple, los CVE solo se asignan a vulnerabilidades de software lanzado a producción, y no a vulnerabilidades de software solo beta
    • Solo afecta a las versiones beta de macOS Sonoma
    • La ruta del servicio XPC vulnerable es /System/Library/PrivateFrameworks/StorageKit.framework/XPCServices/storagekitfsrunner.xpc
    • Este servicio podía ejecutarse sin restricciones de sandbox y aceptaba a todos los clientes XPC en el método delegate
    • El único método de SKRemoteTaskRunnerProtocol, runTask:arguments:withReply:, estaba diseñado para ejecutar comandos arbitrarios con la ruta del ejecutable y los argumentos especificados
    • Como la ruta del ejecutable y los argumentos podían ser controlados por un cliente XPC en sandbox, era posible ejecutar comandos arbitrarios del sistema sin restricciones de sandbox
    • Apple eliminó por completo el servicio XPC vulnerable del sistema operativo antes del lanzamiento estable de macOS Sonoma 14.0

  • Beta-No-CVE-2: abuso de la creación de ZIP en AudioAnalyticsHelperService

    • Esta vulnerabilidad tampoco recibió un CVE por el mismo motivo de ser solo beta
    • La ruta del servicio XPC vulnerable es /System/Library/PrivateFrameworks/AudioAnalyticsInternal.framework/XPCServices/AudioAnalyticsHelperService.xpc
    • El servicio podía ejecutarse sin restricciones de sandbox y aceptaba a todos los clientes XPC
    • El método createZipAtPath:hourThreshold:withReply: comprimía una ruta arbitraria especificada por el cliente XPC
    • Si no existía una carpeta compressed en la ruta indicada, la creaba, buscaba archivos .json, los movía a esa carpeta y luego creaba un archivo ZIP
    • Un atacante podía reemplazar la carpeta compressed por un symlink para mover archivos arbitrarios a ubicaciones arbitrarias
    • El contenido del archivo de origen no se verifica, y la ruta del archivo de destino debe tener el sufijo .json
    • Como el servicio no estaba en sandbox, el archivo ZIP recién creado no quedaba en quarantine
    • Antes del lanzamiento de macOS Sonoma 14.0, Apple lo parchó para verificar el entitlement com.apple.audioanalytics.helper.service de los clientes XPC entrantes
    • En las versiones recientes de macOS, el framework privado AudioAnalyticsInternal.framework y su servicio XPC fueron eliminados por completo

CVE-2023-27944: TrialArchivingService

  • El servicio vulnerable es /System/Library/PrivateFrameworks/TrialServer.framework/XPCServices/TrialArchivingService.xpc
  • Este servicio entra en un Service Sandbox con el perfil /System/Library/Sandbox/Profiles/com.apple.trial.TrialArchivingService.sb
  • Al ser un Service Sandbox, los archivos soltados no quedan en quarantine
  • El servicio acepta a todos los clientes XPC entrantes
  • El método extractArchiveFromHandle:withArchiveName:toDirectory:destDirExtension:postExtractionCompression:completion: extrae en una ubicación especificada el archivo de archivo comprimido entregado por una app en sandbox
  • Como el atributo extendido de quarantine no se transmitía al contenido extraído, podía resultar en el drop de archivos sin quarantine

  • Condiciones de explotación y bypass

    • Al abusar de este método, los archivos Mach-O dentro del archivo comprimido pierden el permiso de ejecución después de extraerse, por lo que no se pueden ejecutar directamente
    • Una técnica con symlink, como la de CVE-2021-30990, puede servir como bypass
    • Sin embargo, este método XPC solo extrae directorios y archivos normales, y no permite extraer symlinks desde el archivo comprimido
    • Un método de bypass es extraer la app payload en la ruta del contenedor de la app en sandbox
    • Como la app en sandbox tiene permisos de lectura y escritura sobre esa ruta, puede crear directamente un symlink o conceder permisos de ejecución con chmod
    • Otro método es archivar dos veces la app payload
      • Descomprimir el ZIP externo con el método XPC vulnerable
      • Descomprimir el ZIP interno con el comando del sistema open

  • Parche

    • En macOS Ventura 13.3, Apple lo parchó para verificar el entitlement com.apple.TrialArchivingService.internal de los clientes XPC entrantes
    • Si no existe ese entitlement, rechaza la conexión XPC

CVE-2023-32414: ArchiveService

  • El servicio vulnerable es /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/XPCServices/ArchiveService.xpc
  • Este servicio entra en un Service Sandbox, pero los archivos soltados no quedan en quarantine
  • El servicio acepta a todos los clientes XPC
  • El método unarchiveItemWithURLWrapper:… descomprime en una ubicación especificada el elemento entregado por una app en sandbox
  • Como no transmitía el atributo extendido de quarantine al contenido extraído, una app en sandbox podía soltar archivos arbitrarios sin quarantine
  • El cliente XPC ya estaba implementado en la clase Objective-C DSArchiveService de DesktopServicesPriv.framework

  • Parche

    • En macOS Ventura 13.4, Apple lo parchó para verificar el entitlement com.apple.private.ArchiveService.XPC de los clientes XPC entrantes
    • Si no existe ese entitlement, rechaza la conexión XPC

CVE-2023-32404: ShortcutsFileAccessHelper

  • El servicio vulnerable es /System/Library/PrivateFrameworks/WorkflowKit.framework/XPCServices/ShortcutsFileAccessHelper.xpc
  • Este servicio podía ejecutarse sin restricciones de sandbox, por lo que podía usarse para escapar de App Sandbox
  • La firma de código también incluía un entitlement especial de TCC para Full Disk Access
  • Por lo tanto, esta vulnerabilidad también podía usarse para evadir por completo las protecciones de TCC
  • El servicio acepta a todos los clientes XPC
  • El único método de WFFileAccessHelperProtocol, extendAccessToURL:completion:, estaba diseñado para otorgar al cliente XPC permisos de lectura y escritura sobre una URL arbitraria
    • Internamente llama a la API sandbox_extension_issue_file para emitir un token de acceso a archivos
    • La URL arbitraria la especifica el cliente XPC en sandbox

  • Parche

    • En macOS Ventura 13.4, Apple lo parchó para verificar el entitlement com.apple.shortcuts.file-access-helper de los clientes XPC entrantes
    • Si no existe ese entitlement, rechaza la conexión XPC

CVE-2023-41077: mscamerad-xpc y evasión repetida de parches

  • El servicio vulnerable es /System/Library/Frameworks/ImageCaptureCore.framework/XPCServices/mscamerad-xpc.xpc
  • Este servicio podía ejecutarse sin restricciones de sandbox, por lo que podía explotarse para escapar del App Sandbox
  • La firma de código tenía entitlements TCC especiales que permitían acceder a Photos y Removable Volumes sin solicitar confirmación al usuario
  • Por lo tanto, esas protecciones TCC también podían evadirse

  • Flujo vulnerable

    • El nombre predeterminado del servicio es com.apple.mscamerad-xpc
    • El servicio acepta todos los clientes XPC
    • openDevice:withReply: de ICXPCDeviceManagerProtocol abre y configura un nuevo MSCameraDevice
    • Durante la inicialización del nuevo dispositivo, se abre otro servicio XPC anónimo para proporcionar rutinas de servicio para el dispositivo de cámara
    • Ese servicio XPC anónimo también acepta todos los clientes XPC
    • El método requestReadDataFromObjectHandle:options:withReply: de ICCameraDeviceProtocol lee el contenido del elemento de archivo solicitado y lo devuelve al cliente XPC
    • La ruta del archivo solicitado podía ser controlada por el cliente XPC, por lo que una app en sandbox podía leer archivos arbitrarios fuera de su contenedor
    • Debido a los potentes entitlements TCC del servicio, también podía leer Photos del usuario sin solicitar confirmación

  • Configuración de un dispositivo de cámara falso

    • MSCameraDevice podía emularse creando y montando un archivo DMG
    • Si una ruta de archivo dentro del volumen DMG coincidía con una expresión regular específica, el elemento de archivo se indexaba como ICCameraFile
    • Ejemplos de nombres de carpeta: 123abcde, DCIM, dcIm
    • Ejemplos de nombres de archivo: abcd1234.mp3, 1234E5678.HEIC
    • Una app en sandbox podía disparar el problema soltando, abriendo y montando el archivo DMG
    • El cliente XPC ya estaba implementado en el framework ImageCaptureCore

  • Parches y evasiones

    • Apple agregó una nueva verificación en acceptConnection: en macOS Sonoma 14
    • Permite el acceso si el cliente tiene el entitlement privado com.apple.private.imagecapturecore.authorization_bypass
    • O si el cliente es un platform binary
    • La condición de platform binary podía evadirse porque era posible inyectar una biblioteca dinámica en un binario firmado por Apple
      • Se elegía /bin/ls, un binario firmado por Apple sin entitlement
      • Se inyectaba una dylib con el código del exploit anterior mediante la variable de entorno DYLD_INSERT_LIBRARIES
      • Luego se comunicaba con el servicio XPC como antes
    • Apple asignó CVE-2024-23253 a este reporte de evasión
    • En macOS 14.4, la segunda condición se reforzó: el cliente XPC no solo debía ser un platform binary, sino que también debía estar firmado con las flags CS_REQUIRE_LV o CS_FORCED_LV
    • Este parche también podía evadirse
      • Se inyectaba una dylib en /bin/ls
      • En tiempo de ejecución, se configuraban manualmente las flags requeridas con la API csops
      • Luego se pasaba la verificación del servicio XPC
    • Apple asignó CVE-2024-40831 a esta segunda evasión
    • En macOS Sequoia 15, se volvió a parchear para permitir únicamente clientes XPC con el entitlement privado com.apple.private.imagecapturecore.authorization_bypass

CVE-2023-42961: intents_helper

  • Esta vulnerabilidad también puede explotarse en iOS
  • El servicio vulnerable es /System/Library/Frameworks/Intents.framework/XPCServices/intents_helper.xpc
  • El servicio puede ejecutarse sin restricciones de sandbox y acepta todos los clientes XPC
  • Debido a un path traversal en la función filePathForImageWithFileName, era posible acceder a rutas arbitrarias
  • El parámetro fileName es una cadena arbitraria que puede controlar el cliente XPC

  • Métodos afectados

    • La función vulnerable era alcanzable desde dos métodos XPC
    • retrieveImageWithIdentifier:completion: podía explotarse para leer archivos arbitrarios con extensión .png
    • Los datos leídos se almacenaban en una variable miembro de una instancia de INImage y se devolvían al cliente XPC
    • purgeImageWithIdentifier:completion: podía explotarse para borrar rutas de archivos arbitrarias

  • Parche

    • Apple lo parchó en macOS Sonoma 14.0 normalizando las cadenas de entrada del cliente XPC
    • Recorta los caracteres especiales usados para path traversal

CVE-2024-27864: diskimagescontroller

  • Al momento de escribir el artículo, la entrada CVE aún estaba pendiente de publicación
  • El servicio vulnerable es /System/Library/PrivateFrameworks/DiskImages2.framework/XPCServices/diskimagescontroller.xpc
  • Este servicio tiene el entitlement com.apple.diskimages.creator-uc en su firma de código, lo que le permite realizar acciones potentes
  • Las funciones principales de ese entitlement son dos
    • Comunicarse con /usr/libexec/diskimagesiod, que tiene FDA entitlement y realiza la operación real de attach
    • Conectarse al servicio IOKit AppleDiskImagesController para crear dispositivos para archivos DMG y aplicar quarantine

  • Causa de la vulnerabilidad

    • El servicio acepta todos los clientes XPC
    • El método attachWithParams:reply: de DIControllerProtocol era el punto de ataque
    • Internamente llama a checkAttachEntitlementWithError, pero, pese a su nombre, esta función siempre devuelve TRUE
    • En DiskImages2.framework, el cliente XPC ya está implementado con la clase Objective-C DIAttachParams
    • El código cliente del framework verifica si la URL de entrada está en estado de quarantine
    • Si la URL de entrada está en quarantine, antes del attach configura un parámetro de quarantine, y ese parámetro le indica al servicio XPC que aplique quarantine al dispositivo de destino
    • Al crear un cliente XPC propio, era posible omitir la configuración del parámetro de quarantine y llamar directamente a attachWithParams:reply:
    • Como resultado, era posible adjuntar un archivo DMG en quarantine sin aplicar quarantine al dispositivo correspondiente

  • Parche

    • En macOS Sonoma 14.4, Apple movió la lógica de validación del lado del cliente al lado del servidor
    • Si la ruta del archivo de entrada está en estado de quarantine, el servidor aplica directamente quarantine al dispositivo correspondiente

CVE-2023-42977: PerfPowerServicesSignpostReader

  • El servicio vulnerable es /System/Library/PrivateFrameworks/PowerlogCore.framework/XPCServices/PerfPowerServicesSignpostReader.xpc
  • El servicio podía ejecutarse sin restricciones de sandbox y aceptaba cualquier cliente XPC
  • XPCSignpostReaderProtocol tiene 6 métodos, pero Apple solo implementó submitSignpostDataWithConfig:withReply:; los otros 5 tienen implementaciones vacías
  • La lógica central de este método consiste en recopilar datos de logs y archivarlos en un archivo gzip
  • Con la cadena tagUUID controlada por el cliente XPC, se podía secuestrar la ruta de powerlog hacia una ruta arbitraria

  • Eliminación de rutas arbitrarias

    • Dentro de la función se llama a archiveDirectoryAt:deleteOriginal: para eliminar la ruta de powerlog
    • Si se incluye una cadena de path traversal en TagUUID, se puede obtener una primitive de eliminación de rutas arbitrarias

  • Creación de directorios arbitrarios y escape completo del sandbox

    • La función createSignpostFile: crea un directorio en la ruta de powerlog
    • Con esto se podía crear un directorio arbitrario sin el atributo extendido de quarantine
    • Una primitive de creación de directorios arbitrarios sin quarantine puede derivar en un escape completo del sandbox
    • En el artículo se usa la técnica de CVE-2023-32364
      • Crea una carpeta .app sin quarantine
      • Crea un symlink a /bin/bash debajo de Contents/MacOS
      • Configura BASH_ENV en LSEnvironment
      • La ejecuta con open ./poc.app

  • Parche

    • Apple lo corrigió en macOS Sonoma 14.0 normalizando la cadena UUID del cliente XPC
    • Si la cadena de entrada no es un UUID válido, la función sale sin continuar

Patrón repetido

  • La superficie de ataque principal no son los servicios XPC del dominio System o User, sino los servicios XPC del dominio PID dentro de frameworks del sistema y privados
  • Los servicios XPC cuyo Service Type es Application pueden registrarse en el dominio PID de una app en sandbox con solo cargar el framework
  • Muchos de los servicios vulnerables no esperaban llamadas de clientes en sandbox y omitieron las siguientes verificaciones
    • Verificación de entitlements del cliente XPC
    • Verificación de si el cliente está en sandbox
    • Normalización de rutas de entrada
    • Validación del estado de quarantine del lado del servidor
  • Las condiciones explotadas repetidamente fueron las siguientes
    • El drop de archivos o carpetas sin quarantine puede conducir a un escape completo del sandbox
    • Si el atributo extendido de quarantine desaparece durante la descompresión, puede derivar en una omisión de Gatekeeper y un escape del sandbox
    • Los archivos creados por Service Sandbox no se marcan con quarantine de forma predeterminada
  • Todavía quedan 5 reportes pendientes de parche

Comentarios adicionales sobre App Sandbox y Service Sandbox

  • Sobre un reporte, Apple determinó que era expected behavior, porque la aplicación recién lanzada no está en el contexto del proceso actual y no puede compartir los entitlements ni los permisos del proceso actual
  • En App Sandbox, los archivos soltados reciben quarantine de forma predeterminada
  • En Service Sandbox, los archivos soltados no reciben quarantine de forma predeterminada
  • Se resume que el hecho de que un proceso recién lanzado no esté en el contexto de ejecución del servicio actual y no comparta los entitlements o privilegios de ese servicio no es, en sí mismo, una falla
  • En cambio, el hecho de que un atacante pueda obtener RCE en el contexto de un servicio restringido por sandbox, luego soltar y ejecutar una nueva app sin sandbox para salir de las restricciones de sandbox del servicio objetivo, sí puede considerarse una falla
    • Como ejemplo, se menciona IMTranscoderAgent, que fue objetivo de un exploit 0-click de NSO Group
  • com.apple.WebDriver.HTTPService.xpc aparece como ejemplo de llamada manual a la API WBSEnableSandboxStyleFileQuarantine
  • Se resume que escapar de App Sandbox a Service Sandbox en macOS equivale, en la práctica, a pasar a Non Sandbox

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-11-09
Comentarios en Hacker News

  • La respuesta de ir parcheando servicios XPC uno por uno aquí se siente un poco rara
    Parece más bien un problema de diseño del sandbox, y queda la duda de por qué tantos servicios XPC que aparentan ser para uso interno de las apps son accesibles desde apps dentro del sandbox

    • Sí. Es muy probable que esto sea un compromiso al haberlo incorporado después en macOS, para no romper cosas heredadas de UNIX y NeXTSTEP
      En Windows también hay mecanismos parecidos, como el sandbox de WinRT, el sandbox para apps Win32, el kernel de seguridad y la protección de drivers, pero si quieres ejecutar un solo binario a través de varias configuraciones, terminan apareciendo huecos de compatibilidad hacia atrás
      En los sistemas operativos móviles es mucho más fácil, porque no hay compatibilidad hacia atrás y se puede restringir fuertemente el modelo de ejecución

  • macOS debería tener algo como contenedores de Darwin basados en capabilities, en vez de parecer un enorme montón de listas de bloqueo

  • Buen trabajo
    Pero queda la duda de si esta arquitectura va en la dirección correcta. Parece que cada vez que se crea un framework de seguridad para bloquear cierto tipo de ataque, termina apareciendo una clase completamente nueva de problemas, y no da la impresión de que al final estemos más seguros
    Es como el sistema fiscal neerlandés: una estructura sobre la que se siguen apilando parches para impedir abusos, y quizá ya hasta haya adquirido conciencia

    • Eso pasa porque muchos de estos sistemas nunca fueron diseñados para ser realmente seguros de punta a punta
      La forma correcta de hacerlo suele fracasar en el mercado por la compatibilidad hacia atrás o porque los desarrolladores se niegan a adoptar las restricciones. El sandbox de WinRT es un ejemplo de eso
      La seguridad en teléfonos lo tuvo más fácil porque no necesitaba preocuparse por compatibilidad hacia atrás y, hasta ahora, el gatekeeping de las app stores ha obligado a los desarrolladores que quieren participar a seguir las reglas
    • Al final, la seguridad es difícilmente compatible con la compatibilidad hacia atrás
      Todos los sistemas operativos que hoy están en uso tendrían que rehacerse desde cero para ser seguros hasta el próximo siglo, y en ese proceso habría que tirar mucho código. Ese es el costo
    • Es graciosa la referencia al sistema fiscal neerlandés. No me sorprendería tanto si algunas de esas “lagunas para abuso” hubieran sido puestas ahí a propósito
      Se puede especular que también podría haber fuerzas poderosas interesadas en meter más vulnerabilidades en la computación de consumo
      Algunos ejemplos conocidos son estos
      https://en.wikipedia.org/wiki/Dutch_Sandwich
      https://en.wikipedia.org/wiki/Intel_Management_Engine#Assert...

  • macOS, o sea NeXTstep, fue creado desde el principio como un sistema operativo abierto y extremadamente extensible
    Había incontables formas de añadir extensiones o hooks de terceros, y como el software podía accederse desde varios runtimes, en ese momento ya era un logro técnico impresionante que todo eso funcionara de manera fluida en conjunto
    Java, Mac clásico, X11 y la base de código de NeXTstep corrían juntos sin problemas gracias a varios puntos de entrada de extensión del kernel
    Además, la plataforma también tenía APIs para que las apps se comunicaran entre sí sin problemas
    Pero Apple se ha ido alejando poco a poco de esa filosofía y sigue cerrando cada vez más el sistema. Ha sido un recorrido bastante interesante

  • SBPL (sandbox profile language) es interesante. Aquí hay más detalles: https://github.com/0xbf00/simbple
    Me pregunto si en algún lugar dentro de macOS hay un intérprete de Scheme que procese esto
    P. D.: parece que quien hace este trabajo es sandbox-exec. Referencia: https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sand...

  • Hallazgo impresionante. Como también se insinúa en el artículo, parece muy probable que todavía queden fallas similares circulando por ahí
    Si Apple no rediseña su enfoque para reforzar estos servicios, da la impresión de que seguirán apareciendo CVE relacionados con XPC

  • Me gustan y no me gustan los sandboxes
    Son una excelente segunda línea de defensa, pero las organizaciones grandes tienden a negarse a corregir vulnerabilidades de ejecución remota de código si no se puede escapar del sandbox y hacer algo realmente útil. Entonces el sandbox acaba usándose como defensa principal, y eso da tristeza

    • No sé a quién se refiere eso de que “se niegan a corregir vulnerabilidades de ejecución remota de código si no se puede escapar del sandbox”
      Hasta donde sé, Apple, Microsoft y Google tienen programas de bug bounty, y aunque pagan más por escapes de sandbox, también pagan por vulnerabilidades que quedan contenidas por el sandbox
      Todo el mundo sabe que los atacantes pueden guardar vulnerabilidades de ejecución remota de código que hoy todavía no sirven y combinarlas después cuando se descubra una vía de escape del sandbox

  • Un poco fuera de tema, pero si algún experto en sandbox conoce una estrategia para eludir el límite de maximum "pattern serialization length", este problema me dio dolores de cabeza durante bastante tiempo: https://github.com/NixOS/nix/issues/4119
    Por desgracia, sandbox-exec casi no está documentado y además se habla de que será descontinuado, así que resolverlo ha sido bastante complicado

  • En macOS siguen apareciendo bypasses sin fin. Este sistema operativo ni siquiera fue diseñado originalmente para este tipo de permisos granulares
    No es algo que simplemente puedas montar después sobre tecnología heredada de Mac OS y NeXTSTEP
    Ni siquiera soy investigador de seguridad, solo un desarrollador de apps antiguas, y aun así encontré varios bypasses por mi cuenta. Digamos que sé dónde están enterrados los cadáveres
    Pero al final dejé de buscarlos. El sistema de reporte de vulnerabilidades de Apple es un desastre total y parecía interesado solo en mantenerte callado el mayor tiempo posible. Es una pérdida de tiempo
    En general, macOS da la impresión de haberse convertido en víctima del teatro de seguridad. Perjudica tanto a usuarios como a desarrolladores legítimos con software debilitado y solicitudes interminables de permisos, mientras que los atacantes reales pueden saltárselo fácilmente cuando quieran. Se parece a la vieja parodia de Windows Vista que hacía Apple

    • Parece que el investigador que escribió esto sí logró que corrigieran bastantes huecos con el crédito correspondiente. Aun así, algunos de estos CVE parecen tener ya varios años
      Que una empresa quiera el mayor tiempo posible para corregir errores también es parte del juego. ¿De verdad otras empresas querrían que las vulnerabilidades descubiertas se hicieran públicas lo antes posible? Como no pueden controlar qué tan rápido actualizan los usuarios, retrasar la divulgación siempre parece mejor para el usuario final, y eso debería estar por encima del deseo de promoción del investigador
      La arquitectura del sandbox de Apple normalmente parece bastante bien diseñada. En este caso, da la impresión de que hubo algún problema en la arquitectura o en la comunicación
      Que existan bypasses también se debe a que se les exige demasiada funcionalidad a los sistemas operativos de escritorio. Se puede decir que son sistemas operativos mucho más sofisticados y complejos que las plataformas de servidor. Los navegadores web también tienen muchos CVE por la misma razón. Queremos seguridad y también funcionalidad, así que inevitablemente aparece un punto intermedio donde ambas chocan
    • A diferencia de la afirmación de que “no es algo que simplemente puedas montar después sobre tecnología heredada de Mac OS y NeXTSTEP”, Apple sí puede hacerlo y de hecho lo ha hecho, porque posee toda la pila
      La prueba está en que ha ido reforzando gradualmente el software y el hardware de macOS durante los últimos 20 años
      Para la mayoría de los usuarios finales ha sido lo bastante gradual como para que casi no lo noten, pero los desarrolladores de macOS conocen muy bien los problemas de seguridad que tienen que lidiar tanto en actualizaciones grandes como pequeñas. Por ejemplo:
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/09/…
    • Este tipo de carga heredada parece existir en todos los sistemas operativos principales
      Existen sistemas basados en capabilities, pero no hay ninguno de uso realmente extendido
      No tengo claro cuál sería la solución. Aun así, intentar agregar seguridad parece mejor que no hacer nada y dejar que una sola vulnerabilidad de una aplicación se convierta de inmediato en el control total de la cuenta del usuario
    • Si “no se puede agregar después sobre Mac OS heredado”, entonces SELinux sí lo logró; ¿qué es lo que impide fundamentalmente que macOS lo haga?
    • La razón de estas limitaciones es hacer más difícil que los desarrolladores terceros compitan con los productos de Apple

  • Los servicios XPC que se pasaron por alto en el dominio pid son una forma ingeniosa de eludir las restricciones del sandbox de macOS
    El truco de inyección de dyld para evitar las comprobaciones de permisos también está muy pulido
    El parche de Apple aquí se siente como una solución temporal, y quizá haga falta revisar de fondo cómo funciona la herencia del sandbox