xpc-string-leak

xpc-string-leak é uma prova de conceito de exploração para uma leitura de memória fora dos limites em libxpc. Este exploit usa a vulnerabilidade para ler memória heap fora dos limites do diagnosticd, um processo root sem sandbox com a permissão task_for_pid-allow.

A vulnerabilidade: CVE-2018-4248

No macOS 10.13.5 e iOS 11.4, a função _xpc_string_deserialize não verifica se a string desserializada tem o comprimento adequado antes de criar um objeto XPC string com _xpc_string_create. Isso pode levar a uma leitura de heap fora dos limites no estilo heartbleed se a string XPC for então serializada em outra mensagem XPC.

Aqui está a implementação de _xpc_string_deserialize, descompilada usando IDA:

OS_xpc_string *__fastcall _xpc_string_deserialize(OS_xpc_serializer *xserializer)
{
    OS_xpc_string *xstring; // rbx@1
    char *string; // rax@4
    char *contents; // [rsp+8h] [rbp-18h]@1
    size_t size; // [rsp+10h] [rbp-10h]@1 MAPDST

    xstring = 0LL;
    contents = 0LL;
    size = 0LL;
    if ( _xpc_string_get_wire_value(xserializer, (const char **)&contents, &size) )
    {
        if ( contents[size - 1] || (string = _xpc_try_strdup(contents)) == 0LL )
        {
            xstring = 0LL;
        }
        else
        {
            xstring = _xpc_string_create(string, size - 1);
            LOBYTE(xstring->flags) |= 1u;
        }
    }
    return xstring;
}

_xpc_string_deserialize primeiro chama _xpc_string_get_wire_value para obter um ponteiro para os dados da string, bem como o tamanho serializado da string, conforme relatado pelo cabeçalho da string. _xpc_string_deserialize então verifica se a string tem um terminador nulo no final do seu tamanho reportado, mas crucialmente não verifica se não há um terminador nulo antes nos dados. Finalmente, ele cria uma cópia da string no heap e cria o objeto OS_xpc_string usando _xpc_string_create.

Aqui está o código descompilado para _xpc_string_create:

OS_xpc_string *__fastcall _xpc_string_create(const char *string, size_t length)
{
    OS_xpc_string *xstring; // rax@1

    xstring = (OS_xpc_string *)_xpc_base_create(&OBJC_CLASS___OS_xpc_string, 16LL);
    if ( (((_DWORD)length + 4) & 0xFFFFFFFC) + 4 < length )
        _xpc_api_misuse("Unreasonably large string");
    xstring->wire_length = ((length + 4) & 0xFFFFFFFC) + 4;
    xstring->string = string;
    xstring->length = length;
    return xstring;
}

_xpc_string_create confia no valor do comprimento fornecido por _xpc_string_deserialize e define os campos apropriados no objeto OS_xpc_string. Neste ponto, a string desserializada pode ter um campo length maior do que os dados da string alocados.

Exploração

Teoricamente, isso poderia ser usado para desencadear corrupção de memória em serviços que obtêm o comprimento da string usando xpc_string_get_length, mas esse padrão parece ser incomum. Uma estratégia de exploração menos poderosa, mas mais prática, é fazer com que a string seja re-serializada e enviada de volta para nós, dando-nos uma janela no estilo heartbleed para a memória do processo vítima.

Esta é a implementação de _xpc_string_serialize:

void __fastcall _xpc_string_serialize(OS_xpc_string *string, OS_xpc_serializer *serializer)
{
    int type; // [rsp+8h] [rbp-18h]@1
    int size; // [rsp+Ch] [rbp-14h]@1

    type = *((_DWORD *)&OBJC_CLASS___OS_xpc_string + 10);
    _xpc_serializer_append(serializer, &type, 4uLL, 1, 0, 0);
    size = LODWORD(string->length) + 1;
    _xpc_serializer_append(serializer, &size, 4uLL, 1, 0, 0);
    _xpc_serializer_append(serializer, string->string, string->length + 1, 1, 0, 0);
}

O parâmetro length de OS_xpc_string é confiado durante a serialização, significando que muitos bytes são lidos do heap para a mensagem serializada. Se a string desserializada era mais curta que seu comprimento reportado, a mensagem será preenchida com dados de heap fora dos limites.

Ainda estamos limitados a explorar serviços XPC que refletem alguma parte da mensagem XPC de volta ao cliente, mas isso é muito mais comum. Por exemplo, no macOS e iOS, o diagnosticd é um candidato promissor que também é sem sandbox, root e tem privilégios task_for_pid. O diagnosticd é responsável por processar mensagens de diagnóstico (por exemplo, mensagens geradas por os_log) e transmiti-las para clientes interessados em receber essas mensagens. Ao nos registrar para receber nosso próprio fluxo de diagnóstico e depois enviar uma mensagem de diagnóstico com uma string mais curta do que o esperado, podemos obter um instantâneo de alguns dos dados no heap do diagnosticd, o que pode ajudar a obter execução de código no processo.

Uso

Para compilar, execute make. Veja o topo do Makefile para várias opções de compilação.

Execute o exploit especificando o tamanho do vazamento na linha de comando:

$ ./xpc-string-leak 0x40
0x2000000000000000 0xe00007ff39bf0992
0x00007fff56858570 0x00007fff7ed23d0e
0x0000000000000000 0x0000000000000000
0x00007fff7ed52be2 0x00007fff7ed29ed6

O tamanho do vazamento deve ser um múltiplo de 8 e no mínimo 16.

Licença

O código do xpc-string-leak é liberado em domínio público. Como cortesia, peço que se você referenciar ou usar qualquer parte deste código, atribua a mim.

Cronologia

Descobri esse bug no início de 2018 (janeiro ou fevereiro), mas esqueci de investigá-lo até maio. Reportei o problema à Apple em 9 de maio, e ele foi atribuído como CVE-2018-4248 e corrigido no iOS 11.4.1 e no macOS 10.13.6 em 9 de julho.

Brandon Azad