MSMQ QueueJumper (vulnerabilidade de RCE): uma análise técnica aprofundada.

As atualizações de segurança lançadas pela Microsoft em 11 de abril de 2023 corrigiram mais de 90 vulnerabilidades individuais. Entre elas, destacou-se a CVE-2023-21554, conhecida como QueueJumper, uma vulnerabilidade de execução remota de código que afeta o serviço Microsoft Message Queueing (MSMQ). O MSMQ é um componente opcional do Windows que permite que aplicações troquem mensagens por meio de filas acessíveis tanto localmente quanto remotamente. Esta análise foi realizada em colaboração com as equipes Randori e X-Force Adversary Services, por Valentina Palmiotti, Fabius Watson e Aaron Portnoy.

As seguintes características da CVE-2023-21554 chamaram atenção inicial:

• Devido ao uso variado de filas MSMQ por aplicações de terceiros, existem desafios para identificar toda a extensão do impacto da vulnerabilidade entre diferentes ambientes.
• Relatórios iniciais descreviam 360.000 hosts acessíveis pela Internet com o serviço MSMQ exposto. Consultas ao Shodan, na época, exibiam apenas 250. Essa discrepância tornava ainda menos claro o grau real de exposição.
• A vulnerabilidade é classificada como execução remota de código (RCE) que não requer autenticação e afeta uma ampla gama de plataformas Windows.
• O único requisito aparente é que o serviço esteja acessível na porta TCP 1801.

Para determinar como detectar a presença do MSMQ, um sistema de teste foi configurado com o componente em um ambiente de laboratório. Ao se conectar ao endpoint MSMQ na porta 1801, o servidor não respondeu com nenhum dado. Pode-se presumir que o servidor não responderá sem receber dados razoavelmente formados. Para entender como conduzir uma conversa com o endpoint, foi necessária uma inspeção mais aprofundada do código subjacente.

No aviso, não está imediatamente claro qual binário foi corrigido. O primeiro passo para identificar o código alterado foi baixar o arquivo de atualização. Isso foi alcançado pesquisando por KB5025224 no catálogo do Microsoft Update.

Resultados da pesquisa do Microsoft Update Catalog para KB5025224

Especificamente, o arquivo de atualização cumulativa 

windows10.0-kb5025224-x64_3522b1b562ed44bc949541dd1c7d08e1e967d925.msu 

para Windows 11 para sistemas baseados em x86 foi recuperado.

O extrator 7-Zip foi usado para descompactar o conteúdo do arquivo MSU e os arquivos CAB que ele continha. A pesquisa pela string "msmq" em todos os arquivos nas pastas resultantes resultou no arquivo de índice do contêiner, 

Windows11.0-KB5025239-x64/express.psf.cix.xml,

que incluía a seguinte entrada:

<File id="21296" name="amd64_microsoft-windows-msmq-queuemanager-core_31bf3856ad364e35_10.0.22621.1555_none_5f975f8fdb349517\f\mqqm.dll" length="34811" time="133245266510000000" attr="128">

Esta entrada faz referência a MQQM.dll  , que foi identificado como alvo para análises adicionais.

Para identificar as alterações feitas entre as versões corrigida e não corrigida do arquivo MQQM.dll , foi usada a ferramenta BinDiff da Zynamics. A imagem a seguir mostra as funções correspondentes com uma pontuação de similaridade inferior a1.00 :

Resultados do BinDiff entre arquivos MQQM.data corrigidos e não corrigidos 

Uma análise dessas funções usando o Hex-Rays Decompiler revelou símbolos para a versão corrigida que contém nomes de funções detalhados que parecem fazer referência a identificadores de vulnerabilidade do Microsoft Security Research Center (MSRC):

Símbolos de funcionalidade dentro do MQQM.dll

Após uma inspeção mais detalhada, observou-se que os símbolos contendo números de casos do MSRC correspondiam a  sinalizadores de funcionalidade  usados para aplicar correções de vulnerabilidades. Os sinalizadores de funcionalidade são um componente do Windows que permite ativar ou desativar determinados comportamentos, funcionalidades ou experimentos. Neste caso, a “funcionalidade” identificada é, na verdade, um patch para uma vulnerabilidade.

Trecho de código descompilado mostrando o sinalizador de funcionalidade para correções de vulnerabilidade

