ASA-2019-00063 – rdesktop: Integer underflow que leva a um heap-based buffer overflow na função rdpsnddbg_process()


For the English version of this alert, click here.

Allele Security Alert

ASA-2019-00063

Identificador(es)

ASA-2019-00063, CVE-2018-20180

Título

Integer underflow que leva a um heap-based buffer overflow na função rdpsnddbg_process()

Fabricante(s)

rdesktop team

Produto(s)

rdesktop

Versão(ões) afetada(s)

rdesktop versões até e incluindo v1.8.3

Versão(ões) corrigida(s)

rdesktop v1.8.4

Prova de conceito

Desconhecida

Descrição

As versões do rdesktop até e inclusive a v1.8.3 contêm um integer underflow que leva a um heap-based buffer overflow na função rdpsnddbg_process() e resulta em uma corrupção de memória e, provavelmente, até mesmo uma execução remota de código.

Detalhes técnicos

Em todo o código do cliente, há uma suposição de que o servidor enviou bytes suficientes para o cliente processar. Um exemplo para essa suposição pode ser encontrado no seguinte trecho de código abaixo:

void
channel_process(STREAM s, uint16 mcs_channel)
{
    uint32 length, flags;
    uint32 thislength;
    VCHANNEL *channel = NULL;
    unsigned int i;
    STREAM in;
    ...
    in_uint32_le(s,length)
    in_uint32_le(s,flags)
    if((flags & CHANNEL_FLAG_FIRST) && (flags & CHANNEL_FLAG_LAST))
    {
        /* single fragment - pass straight up */
        channel->process(s);
    }
}

Analisando 2 campos do stream “s” sem primeiro verificar seu tamanho

Como podemos ver, os campos “length” e “flags” são analisados a partir do stream “s”, sem verificar se “s” realmente contém os 8 bytes necessários para essa operação de análise. Embora isso geralmente leve a um out-of-bounds read, podemos combinar essa vulnerabilidade com uma vulnerabilidade adicional em vários canais internos e obter um efeito muito mais grave.

Existem três canais lógicos que compartilham uma vulnerabilidade comum:

lspci
rdpsnddbg – sim, esse canal de depuração está sempre ativo
desatado

A vulnerabilidade em si pode ser vista abaixo:

/* process new data from virtual channel */
static void(STREAM *s)
{
    unsigned int pkglen;
    static char *rest = NULL;
    char *buf;

    pkglen = s->end - s->p;
    /* str_handle_lines requires null terminated strings */
    // EI-DBG: In case we over-read here, we can do the following: 
    // EI-DBG: 1. buf = xmalloc(0);
    // EI-DBG: 2. STRNCPY(buf, s->p,0)
    // EI-DBG:  a) strncpy(buf, s->p, -1)
    // EI-DBG:  b) buf[-1] = '\0'
    // EI-DBG: And s->p can be controlled using data from the previous packet
    buf = xmalloc(pkglen + 1);
    STRNCPY(buf,(char *)s->p,pkglen + 1);
    ...

    str_handle_lines(buf,&rest,lspci_process_line,NULL);
    xfree(buf)
}

Integer underflow ao calcular o “pkglen” restante

Ao ler muitos dados do stream, ou seja, enviar um pacote picado para o cliente, a invariante que “s->p <= s->end” se rompe. Isto leva a um integer underflow ao calcular “pkglen”, e a um integer overflow adicional ao alocar bytes “xmalloc(pkglen + 1)” para nosso buffer, como pode ser visto no meu comentário acima da chamada para “xmalloc”.

Juntamente com a implementação proprietária de “STRNCPY”, vista abaixo, podemos acionar um heap-based buffer overflow massivo ao copiar dados para o pequeno buffer de heap alocado.

#define STRNCPY(dst,src,n) {strncpy(dst,src,n-1); dst[n-1] = 0;}

Implementação proprietária da função “strncpy”

Encadeando essas duas vulnerabilidades, encontradas em três canais lógicos diferentes, agora temos três vulnerabilidades de execução remota de código.

Créditos

Eyal Itkin (Checkpoint Research)

Referência(s)

Reverse RDP Attack: Code Execution on RDP Clients
https://research.checkpoint.com/reverse-rdp-attack-code-execution-on-rdp-clients/

Updated ChangeLog and bumped version to 1.8.4
https://github.com/rdesktop/rdesktop/commit/34b8a18fe5d4de795851defe34b3ad3e1f43532b

CVE-2018-20180
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20180

CVE-2018-20180
https://nvd.nist.gov/vuln/detail/CVE-2018-20180

Se encontrou algum erro neste alerta ou deseja uma análise compreensiva, entre em contato.

Última modificação: 11 fevereiro 2019

Não somos responsáveis por qualquer perda de dados, corrupção de dispositivos ou qualquer outro tipo de problema devido ao uso de qualquer informação mencionada em nossos alertas de segurança.