Várias novas vulnerabilidades de escape do sandbox no macOS

 (jhftss.github.io)
1 pontos por GN⁺ 2024-11-09 | 1 comentários | Compartilhar no WhatsApp
  • Em uma pesquisa sobre escape de sandbox no macOS, os relativamente menos explorados serviços XPC do domínio PID surgiram como superfície de ataque, levando à descoberta de mais de 10 novas vulnerabilidades
  • O alvo principal não são os serviços Mach dos domínios System/User, mas sim os serviços XPC do tipo Application registrados no domínio PID ao carregar apps ou frameworks
  • Os casos vulneráveis incluem CVE-2023-27944, CVE-2023-32414, CVE-2023-32404, CVE-2023-41077, CVE-2023-42961, CVE-2024-27864 e CVE-2023-42977, e alguns se conectam a bypass de TCC, permissões relacionadas ao SIP e até impacto no iOS
  • Os pontos de falha recorrentes foram serviços não isolados que processavam arquivos, diretórios, arquivos compactados e DMGs sem tratar com segurança o atributo estendido de quarantine, strings de caminho e a validação de privilégios do cliente
  • A resposta da Apple incluiu remoção de serviços XPC vulneráveis, normalização de entrada, migração da validação para o lado do servidor e exigência de private entitlement, mas ainda restam 5 relatórios aguardando correção