Um mecanismo de verificação por sinalizador de funcionalidade estava presente para cada uma das vulnerabilidades que compunham a CVE-2023-21554, tanto nos componentes de usuário quanto nos componentes de kernel. A análise dos demais binários incluídos no pacote de atualização de segurança revelou que sinalizadores de funcionalidade também foram introduzidos para a maioria, ou possivelmente todas, as vulnerabilidades corrigidas no Patch Tuesday de abril de 2023.

Ao cruzar esses sinalizadores, conseguimos identificar rapidamente os pontos do código que foram corrigidos. Em particular, as alterações no CQmPacket::CQmPacket relacionadas ao sinalizadorMSRC76146_MSMQ_OOBRWF ixes pareceram ser a de maior interesse.

A verificação desse sinalizador de funcionalidade ocorre oito vezes dentro da função. Uma dessas verificações é mostrada abaixo:

Trecho de código descompilado mostrando a correção de vulnerabilidade 

No trecho de código descompilado mostrado acima, o caminho de código corrigido obtém o ponteiro para a próxima seção da mensagem MSMQ via uma chamada para GetNextSectionPtrSafe. No caminho não corrigido, o ponteiro é obtido simplesmente adicionando o tamanho da seção sem verificações. A nova funçãoGetNextSectionPtrSafe verifica se o ponteiro calculado para a próxima seção do pacote não excede o comprimento do próprio pacote.

Trecho de descompilação da função GetNextSectionPtrSafe

Depois de examinar todas as ocorrências desse sinalizador de funcionalidade e de outros, foi determinado que o CVE-2023-21554 consiste em vários bugs que verificam de forma insuficiente o tamanho de vários tipos de seção de mensagens MSMQ. Essas vulnerabilidades permitem que o ponteiro para o final da mensagem MSMQ seja incrementado por um deslocamento arbitrário de 32 bits para fora dos limites do buffer originalmente alocado.

Após o processamento do pacote, a etapa final em CQmPacket::CQmPacket anexará um OnDiskExtensionHeader até o final do buffer do pacote. Devido às vulnerabilidades mencionadas anteriormente, é possível que o ponteiro calculado para o final da mensagem ultrapasse os limites. Assim, a inclusão do cabeçalho OnDiskExtensionHeader pode resultar em diversas gravações fora dos limites. O código descompilado abaixo mostra uma verificação corrigida para o ponteiro final da mensagem vulnerável antes que as gravações fora dos limites (OOB) ocorram:

Verificação de acesso a memória fora dos limites para o fim da mensagem

Durante a avaliação da explorabilidade das vulnerabilidades, foram identificadas vulnerabilidades adicionais no kernel no driver correspondente ao serviço MSMQ, mqac.sys. As vulnerabilidades foram novamente indicadas pelos símbolos do sinalizador de funcionalidade, que também fazem referência ao caso MSRC 76146, conforme observado em MQQM.dll .

Sinalizadores de funcionalidade dentro de mqac.sys

A análise do sinalizador de funcionalidadeKernelVariants revelou que as vulnerabilidades correspondentes são análogas às encontradas no componente de espaço do usuário. O componente do kernelmqac.sys  está envolvido em várias operações para o serviço MSMQ, como o encaminhamento de mensagens para filas de mensagens não entregues, o envio de mensagens de confirmação e o gerenciamento de memória para buffers de pacotes MSMQ.

Para executar essas operações, o componente de kernel analisa diferentes seções do buffer de pacotes MSMQ. Duas dessas instâncias são retratadas abaixo:

Trecho de código descompilado mostrando o sinalizador de funcionalidade para a correção da vulnerabilidade no driver de kernel mqac.sys

Como pode ser visto no trecho de código descompilado acima, se o sinalizador de funcionalidade estiver habilitado, as funções “seguras” CPacketBuffer::MsgDeadletterHeaderSafe  e CPacketBuffer::MsgOnDiskExtensionHeaderSafe  são chamadas para recuperar os cabeçalhos correspondentes do buffer do pacote. Se não estiver habilitado, são chamadas as funções "inseguras", que não possuem verificações suficientes sobre o tamanho da seção.

