Exploração no 10.15 e 11.0 beta

O runtime Objective-C usado no macOS 10.15 não é vulnerável à técnica de exploração detalhada anteriormente, porque as categorias não são carregadas antes de didCallDyldNotifyRegister ser definido, fazendo com que nosso método +initialize seja chamado apenas após a inicialização da sandbox.

No entanto, map_images ainda é chamado em nosso binário, tornando possível alterar dados do runtime de maneiras não intencionais que nos permitiriam executar código antes da inicialização da sandbox. A exploração completa e comentada está em main.c, mas abordarei os detalhes básicos aqui. Criamos uma estrutura de classe Objective-C cujo ponteiro data aponta para um local em libxbc.dylib. Esse local deve ser escolhido de forma que flags tenha o bit 31 (RW_REALIZED) definido, para que o runtime não tente realizar esta classe inválida e trave, e firstSubclass deve compartilhar seu endereço com o isa de uma classe que queremos sobrescrever. Outra (meta) classe herdará desta classe inválida e fornecerá seu próprio método +initialize. Adicionamos a subclasse a __objc_nlclslist para que o runtime realize esta classe.

Quando o runtime realiza nossa subclasse, o que acontece antes da inicialização da sandbox, ele chamará addSubclass em nossa superclasse inválida e subclasse, o que substituirá o isa da vítima por um ponteiro para nossa subclasse, efetivamente substituindo todos os seus métodos pelo nosso +initialize. Quando nosso método +initialize é chamado, o que será antes da inicialização da sandbox se escolhermos uma classe vítima adequada, podemos novamente substituir referências a _libsecinit_initializer por nops (condicionalmente ou não) e corrigir as alterações no runtime que fizemos para retomar a execução sem travar posteriormente.

Demonstração Fornecida

A demonstração fornecida pode ser construída executando make, criando um arquivo em ~/Documents/SecretDocument.txt e executando SnatchBox.app/Contents/MacOS/SnatchBox a partir do terminal (um bundle é criado porque é exigido por com.apple.security.app-sandbox, mas ainda é um programa de linha de comando). O binário construído é assinado com com.apple.security.app-sandbox, o que normalmente impediria o acesso a ~/Documents/SecretDocument.txt (pois não está em nosso container), mas será capaz de ler seus dados mesmo assim. Devido a alterações na estrutura do runtime, esta demonstração não funcionará no macOS 10.14 e anteriores sem modificações, mas funcionará no 10.15 e 11.0 (Testado: 10.15.4, 10.15.7 e 11.0 Beta (20A5354i)). As duas técnicas de exploração podem ser combinadas para atingir ambas as versões do runtime, mas tal demonstração não é fornecida.

Exemplo de execução:

Impacto

Como mencionado anteriormente, isso permite criar um aplicativo da Mac App Store que não é executado em uma sandbox, apesar de ser obrigado a fazê-lo pela política da App Store. A vulnerabilidade também pode ser usada em um framework, que pode ser usado por aplicativos da App Store que de outra forma seriam legítimos. Por último, pode até ser combinado com algo semelhante a "Xcode Ghost" para injetar em massa código malicioso que é executado fora da sandbox em aplicativos da App Store.

Correção

A Apple corrigiu a exploração durante a fase de testes beta do macOS 11.0 adicionando uma chamada a malloc_size em realizeClassWithoutSwift. Isso confirma que, se uma classe está marcada como realizada (RW_REALIZED, como nossa classe falsa), ela realmente tem um ponteiro de dados válido, mallocado, com o tamanho correto (0x20 bytes). Se não for o caso, o runtime abortará com uma mensagem semelhante a realized class 0x100002078 has corrupt data pointer 0x7fff88c00948. A correção também foi aplicada ao iOS, iPadOS, tvOS e watchOS; mesmo que não sejam diretamente afetados.