Kernel Local Privilege Escalation "Dirty COW" - CVE-2016-5195
Red Hat Product Security descobriu uma vulnerabilidade no kernel do Linux que foi designada CVE-2016-5195. Este problema foi divulgado publicamente no dia 19 de outubro de 2016 e foi avaliado como importante. A mídia esta se referindo a este problema como "Dirty COW".
Informações Gerais
Uma condição de corrida foi encontrada na maneira em que o subsistema de memória do kernel do Linux manipula a quebra da cópia-na-escrita (COW) do mapeamento de memória privada somente de leitura. Um usuário local sem privilégios pode usar esta falha para ganhar permissão de escrita dos mapeamentos de memória que são somente de leitura e assim aumentar seus privilégios no sistema.
Isto pode ser aproveitado de forma abusiva por um invasor para modificar arquivos setuid existentes com instruções para elevar privilégios. Foi encontrada uma exploração da utilização desta técnica. Esta falha afeta a maior parte das distribuições modernas de Linux.
Red Hat Product Security avaliou esta atualização como um impacto de segurança importante.
Produtos Impactados
As seguintes versões dos produtos Red Hat estão impactadas:
- Red Hat Enterprise Linux 5
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 7
- Red Hat Enterprise MRG 2
- Red Hat Openshift Online v2
- Red Hat Virtualization (RHEV-H/RHV-H)
Descrição e impacto do ataque
Esta falha permite que um invasor com uma conta de sistema local modifique binários em disco, iludindo os mecanismos de permissões padrões que evitariam modificações sem as definições de permissões apropriadas. Isto é alcançado ao executar a chamada do sistema madvise(MADV_DONTNEED), enquanto a página de mmapped executável estiver em memória.
Diagnostique sua vulnerabilidade
Intervenções Necessárias
Todos os clientes da Red Hat executando as versões afetadas do kernel são altamente recomendados a atualizar o kernel assim que patches estiverem disponíveis. Detalhes sobre os pacotes que sofreram impacto, assim como mitigações recomendáveis, estão relatadas abaixo. É necessário reiniciar o sistema para que a atualização do kernel seja aplicada.
Atualizações para os Produtos Afetados
Um kpatch para clientes executando Red Hat Enterprise Linux 7.2 ou mais recente estará disponível. Por favor, abra um caso de suporte para ter acesso ao kpatch.
Para mais detalhes sobre o que é um kpatch:
RHEL 7 tem suporte patch de kernel ao vivo (kpatch)?
Produto | Pacote | Aviso/Atualização |
---|---|---|
Red Hat Enterprise Linux 7 | kernel | RHSA-2016:2098 |
Red Hat Enterprise Linux 7 | kernel-rt | RHSA-2016:2110 |
Red Hat Enterprise Linux 7.1 Extended Update Support* | kernel | RHSA-2016:2118 |
Red Hat Enterprise Linux 6 | kernel | RHSA-2016:2105 |
Red Hat Enterprise Linux 6.7 Extended Update Support* | kernel | RHSA-2016:2106 |
Red Hat Enterprise Linux 6.6 Extended Update Support* | kernel | RHSA-2016:2128 |
Red Hat Enterprise Linux 6.5 Advanced Update Support** | kernel | RHSA-2016:2120 |
Red Hat Enterprise Linux 6.4 Advanced Update Support** | kernel | RHSA-2016:2133 |
Red Hat Enterprise Linux 6.2 Advanced Update Support** | kernel | RHSA-2016:2132 |
Red Hat Enterprise Linux 5 | kernel | RHSA-2016:2124 |
Red Hat Enterprise Linux 5.9 Long Life | kernel | RHSA-2016:2126 |
Red Hat Enterprise Linux 5.6 Long Life | kernel | RHSA-2016:2127 |
RHEL Atomic Host | kernel | pendente |
Red Hat Enterprise MRG 2 | kernel-rt | RHSA-2016:2107 |
Red Hat Virtualization (RHEV-H/RHV-H) | kernel | pendente |
*Uma subscrição ativa EUS é exigida para acessar este patch.
Por favor, contate a equipe de vendas da Red Hat ou seu representante de vendas específico para mais informações caso sua conta não possua uma subscrição EUS ativa.
O que é uma subscrição Red Hat Enterprise Linux Extended Update?
**Uma subscrição AUS ativa é necessária para ter acesso a essa correção no RHEL 6.X AUS.
Mitigação
COMO CRIAR E UTILIZAR A SOLUÇÃO ALTERNATIVA SYSTEMTAP
A contramedida Systemtap envolve criar um módulo kernel (como um driver) utilizando um script systemtap que intercepta a chamada de sistema vulnerável. Ele é utilizado como uma solução provisória até que um kernel corrigido seja iniciado na máquina afetada. Esta solução não requer uma reinicialização e aplica-se ao RHEL 5, 6 e 7.
Não é possível criar um módulo que se aplique a todos os kernels. Nem mesmo para uma família (ex.: todos RHEL 5,6 ou 7). Cada versão específica de kernel requer um .ko gerado para aquele kernel particular (uname -r)
REQUISITOS
Para poder criar o módulo systemtap, são necessários os seguintes pacotes:
- systemtap-client
- systemtap-devel
- gcc (e dependências)
- kernel-devel-`uname -r`
- kernel-debuginfo-`uname -r`
- kernel-debuginfo-common-`uname -r`
ALERTA: Os pacotes de 'kernel' exigem a mesma versão do kernel em funcionamento. O download da versão mais recente não permitirá o funcionamento do systemtap. Por favor, faça o download da versão exata que está executando.
ONDE OBTER INFORMAÇÕES DE DEPURAÇÃO
Por favor, consulte a base de conhecimento https://access.redhat.com/solutions/9907
COMO CRIAR O MÓDULO
1. Depois de instalar os pacotes, crie um arquivo com o nome dirtycow.stp com o seguinte conteúdo:
probe kernel.function("mem_write").call ? { $count = 0 } probe syscall.ptrace { // includes compat ptrace as well $request = 0xfff } probe begin { printk(0, "CVE-2016-5195 mitigation loaded") } probe end { printk(0, "CVE-2016-5195 mitigation unloaded") }
2. Salve o arquivo. Para compilá-lo, utilize o seguinte comando:
# stap -g -p 4 -m dirtycow_`uname -r|tr -cd [:digit:]` dirtycow.stp dirtycow_26183985.ko
No exemplo acima, o arquivo .ko possui um número identificando a versão de seu kernel. Neste caso, é 2.6.18-398.el5. Este módulo pode ser utilizado em outros sistemas com esta exata versão de kernel, sem ter a necessidade de instalar o debugs/debuginfos/systemtap. Só é necessário copiar o arquivo para o servidor com o mesmo kernel e prosseguir à próxima etapa.
3. Para carregar o módulo, execute o comando insmod <.ko file>. Por exemplo:
# insmod dirtycow_26183985.ko
4. Verifique se está carregado:
# lsmod| grep dirty dirtycow_26183985 101688 0
5. Para descarregar o módulo utilize o comando rmmod ou reinicialize o sistema.
IMPORTANTE
- O módulo não sobrevive uma inicialização: não é recarregado após uma inicialização do sistema.
- Após uma reinicialização, o módulo deve ser carregado manualmente mais uma vez.
- Se o kernel for atualizado ou modificado, este módulo não será carregado em um novo kernel.
- Se você iniciou em um kernel diferente sem a correção, um novo módulo compatível deve ser carregado.
- Um kernel corrigido não precisa carregar o módulo.
Por favor, consulte erro 1384344 para etapas detalhadas de mitigação.
Comments