A maior parte do código relacionado à análise de protocolo está localizada dentro da biblioteca MQQM.dll , que é carregada pelo processomqsvc.exe . Para acessar o código referenciado por MSRC76146_MSMQ_OOBRWFixes , uma solicitação MSMQ válida deve ser enviada pelo cliente. A especificação e o protocolo de mensagens do MSMQ são vastos e complexos. Inicialmente, foi encontrado um código público para escanear servidores MSMQ em um gist do GitHub, o que forneceu a base para uma exploração mais aprofundada do processamento de pacotes. Além disso, a documentação da Microsoft foi útil para compreender o formato das mensagens do MSMQ.

O código dentro da DLL recebe dados pela porta 1801 por meio de uma chamada à função WSARecv, como pode ser visto na sessão de depuração abaixo:

0:020> bp ws2_32!wsarecv ; g

Breakpoint 0 hit

WS2_32!WSARecv:

00007ffd`651115c0 48895c2408      mov     qword ptr [rsp+8],rbx ss:000000aa`f07fef30=0000000000000006

0:019> k

# Child-SP          RetAddr               Call Site

00 000000aa`f07fef28 00007ffd`57ba9cb0     WS2_32!WSARecv

01 000000aa`f07fef30 00007ffd`57b9683d    

MQQM!NoReceivePartialBuffer+0x38

02 000000aa`f07fefb0 00007ffd`57b2078e     MQQM!CWinsockConnection::ReceivePartialBuffer+0x7d

03 000000aa`f07ff010 00007ffd`57b25b28    

MQQM!CSockTransport::BeginReceive+0xe6

04 000000aa`f07ff060 00007ffd`57b2d40b    

MQQM!CSockTransport::NewSession+0x194

05 000000aa`f07ff3f0 00007ffd`57b2d367     MQQM!CSessionMgr::AcceptSockSession+0x6f

06 000000aa`f07ff430 00007ffd`645e26bd     MQQM!AcceptIPThread+0x6a7

07 000000aa`f07ff7d0 00007ffd`6650a9f8    

KERNEL32!BaseThreadInitThunk+0x1d

08 000000aa`f07ff800 00000000`00000000     ntdll!RtlUserThreadStart+0x28

0:019> r @$t0=@rdx

0:019> pt

WS2_32!WSARecv+0x19f:

00007ffd`6511175f c3              ret

0:019> dc poi(@$t0+8) LC

000001b5`880ff490  62f06110 524f494c 00000070 5a5a5a5a  .a.bLIORp…ZZZZ

000001b5`880ff4a0  0073006e 00610074 0063006e 00200065  n.s.t.a.n.c.e. .

000001b5`880ff4b0  00440049 00000000 00000000 00000000  I.D………….

0:019> ba r1 poi(@$t0+8) ; g

Breakpoint 1 hit

MQQM!CBaseHeader::SectionIsValid+0x154:

00007ffd`57b53450 7462            je     

MQQM!CBaseHeader::SectionIsValid+0x1b8 (00007ffd`57b534b4) [br=1]
 

A função CBaseHeader::SectionIsValid é responsável por analisar o início de uma nova mensagem, que começa com uma estrutura BaseHeader no formato:

Estrutura do objeto BaseHeader

Os campos de mensagem recebida são validados por SectionIsValid antes de o servidor enviar uma resposta:

Código de disassembly para SectionIsValid within MQQM.dll 

Após a validação inicial, a maior parte da análise do protocolo ocorre dentro da função construtoraCQmPacket:: CQmPacket . Para acionar uma vulnerabilidade CVE-2023-21554, uma mensagem MSMQ pode ser enviada contendo um cabeçalho de seção malformado que é tratado incorretamente. O exemplo a seguir detalha como acionar uma vulnerabilidade usando um EodHeader para uma seção Eod (entrega exatamente uma vez).

Descompilação mostrando vulnerabilidade no manuseio do EodHeader

A descompilação acima mostra o caminho corrigido chamando a função denominadaCEodHeader::GetNextSectionSafe. T o caminho sem patch simplesmente realiza uma adição de ponteiros, usando valores dentro do cabeçalho, para calcular o início da próxima seção.

A estrutura de umEodHeader  não está documentada; o bit de sinalização que indica a presença de umEodHeader noUserHeader é especificado como “reservado” na documentação da Microsoft, que afirma que o bit de sinalização não deve ser definido quando enviado. Observar o disassembly pode fornecer um insight sobre a estrutura do cabeçalho:

Disassembly calculando o tamanho total da seção EodHeader

Na desmontagem acima, o ponteiro para o início do EodHeader é carregado no registro rdx  . Pode-se especular que o primeiro e o segundo campos do cabeçalho descrevem tamanhos inteiros (tamanho do cabeçalho e tamanho dos dados, ou algo semelhante). Os dois tamanhos mais 0xF indicam o tamanho total da seção Eod em bytes. Ao enviar uma mensagem com um EodHeader cujos campos de tamanho correspondentes são definidos como valores grandes, uma gravação fora dos limites é acionada. Isso causa uma violação de acesso quando o OnDiskExtensionHeader está escrito até o que é (o programa pensa ser) o final da mensagem:

WinDbg session showing an access violation when writing to the end of a malformed MSMQ message

Para avaliar a robustez da escrita OOB obtida pelas vulnerabilidades, primeiro investigamos a alocação e o gerenciamento da memória subjacente.

Antes de um pacote de mensagemMSMQ ser processado, seu conteúdo é copiado para um buffer alocado na função QmAcAllocatePacket . Essa função chama o driver do kernel mqac.sys viaNtDeviceIoControl.

Descompilação da função de alocação do buffer de pacote

O componente do kernel retorna um buffer que é particionado a partir de uma visão mapeada de um arquivo no disco, armazenado no diretórioC:\Windows\System32\msmq\storage com uma extensão.mq  . Cada arquivo pode armazenar até 4 MB e pode conter mensagens de múltiplas filas.

Layout de memória do processo MQSVC no ProcessHacker mostrando que o buffer de pacote é um mapeamento de arquivo

O endereço do buffer de pacote, juntamente com um handle de pacote randomizado, é retornado ao espaço de usuário após a solicitação de alocação via IOCTL. O driver utiliza esse identificador para calcular o endereço do buffer de pacote ao lidar com requisições vindas do modo usuário.

A memória subjacente aos buffers vulneráveis está dentro de um arquivo mapeado, não em um heap do processo. Além disso, a memória afetada não armazena quaisquer objetos. O único conteúdo presente no mapeamento de arquivo são as mensagens MSMQ e os metadados armazenados em OnDiskExtension.

Além disso, sem conhecimento prévio do layout de memória, não é possível saber a posição relativa desse mapeamento em relação ao heap do processo para que seja possível sobrescrever ponteiros de objetos. Portanto, para que a execução remota de código seja viável, é necessário algum método para moldar a memória em uma posição previsível.

Após experimentar o envio de mensagens MSMQ legítimas para o destino, descobriu-se que é possível forçar uma nova alocação de heap adjacente a um mapeamento de arquivo .mq por meio do envio de várias mensagens. As mensagens são escritas sequencialmente na memória à medida que são recebidas, e usando a propriedade de mensagem do MSMQ TimeToBeReceived , a liberação de mensagens específicas pode ser cuidadosamente programada.

Layout de memória do processo MQSVC mostrando um novo heap alocado adjacente a um mapeamento de arquivo MQ

No entanto, isso exige que o invasor tenha acesso para enviar mensagens para pelo menos uma fila no destino; caso contrário, as mensagens serão descartadas e substituídas e, portanto, não ocuparão a memória dos pacotes de forma persistente.

Na experimentação de pesquisa realizada, descobriu-se que é possível para um usuário sem privilégios criar uma fila aberta para qualquer pessoa enviar mensagens remotamente, por padrão. A fila persiste no sistema indefinidamente. Embora a maioria dos usos modernos do MSMQ exista como componentes e adaptadores opcionais, fornecedores como Oracle, Veritas e Xerox oferecem softwares corporativos que dependem do MSMQ como uma dependência central. Portanto, o cenário de ataque não é irrealista.

A vulnerabilidade de acesso à memória fora dos limites introduz uma primitiva de exploração que permite que um
cliente malicioso para screva umOnDiskExtensionHeader além dos limites da memória
alocados para o pacote.

Ao avaliar uma vulnerabilidade que permite escrever valores em um deslocamento, algumas propriedades
devem ser consideradas:

• A compensação pode ser controlada
• Os valores escritos podem ser controlados

No caso das vulnerabilidades do QueueJumper, o deslocamento do buffer alocado para a escrita OOB é controlável porque é calculado usando dados controlados pelo invasor. O conteúdo da escrita OOB, no entanto, tem controle limitado.