Modelo de sandbox do macOS e objetivo do escape

  • No macOS, muitos processos, incluindo serviços da própria Apple e apps de terceiros, executam em um ambiente de sandbox restrito
  • Mesmo que um invasor obtenha execução remota de código (RCE) em um processo sandboxado, a capacidade de execução e as permissões de acesso a arquivos permanecem limitadas, então o passo seguinte é o escape do sandbox para obter privilégios mais amplos

  • App Sandbox

    • Por exigência da Mac App Store, muitos apps rodam com restrições de App Sandbox
    • Apps sandboxados precisam ter a entitlement com.apple.security.app-sandbox
    • As restrições são aplicadas na etapa de inicialização do dyld, antes da função main do app
    • Ao entrar no App Sandbox, o app é conteinerizado, e as operações de arquivo ficam limitadas ao caminho do contêiner de dados
    • Arquivos criados por apps sandboxados recebem por padrão o atributo estendido com.apple.quarantine
    • O perfil do sandbox contém regras que impedem a remoção desse atributo estendido
    • As permissões detalhadas do App Sandbox são definidas em /System/Library/Sandbox/Profiles/application.sb
    • Rede, hardware, sistema de arquivos e serviços Mach acessíveis são restringidos
    • Processos filhos criados com fork herdam as restrições de App Sandbox do processo pai
    • Processos executados por LaunchService.framework não herdam as restrições; por exemplo, é possível executar diretamente um app não sandboxado com o comando de sistema open

  • Service Sandbox

    • Muitos serviços daemon da Apple executam no contexto de Service Sandbox
    • Os perfis de sandbox de serviço ficam principalmente em /System/Library/Sandbox/Profiles/*.sb e /usr/share/sandbox/*.sb
    • As restrições de Service Sandbox são aplicadas manualmente na função main do serviço por meio da chamada da API sandbox_init_XXX
    • Serviços que entram em Service Sandbox normalmente não são conteinerizados
    • Uma diferença importante é que arquivos criados no Service Sandbox não recebem quarantine por padrão
    • Se as APIs relacionadas a quarantine não forem chamadas manualmente, os arquivos criados não recebem quarantine

Caminhos existentes de escape do sandbox no macOS

  • Ataque via LaunchService.framework

    • Um dos métodos comuns já conhecidos é atacar apps não sandboxados por meio de LaunchService.framework
    • CVE-2021-30864 foi um caso de manipulação da variável de ambiente $HOME contra o app de sistema não sandboxado Terminal.app
    • Ao iniciar o Terminal, uma carga maliciosa sob $HOME/.profile, controlável pelo atacante, era executada sem restrições de sandbox
    • Outro cenário é soltar e depois executar um novo app não sandboxado
    • No entanto, apps recém-soltos por um app sandboxado recebem quarantine e sua execução é bloqueada
    • Se for possível soltar um arquivo ou pasta sem quarantine, é possível contornar completamente o App Sandbox
    • CVE-2023-32364 foi um caso em que se soltou uma pasta sem quarantine explorando o fato de que devfs não oferece suporte a atributos estendidos

  • Ataque a serviços Mach acessíveis

    • O segundo método comum é atacar serviços Mach listados no perfil do App Sandbox
    • As informações dos serviços Mach do sistema são armazenadas em /System/Library/xpc/launchd.plist
    • Com a API bootstrap_look_up, é possível verificar a partir de um app sandboxado se um serviço Mach específico está acessível
    • Esses serviços Mach existem no domínio System ou no domínio User
    • O ponto de partida desta pesquisa foi que há mais serviços XPC acessíveis a partir do App Sandbox além desses dois domínios

Nova superfície de ataque: serviços XPC do domínio PID

  • Os serviços XPC ignorados ficam no domínio PID
  • Diferentemente dos serviços XPC dos domínios System/User, mais observados tradicionalmente, eles têm tipo de serviço Application
  • Serviços XPC do tipo Application são iniciados sob demanda do app e encerrados junto com o app solicitante
  • Serviços XPC dos domínios System/User só podem ser acessados por apps sandboxados quando definidos em application.sb
  • Todos os serviços XPC necessários para apps e frameworks ficam visíveis no domínio PID do respectivo app
  • Muitos serviços XPC do domínio PID não presumem que serão invocados por apps sandboxados, então podem não ter verificação de entitlement nem de sandbox para clientes XPC de entrada

  • Caso SystemShoveService.xpc

    • SystemShoveService.xpc é um bundle XPC dentro do framework privado de sistema ShoveService.framework
    • No Info.plist, o tipo de serviço é Application, e o identificador do bundle é com.apple.installandsetup.shoveservice.system
    • Ao carregar /System/Library/PrivateFrameworks/ShoveService.framework em um app sandboxado, o serviço XPC correspondente é automaticamente registrado no domínio PID
    • SystemShoveService.xpc não inspecionava o cliente XPC solicitante, o que permitia seu abuso para escape do App Sandbox
    • Esse serviço tinha a poderosa entitlement relacionada ao SIP com.apple.rootless.install, o que também podia levar a bypass da proteção do SIP
    • A vulnerabilidade recebeu o identificador CVE-2022-26712, e os detalhes estão organizados em um texto anterior

  • Método de exploração

    • Todos os serviços XPC com Service Type Application são alvos potenciais para escape do App Sandbox
    • É possível encontrá-los enumerando serviços XPC em frameworks do sistema e frameworks privados
      • /System/Library/Frameworks
      • /System/Library/PrivateFrameworks
    • Se houver um serviço XPC do domínio PID que não inspeciona clientes XPC de entrada, é possível tentar o ataque das seguintes formas
      • Soltar uma pasta de app sem quarantine para obter um escape completo do sandbox
      • Soltar sem quarantine um arquivo ZIP ou DMG que contenha um app não sandboxado

2 vulnerabilidades apenas em beta

  • Beta-No-CVE-1: execução arbitrária de comandos no StorageKit

    • A Apple registrou essa vulnerabilidade em additional recognitions, mas não atribuiu um CVE
    • Segundo a Apple, CVEs só são atribuídos a vulnerabilidades em softwares lançados em produção, e não a vulnerabilidades em softwares apenas beta
    • O impacto se limitava às versões Beta do macOS Sonoma
    • O caminho do serviço XPC vulnerável era /System/Library/PrivateFrameworks/StorageKit.framework/XPCServices/storagekitfsrunner.xpc
    • Esse serviço podia ser executado sem restrições de sandbox e aceitava todos os clientes XPC no método delegate
    • O único método de SKRemoteTaskRunnerProtocol, runTask:arguments:withReply:, havia sido projetado para executar comandos arbitrários com o caminho do executável e os argumentos especificados
    • Como o caminho do executável e os argumentos podiam ser controlados por um cliente XPC em sandbox, era possível executar comandos arbitrários do sistema sem restrições de sandbox
    • A Apple removeu completamente o serviço XPC vulnerável do sistema operacional antes do lançamento oficial do macOS Sonoma 14.0

  • Beta-No-CVE-2: abuso da criação de ZIP no AudioAnalyticsHelperService

    • Essa vulnerabilidade também não recebeu CVE pelo mesmo motivo de ser apenas beta
    • O caminho do serviço XPC vulnerável era /System/Library/PrivateFrameworks/AudioAnalyticsInternal.framework/XPCServices/AudioAnalyticsHelperService.xpc
    • O serviço podia ser executado sem restrições de sandbox e aceitava todos os clientes XPC
    • O método createZipAtPath:hourThreshold:withReply: compactava um caminho arbitrário especificado pelo cliente XPC
    • Se não houvesse uma pasta compressed no caminho especificado, ela era criada, depois arquivos .json eram localizados, movidos para essa pasta e então o arquivo ZIP era criado
    • Um invasor podia trocar a pasta compressed por um symlink para mover arquivos arbitrários para locais arbitrários
    • O conteúdo do arquivo de origem não era verificado, e o caminho do arquivo de destino precisava ter o sufixo .json
    • Como o novo arquivo ZIP era criado por um serviço sem sandbox, ele não recebia quarantine
    • A Apple corrigiu isso antes do lançamento do macOS Sonoma 14.0, passando a verificar o entitlement com.apple.audioanalytics.helper.service dos clientes XPC recebidos
    • Nas versões mais recentes do macOS, o AudioAnalyticsInternal.framework privado e o respectivo serviço XPC foram removidos por completo

CVE-2023-27944: TrialArchivingService

  • O serviço vulnerável era /System/Library/PrivateFrameworks/TrialServer.framework/XPCServices/TrialArchivingService.xpc
  • Esse serviço entra em Service Sandbox com o perfil /System/Library/Sandbox/Profiles/com.apple.trial.TrialArchivingService.sb
  • Por ser um Service Sandbox, os arquivos soltos não recebem quarantine
  • O serviço aceitava todos os clientes XPC recebidos
  • O método extractArchiveFromHandle:withArchiveName:toDirectory:destDirExtension:postExtractionCompression:completion: extraía para um local especificado um arquivo compactado enviado por um app em sandbox
  • Como o conteúdo extraído não recebia o atributo estendido de quarantine, isso podia resultar em drop de arquivos sem quarantine

  • Condições de exploração e bypass

    • Ao abusar desse método, arquivos Mach-O dentro do arquivo compactado perdiam a permissão de execução após a extração, então não podiam ser executados imediatamente
    • Um contorno poderia ser usar symlink, como na técnica de CVE-2021-30990
    • Porém, esse método XPC só extrai diretórios e arquivos regulares, e não permite extrair symlinks do arquivo compactado
    • Um método de bypass é extrair o app payload para o caminho do contêiner do app em sandbox
    • Como o app em sandbox tem permissão de leitura e escrita nesse caminho, ele pode criar diretamente um symlink ou conceder permissão de execução com chmod
    • Outro método é arquivar o app payload duas vezes
      • Descompactar o ZIP externo com o método XPC vulnerável
      • Descompactar o ZIP interno com o comando do sistema open

  • Correção

    • A Apple corrigiu isso no macOS Ventura 13.3, passando a verificar o entitlement com.apple.TrialArchivingService.internal dos clientes XPC recebidos
    • Se esse entitlement não estiver presente, a conexão XPC é recusada

CVE-2023-32414: ArchiveService

  • O serviço vulnerável era /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/XPCServices/ArchiveService.xpc
  • Esse serviço entra em Service Sandbox, mas os arquivos soltos não recebem quarantine
  • O serviço aceitava todos os clientes XPC
  • O método unarchiveItemWithURLWrapper:… descompactava, em um local especificado, um item enviado por um app em sandbox
  • Como o conteúdo extraído não recebia o atributo estendido de quarantine, um app em sandbox podia soltar arquivos arbitrários sem quarantine
  • O cliente XPC já estava implementado na classe Objective-C DSArchiveService de DesktopServicesPriv.framework

  • Correção

    • A Apple corrigiu isso no macOS Ventura 13.4, passando a verificar o entitlement com.apple.private.ArchiveService.XPC dos clientes XPC recebidos
    • Se esse entitlement não estiver presente, a conexão XPC é recusada

CVE-2023-32404: ShortcutsFileAccessHelper

  • O serviço vulnerável era /System/Library/PrivateFrameworks/WorkflowKit.framework/XPCServices/ShortcutsFileAccessHelper.xpc
  • Esse serviço podia ser executado sem restrições de sandbox, o que permitia seu abuso para escapar do App Sandbox
  • A assinatura de código também incluía um entitlement especial de TCC para Full Disk Access
  • Por isso, essa vulnerabilidade também podia ser usada para contornar completamente as proteções do TCC
  • O serviço aceitava todos os clientes XPC
  • O único método de WFFileAccessHelperProtocol, extendAccessToURL:completion:, havia sido projetado para conceder ao cliente XPC permissões de leitura e escrita sobre uma URL arbitrária
    • Internamente, ele chamava a API sandbox_extension_issue_file para emitir um token de acesso a arquivo
    • A URL arbitrária era especificada pelo cliente XPC em sandbox

  • Correção

    • A Apple corrigiu isso no macOS Ventura 13.4, passando a verificar o entitlement com.apple.shortcuts.file-access-helper dos clientes XPC recebidos
    • Se esse entitlement não estiver presente, a conexão XPC é recusada

CVE-2023-41077: mscamerad-xpc e bypasses repetidos de patch

  • O serviço vulnerável é /System/Library/Frameworks/ImageCaptureCore.framework/XPCServices/mscamerad-xpc.xpc
  • Esse serviço podia ser executado sem restrições de sandbox, então podia ser explorado para escapar do App Sandbox
  • A assinatura de código tinha um entitlement especial de TCC que permitia acessar Photos e Removable Volumes sem prompt ao usuário
  • Portanto, essa proteção de TCC também podia ser contornada

  • Fluxo da vulnerabilidade

    • O nome padrão do serviço é com.apple.mscamerad-xpc
    • O serviço permitia todos os clientes XPC
    • ICXPCDeviceManagerProtocol de openDevice:withReply: abre e configura um novo MSCameraDevice
    • Durante a inicialização do novo dispositivo, outro serviço XPC anônimo é aberto para fornecer rotinas de serviço ao dispositivo de câmera
    • Esse serviço XPC anônimo também permitia todos os clientes XPC
    • O método requestReadDataFromObjectHandle:options:withReply: de ICCameraDeviceProtocol lê o conteúdo do item de arquivo solicitado e o retorna ao cliente XPC
    • Como o caminho do arquivo solicitado podia ser controlado pelo cliente XPC, um app em sandbox podia ler arquivos arbitrários fora do contêiner
    • Por causa do forte entitlement de TCC do serviço, também era possível ler as Photos do usuário sem prompt

  • Configuração de dispositivo de câmera falso

    • MSCameraDevice podia ser emulado criando e montando um arquivo DMG
    • Se o caminho do arquivo dentro do volume DMG correspondesse a um regex específico, o item de arquivo era indexado como ICCameraFile
    • Exemplos de nome de pasta: 123abcde, DCIM, dcIm
    • Exemplos de nome de arquivo: abcd1234.mp3, 1234E5678.HEIC
    • Um app em sandbox podia acionar o problema soltando um arquivo DMG, abrindo-o e montando-o
    • O cliente XPC já estava implementado no framework ImageCaptureCore

  • Patch e bypass

    • A Apple adicionou uma nova verificação em acceptConnection: no macOS Sonoma 14
    • Permitia o cliente se ele tivesse o private entitlement com.apple.private.imagecapturecore.authorization_bypass
    • Ou permitia se o cliente fosse um platform binary
    • A condição de platform binary podia ser contornada injetando uma biblioteca dinâmica em um binário assinado pela Apple
      • Foi escolhido o binário assinado pela Apple /bin/ls, que não tem o entitlement
      • Uma dylib com o código do exploit anterior foi injetada pela variável de ambiente DYLD_INSERT_LIBRARIES
      • Depois disso, a comunicação com o serviço XPC seguia como antes
    • A Apple atribuiu CVE-2024-23253 a esse relatório de bypass
    • No macOS 14.4, a segunda condição foi endurecida: além de ser platform binary, o cliente XPC precisava ser assinado com as flags CS_REQUIRE_LV ou CS_FORCED_LV
    • Esse patch também podia ser contornado
      • Foi feita a injeção de dylib em /bin/ls
      • Em tempo de execução, as flags exigidas eram definidas manualmente via API csops
      • Depois disso, a verificação do serviço XPC era aprovada
    • A Apple atribuiu CVE-2024-40831 a esse segundo bypass
    • No macOS Sequoia 15, foi aplicado outro patch para permitir apenas clientes XPC com o private entitlement com.apple.private.imagecapturecore.authorization_bypass

CVE-2023-42961: intents_helper

  • Essa vulnerabilidade também podia ser explorada no iOS
  • O serviço vulnerável é /System/Library/Frameworks/Intents.framework/XPCServices/intents_helper.xpc
  • O serviço podia ser executado sem restrições de sandbox e permitia todos os clientes XPC
  • Por causa de uma path traversal na função filePathForImageWithFileName, era possível acessar caminhos arbitrários
  • O parâmetro fileName é uma string arbitrária controlável pelo cliente XPC

  • Métodos afetados

    • A função vulnerável era alcançável a partir de dois métodos XPC
    • retrieveImageWithIdentifier:completion: podia ser explorado para ler arquivos arbitrários com extensão .png
    • Os dados lidos eram armazenados em uma variável de membro de uma instância INImage e retornados ao cliente XPC
    • purgeImageWithIdentifier:completion: podia ser explorado para apagar caminhos de arquivo arbitrários

  • Patch

    • A Apple corrigiu isso no macOS Sonoma 14.0 normalizando as strings de entrada do cliente XPC
    • Os caracteres especiais usados em path traversal eram removidos

CVE-2024-27864: diskimagescontroller

  • O registro CVE ainda aguardava divulgação pública no momento da escrita
  • O serviço vulnerável é /System/Library/PrivateFrameworks/DiskImages2.framework/XPCServices/diskimagescontroller.xpc
  • Esse serviço tinha o entitlement com.apple.diskimages.creator-uc na assinatura de código, o que permitia operações poderosas
  • Há duas funções principais desse entitlement
    • Comunicar-se com /usr/libexec/diskimagesiod, que tem o FDA entitlement e executa a operação real de attach
    • Conectar-se ao serviço IOKit AppleDiskImagesController para criar dispositivos para arquivos DMG e aplicar quarantine

  • Causa da vulnerabilidade

    • O serviço permitia todos os clientes XPC
    • O método attachWithParams:reply: de DIControllerProtocol era o ponto de ataque
    • Internamente, ele chama checkAttachEntitlementWithError, mas essa função, ao contrário do que o nome sugere, sempre retorna TRUE
    • O DiskImages2.framework já fornece um cliente XPC implementado pela classe Objective-C DIAttachParams
    • O código cliente do framework verifica se a URL de entrada está em estado de quarantine
    • Se a URL de entrada estiver em quarantine, ele define parâmetros de quarantine antes do attach, e esses parâmetros instruem o serviço XPC a aplicar quarantine ao dispositivo de destino
    • Ao criar um cliente XPC próprio, é possível pular a definição dos parâmetros de quarantine e chamar attachWithParams:reply: diretamente
    • Como resultado, era possível fazer attach de um arquivo DMG em quarantine sem aplicar quarantine ao dispositivo correspondente

  • Patch

    • A Apple moveu a lógica de validação do lado do cliente para o lado do servidor no macOS Sonoma 14.4
    • Se o caminho do arquivo de entrada estiver em quarantine, o servidor aplica quarantine diretamente ao dispositivo correspondente

CVE-2023-42977: PerfPowerServicesSignpostReader

  • O serviço vulnerável é /System/Library/PrivateFrameworks/PowerlogCore.framework/XPCServices/PerfPowerServicesSignpostReader.xpc
  • O serviço pode ser executado sem restrições de sandbox e aceita todos os clientes XPC
  • XPCSignpostReaderProtocol tem 6 métodos, mas a Apple implementou apenas submitSignpostDataWithConfig:withReply:; os outros 5 estão vazios
  • A lógica principal desse método é coletar dados de log e arquivá-los em um arquivo gzip
  • Era possível sequestrar o caminho de powerlog para um caminho arbitrário usando a string tagUUID controlada pelo cliente XPC

  • Exclusão de caminho arbitrário

    • Dentro da função, archiveDirectoryAt:deleteOriginal: é chamado para excluir o caminho de powerlog
    • Se TagUUID contiver uma string de path traversal, é possível obter um primitive de exclusão de caminho arbitrário

  • Criação de diretório arbitrário e escape completo do sandbox

    • A função createSignpostFile: cria um diretório no caminho de powerlog
    • Com isso, é possível criar um diretório arbitrário sem o atributo estendido de quarantine
    • Um primitive de criação de diretório arbitrário sem quarantine pode levar a um escape completo do sandbox
    • O texto usa a técnica de CVE-2023-32364
      • Cria uma pasta .app sem quarantine
      • Cria um symlink para /bin/bash em Contents/MacOS
      • Define BASH_ENV em LSEnvironment
      • Executa com open ./poc.app

  • Patch

    • A Apple corrigiu isso no macOS Sonoma 14.0 normalizando a string UUID do cliente XPC
    • Se a string de entrada não for um UUID válido, a função retorna imediatamente

Padrão recorrente

  • A principal superfície de ataque não são serviços XPC dos domínios System ou User, mas sim serviços XPC do domínio PID dentro de frameworks de sistema e private
  • Serviços XPC com Service Type Application podem ser registrados no domínio PID de um app em sandbox apenas com o carregamento do framework
  • Muitos dos serviços vulneráveis não esperavam chamadas de clientes em sandbox e por isso deixavam de fazer as seguintes verificações
    • Verificação de entitlement do cliente XPC
    • Verificação se o cliente é um cliente em sandbox
    • Normalização do caminho de entrada
    • Verificação, no lado do servidor, do estado de quarantine
  • As condições exploradas repetidamente foram as seguintes
    • Drop de arquivos/pastas sem quarantine pode levar a um escape completo do sandbox
    • Se o atributo estendido de quarantine desaparecer durante a descompressão, isso pode levar a bypass do Gatekeeper e escape do sandbox
    • Arquivos criados pelo Service Sandbox não recebem quarantine por padrão
  • Ainda restam 5 relatórios aguardando patch

Observações adicionais sobre App Sandbox e Service Sandbox

  • Em um dos relatórios, a Apple avaliou como expected behavior porque a aplicação recém-executada não está no contexto do processo atual e não pode compartilhar os entitlements nem os privilégios do processo atual
  • No App Sandbox, arquivos soltos recebem quarantine por padrão
  • No Service Sandbox, arquivos soltos não recebem quarantine por padrão
  • A conclusão é que, por si só, o fato de um processo recém-executado não estar no contexto de execução do serviço atual e não compartilhar os entitlements ou privilégios desse serviço não é uma falha
  • Por outro lado, pode ser considerado uma falha o fato de um atacante conseguir RCE no contexto de um serviço com restrição de sandbox e depois soltar e executar um novo app sem sandbox para escapar das restrições de sandbox do serviço alvo
    • Como exemplo, é citado o IMTranscoderAgent, alvo de um 0-click exploit do NSO Group
  • com.apple.WebDriver.HTTPService.xpc aparece como exemplo de chamada manual da API WBSEnableSandboxStyleFileQuarantine
  • Conclui-se que escapar do App Sandbox para o Service Sandbox no macOS equivale, na prática, a ir para Non Sandbox

Leituras relacionadas

1 comentários

 
GN⁺ 2024-11-09
Opiniões no Hacker News

  • A resposta de aplicar patches individualmente, um por um, nos serviços XPC aqui é meio estranha.
    Parece mais um problema de design do próprio sandbox, e fica a dúvida de por que tantos serviços XPC, que parecem ser internos aos apps, são acessíveis por apps em sandbox.

    • Sim. É bem provável que isso seja um compromisso feito ao enxertar esse recurso posteriormente no macOS, para não quebrar coisas herdadas do UNIX e do NeXTSTEP.
      No lado do Windows também há muitos mecanismos parecidos, como sandbox do WinRT, sandbox de apps Win32, kernel seguro, proteção de drivers etc., mas, se você quer rodar um único executável em várias configurações, surgem brechas de compatibilidade retroativa.
      Em sistemas operacionais móveis, é bem mais fácil, porque não há compatibilidade retroativa e o modelo de execução pode ser restringido com força.

  • O MacOS deveria ter algo como contêineres Darwin baseados em capabilities, em vez de um modelo que parece um enorme monte de listas de bloqueio.

  • Bom trabalho.
    Ainda assim, fico em dúvida se esse tipo de arquitetura é o caminho certo. Toda vez que se cria um framework de segurança para bloquear algum ataque, parece surgir uma classe completamente nova de problemas, e no fim não dá a sensação de que ficou mais seguro.
    É uma estrutura como a legislação tributária holandesa, em que patches para impedir abusos vão se acumulando, e talvez ela já tenha adquirido consciência.

    • Isso acontece porque muitos desses sistemas não foram projetados para ser devidamente seguros de ponta a ponta desde o início.
      A abordagem correta geralmente fracassa no mercado por causa da compatibilidade retroativa ou da recusa dos desenvolvedores em adotar os recursos. O sandbox do WinRT é um exemplo disso.
      A segurança em celulares foi mais fácil porque não havia necessidade de se preocupar com compatibilidade retroativa e, até agora, graças ao gatekeeping das lojas de apps, os desenvolvedores que querem participar não têm escolha a não ser seguir as regras.
    • No fim, segurança é difícil de conciliar com compatibilidade retroativa.
      Todos os sistemas operacionais em operação hoje precisam ser refeitos do zero para serem seguros até o próximo século e, nesse processo, muito código terá de ser descartado. Esse é o preço a pagar.
    • É engraçado você mencionar a legislação tributária holandesa. Acho que não seria muito controverso dizer que algumas dessas “brechas de abuso” foram colocadas ali de propósito.
      Dá para especular que pode haver forças poderosas tentando inserir mais vulnerabilidades na computação de consumo.
      Alguns exemplos famosos, respectivamente:
      https://en.wikipedia.org/wiki/Dutch_Sandwich
      https://en.wikipedia.org/wiki/Intel_Management_Engine#Assert...

  • O MacOS, ou seja, o NeXTstep, foi criado desde o início como um sistema operacional aberto e extremamente extensível.
    Havia inúmeras formas de adicionar extensões ou hooks de terceiros, e era possível acessar software a partir de vários runtimes; na época, o simples fato de tudo isso funcionar junto de forma fluida já era uma realização técnica impressionante.
    Java, o Mac clássico, X11 e a base de código do NeXTstep rodavam juntos sem problemas graças aos vários pontos de entrada de extensão do kernel.
    Além disso, a plataforma tinha APIs que permitiam que os apps se comunicassem entre si sem dificuldade.
    Mas a Apple foi se afastando aos poucos dessa filosofia e continua fechando o sistema. É uma jornada bem interessante.

  • SBPL (sandbox profile language) é interessante. Há mais detalhes aqui: https://github.com/0xbf00/simbple
    Fico me perguntando se existe em algum lugar dentro do macOS um interpretador Scheme para lidar com isso.
    PS: parece que quem faz esse trabalho é o sandbox-exec. Referência: https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sand...

  • Descoberta impressionante. Como o texto também sugere, parece muito provável que falhas semelhantes ainda estejam soltas por aí.
    Se a Apple não redesenhar a abordagem de reforço desses serviços, acho que veremos CVEs relacionados a XPC de forma contínua.

  • Gosto e ao mesmo tempo não gosto de sandboxes.
    São uma excelente segunda linha de defesa, mas grandes organizações tendem a se recusar a corrigir vulnerabilidades de execução remota de código se não for possível escapar do sandbox e fazer algo significativo. Então o sandbox acaba sendo usado como linha principal de defesa, e isso é triste.

    • Não sei de quem você está falando com “recusam-se a corrigir vulnerabilidades de execução remota de código se não for possível escapar do sandbox”.
      Pelo que sei, Apple, Microsoft e Google têm programas de bug bounty; elas pagam recompensas maiores por escapes de sandbox, mas também recompensam vulnerabilidades bloqueadas pelo sandbox.
      Todo mundo sabe muito bem que atacantes guardam vulnerabilidades de execução remota de código que hoje não conseguem usar e as combinam com um escape de sandbox quando um é descoberto.

  • Fugindo um pouco do tema, mas se houver alguém entre os especialistas em sandbox que conheça uma estratégia para contornar o limite de maximum "pattern serialization length", esse problema me deu bastante dor de cabeça por um bom tempo: https://github.com/NixOS/nix/issues/4119
    Infelizmente, sandbox-exec quase não tem documentação, e também há rumores de que será descontinuado, então resolver isso é bem complicado

  • No macOS, surgem desvios sem parar. Isso porque esse sistema operacional nunca foi projetado originalmente para esse tipo de permissões granulares
    Não dá para simplesmente colocar isso por cima de tecnologias legadas do Mac OS e do NeXTSTEP depois
    Não sou pesquisador de segurança, apenas um desenvolvedor de apps antigos, e mesmo assim encontrei vários desvios por conta própria. Por assim dizer, sei onde os corpos estão enterrados
    Mas, no fim, desisti de procurar. O sistema da Apple para reportar vulnerabilidades de segurança é uma bagunça completa, e parecia interessado apenas em manter todo mundo calado pelo maior tempo possível. É perda de tempo
    No geral, o macOS parece ter se tornado vítima de teatro de segurança. Prejudica usuários e desenvolvedores legítimos com software enfraquecido e solicitações intermináveis de permissão, enquanto atacantes reais conseguem contornar facilmente quando querem. Parece a antiga paródia da Apple sobre o Windows Vista

    • O pesquisador que escreveu este artigo parece ter conseguido fazer um bom número de brechas serem corrigidas, com os devidos créditos. Porém, alguns desses CVEs parecem ter anos de idade
      Faz parte do jogo uma empresa querer o máximo de tempo possível para corrigir bugs. Será que realmente queremos que outras empresas divulguem vulnerabilidades descobertas o mais rápido possível? Como não dá para controlar a rapidez com que os usuários vão fazer upgrade, atrasar a divulgação é sempre melhor para os usuários finais, e isso deve ter prioridade sobre o desejo de autopromoção do pesquisador
      A arquitetura de sandbox da Apple geralmente parece ser bem projetada. Neste caso, parece que houve algum problema em algum ponto da arquitetura ou da comunicação
      A existência de desvios também se deve ao fato de exigirmos recursos demais dos sistemas operacionais de desktop. Um sistema operacional de desktop pode ser visto como muito mais sofisticado e complexo do que uma plataforma de servidor. É pelo mesmo motivo que navegadores web têm muitos CVEs. Queremos segurança e também queremos recursos, então inevitavelmente surge um ponto intermediário em que os dois entram em conflito
    • Ao contrário da afirmação de que “não dá para simplesmente colocar isso por cima de tecnologias legadas do Mac OS e do NeXTSTEP depois”, a Apple é dona de toda a pilha, então ela pode fazer isso e de fato fez
      A prova disso é o reforço gradual do software e do hardware do macOS ao longo dos últimos 20 anos
      Para a maioria dos usuários finais, foi gradual a ponto de quase não perceberem, mas desenvolvedores macOS sabem muito bem dos problemas relacionados a segurança que precisam enfrentar tanto em atualizações principais quanto em menores. Por exemplo:
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/09/…
    • Esse tipo de peso legado parece existir em todos os sistemas operacionais mainstream
      Existem sistemas baseados em capabilities, mas nenhum que seja realmente usado de forma ampla
      Não sei bem qual é a solução. Ainda assim, tentar acrescentar segurança parece melhor do que não fazer nada e permitir que uma única vulnerabilidade de aplicação leve diretamente ao controle total da conta do usuário
    • Se “não dá para adicionar isso depois por cima do Mac OS legado”, o que impede fundamentalmente o MacOS, já que o SELinux conseguiu fazer isso?
    • O motivo dessas restrições é dificultar que desenvolvedores terceiros concorram com produtos da Apple

  • Serviços XPC esquecidos no domínio de pid são uma forma inteligente de contornar as restrições de sandbox do macOS
    O truque de injeção em dyld para evitar verificações de permissão também é elegante
    O patch da Apple aqui parece uma solução provisória, e talvez seja preciso corrigir de verdade a forma como a herança de sandbox funciona