Aqui,Address representa o ponteiro corrompido para o final da mensagem do pacote, onde o cabeçalho OnDiskExtension será gravado. A sequência de operações que ocorrem é a seguinte:

• O valor 0x000000000000000C é gravadoAddress
• O valor0x00000000 é gravado em Address+0x2
• O valor0x0000000000000000 é gravado em Address+0x12
• O valor 0x0000000000000000 é gravado em Address+0x1A
• O valor 0x00000094 é gravado em Address+0xE
• O valor0x0000 é gravadoAddress+0x22
• O valor 0x0000 é gravado em Address+0x62
• memcpy(Address+0xA6, Source, Source->AddressLength+0x08)

OSource usado na chamada para omemcpy acima se refere a um objeto TA_ADDRESS . A estrutura TA_ADDRESS define um único endereço de transporte de um tipo específico (por exemplo, NetBIOS). A definição é a seguinte:

typedef struct _TA_ADDRESS {

    USHORT AddressLength;;

    USHORT AddressType; Info;

    UCHAR Address[1];;

} TA_ADDRESS, *PTA_ADDRESS;

AddressLength

Especifica o número de bytes em um endereço do AddressType especificado.

AddressType

Especifica o tipo de endereço de transporte.

Address

Especifica uma matriz de tamanho variável contendo o endereço de transporte.

Em uma sessão de depuração abaixo,TA_ADDRESS contém dados influenciados pelo invasor na forma de um endereço IP:

rax=0000014e1d110180 rbx=0000014e1d110180 rcx=0000014e1d110184

rdx=0000014e1ce86b10 rsi=0000014e1d110001 rdi=0000000545d7fa50

rip=00007ff843208074 rsp=0000000545d7f940 rbp=0000000545d7f980

r8=000000000000000c  r9=0000000000000002 r10=0000000000000000

r11=0000000545d7f938 r12=0000000000000002 r13=0000000000001000

r14=0000014e1ce86b10 r15=0000000000000000

iopl=0         nv up ei pl nz na po nc

cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206

MQQM!CQmPacket::CQmPacket+0x89c:

00007ff8`43208074 e8a5780a00      call    MQQM!memcpy (00007ff8`432af91e)

0:017> dc rcx

0000014e`1d110184  00010004 00000000 8620a8c0 00000000  ………. …..
 

Acima, o objetoTA_ADDRESS tem o comprimento de 4 , um tipo de1 e um valor de 0x8620a8c0 . A conversão de cada byte em um octeto IPv4 resulta no endereço 192.168.32.134 , que é o endereço de origem IPv4 do cliente.

Esse cenário permite a escrita de dados controlados pelo atacante por meio de um endereço de origem para um deslocamento controlado a partir da alocação do pacote na memória. Embora extremamente restritivo e possivelmente inviável na prática, isso poderia, teoricamente, ser usado para controlar com precisão os valores escritos na memória ao fazer múltiplas requisições a partir de endereços de origem variados, usando deslocamentos de pacote decrementais.

Devido ao número de limitações encontradas para alcançar a execução remota de código, cenários de ataque alternativos, como vazamentos de informações, foram investigados.

Um ataque que foi considerado estava corrompendo o ponteiro para uma seção de mensagem específica para apontar para a memória fora dos limites e, mais tarde, recuperar a mensagem para ler a memória adjacente.

No entanto, o início de cada análise de seção faz uma verificação da posição da seção atual, portanto, não podemos enganar a lógica de análise para analisar uma seção de dados que está fora dos limites.

Outro cenário de ataque possível é substituir o OnDiskExtensionHeader de outra mensagem para enganar o destinatário da mensagem sobre as origens da mensagem recebida. Da mesma forma, é possível substituir o conteúdo das mensagens destinadas a filas às quais o invasor não tem acesso. Sobrescrever conteúdos específicos de uma mensagem exigiria que o atacante tivesse informações sobre a mensagem, como seu tamanho.

Há uma seção opcional chamada SoapHeader que é suscetível ao acesso a dados fora dos limites, com o seguinte formato:

Formato do pacote SoapHeader

Observou-se que a memória usada para armazenar dados de pacotes MSMQ não é devidamente limpa quando o buffer é liberado. Como resultado, o envio de um pacote MSMQ que é menor em tamanho do que um pacote MSMQ anterior resultará em um layout de memória contendo os dados do pacote atual seguidos por dados de pacotes MSMQ processados anteriormente.

Descobriu-se que o SoapHeader poderia ser usado para abusar dessa característica a fim de divulgar dados de pacotes processados anteriormente ou mensagens armazenadas adjacentes. Um invasor pode definir arbitrariamente o BodyDataLength e excluir completamente a seção Corpo. Isso resultará em uma mensagem MSMQ que inclui dados potencialmente sensíveis de pacotes MSMQ processados anteriormente como o Body do SoapHeader do invasor. O caminho de código corrigido impede esse caso de abuso, pois valida que os dados Body estão dentro dos limites dos dados do pacote MSMQ.

O controle limitado no conteúdo de escrita, com escritas não controladas adicionais corrompendo a memória adjacente, juntamente com o conhecimento limitado no layout da mensagem, provaram ser um grande obstáculo na invasão.

No momento da análise, apenas as vulnerabilidades do espaço do usuário envolvidas no processamento inicial de um pacote de mensagem MSMQ foram avaliadas quanto à sua explorabilidade. A análise das vulnerabilidades da variante do kernel pode descobrir caminhos adicionais de invasão. Por exemplo, é possível que a inclusão de um cabeçalho malformado ganhe uma primitiva de gravação no mapeamento de memória do kernel do arquivo .mq . Em alguns casos, as verificações no processamento do espaço do usuário impedem que o kernel execute algumas operações de pós-processamento.

Além disso, no caso das variantes do kernel, o invasor tem menos controle direto sobre o conteúdo das mensagens e também está operando no mesmo mapeamento de arquivos que o espaço do usuário, não em um pool de kernel (heap). Mitigações, como KASLR, também apresentam obstáculos que são difíceis de superar para invasão remota.

Devido à implementação do código corrigido, um cliente remoto pode determinar com segurança se um sistema aplicou a atualização. Isso pode ser feito enviando uma mensagem MSMQ que aciona a vulnerabilidade, mas que não causa de fato um acesso fora dos limites, evitando assim a falha do processo do serviço. Se o sinalizador HTTP estiver definido no UserHeader da mensagem, espera-se um SRMPEnvelopeHeader . Na correção, é realizada uma verificação de estouro de inteiro no campo DataLength multiplicado por 2. Esse comprimento pode ser definido de forma que o resultado da multiplicação ultrapasse um número pequeno, igual ao tamanho real dos dados.

Trecho de código decompilado mostrando a verificação de estouro de número inteiro em SRMPEnvelocaHeader DataLength

Se o destino for corrigido, a vulnerabilidade fará com que uma exceção seja lançada e o servidor interromperá o processamento da mensagem, portanto, nenhuma resposta será enviada de volta ao cliente. Se não estiver corrigido, o servidor processará a mensagem normalmente e enviará uma resposta.

Devido à localização da memória que dão suporte aos buffers vulneráveis, a execução remota de código parece mais viável para um invasor com a capacidade de enviar mensagens para qualquer fila no alvo. Nesse cenário, é possível realizar o grooming de forma que um heap adjacente seja alocado. O controle extremamente limitado sobre o conteúdo de gravação apresenta desafios para a invasão remota. Devido a medidas de mitigação como o ASLR, também é necessário obter um vazamento de informações. É possível que uma única escrita de uma constante (0xC, 0x0 – obtida com a primitiva) para um objeto poderia alcançar isso, no entanto, o objeto deve conter um campo útil onde os campos adjacentes possam resistir à corrupção de outras gravações. Além disso, o objeto deve ser alocado de forma previsível pelo invasor, o tempo de vida do objeto deve abranger a duração da invasão e alguma ação do objeto deve ser acionada pelo invasor. No decorrer desta pesquisa, nenhum objeto adequado foi descoberto.

Em última análise, concluímos que, embora a exploração remota do QueueJumper não seja necessariamente impossível, os requisitos mencionados tornam sua realização extremamente difícil. Este artigo apenas arranha a superfície do que constitui uma especificação de mensagem, um serviço e um protocolo altamente complexos. Pesquisas adicionais de vulnerabilidades, tanto no componente de user space quanto no componente de kernel, são justificadas.