<h1>Segurança do MaraDNS</h1> <i>Para pessoas que apenas querem rapidamente se atualizar sobre o histórico de segurança do MaraDNS podem pular para <A href=#history>seção histórica</A>.</i><p> MaraDNS deverá ser um servidor de DNS seguro. <p> A razão por que eu digo <em>deverá ser </em> em vez de "é", é porque eu acho reivindicações de segurança muito pretensiosos. Não há nenhum modo que eu posso garantia que um pedaço de código tão complexo quanto um servidor recursivo de DNS esteja completamente livre de bugs de segurança. <p> Porém, o que eu posso garantir é aqueles bugs são muito improváveis no MaraDNS, já que o projeto tem conferências de segurança e equilíbrio, o que minimiza a chance de haver perigo de segurança no código. <H2>Porque o código é inseguro?</H2> A razão principal por que um código é inseguro é porque o código em questão tem resultados indefinidos quando alimentado com dados que estão em uma forma diferente do que autor do código esperou. O caso mais simples disto é o <em>buffer overflow</em>, onde um programa é alimentado por uma string mais longa que o programa foi projetado para controlar. <p> Outro exemplo é o bug "cache poison" que versões antigas de outros DNS tiveram implementados. Com este bug, era uma questão trivial por exemplo, para dizer ao servidor DNS que www.yahoo.com tinha um endereço de ip de digamos, 10.69.69.69, o qual realmente apontava para algum desprezível sitel que instalava spyware. Por que este bug existiu? Porque os autores originais deste servidor não esperaram que servidores remotos deliberadamente distribuisem endereços IP incorretos. <h2>Como MaraDNS evita esses problemas?</h2> Em primeiro lugar, MaraDNS usa uma biblioteca de string especial para a qual é resistente buffer overflows. Faz-se isto tendo um tamanho máximo permitido para uma string --qualquer tentativa em fazer uma string maior que o tamanho máximo permitido, causa a biblioteca de string retornar um erro em vez de sobregaregar um buffer. Além disso, a biblioteca de string aloca uns três bytes extras para cada objeto de string, como uma almofada contra possíveis condições de limite, (havia um caso com outro programa que strived para estar seguro onde um byte buffer overflow resultou em um exploit de root remoto). <p> Segundo, MaraDNS se protege do cache poisoning sem descartar registros de cola e é controlando out-of-bailiwick registros diferentemente, dependendo em onde os registros ofendendo são. As atuais regras são bastante complexas, e detalhadas em um documento chamado "<A href= http://www.maradns.org/cache_poison_protection.html>cache.poison.protection</A>". <p> Terceiro, eu tenho extensivamente lido as <A href=http://cr.yp.to/djbdns.html>notas </A> de Dan Bernstein sobre implementação de DNS antes de realizar o MaraDNS. Duas idéias para implementar segurança no DNS discutida nas páginas de Dan's foram implementadas em MaraDNS: <UL> <LI> Quando um servidor recursivo estiver executando consultas, MaraDNS usa um gerador seguro de números pseudo aleatórios para gerar o ID da consulta, e os mais baixos 12 bits da fonte da porta da consulta. Isto significa que uma determinada tentativa de spoof a uma resposta para MaraDNS tem menos que um 1 entre 250 milhões chance de ter sucesso. <LI> MaraDNS usa uma fila FIFO para apagar registros não usados quando o cache começa a encher. O algoritmo é simples: Toda vez que um registro é acessado, é colocado ao topo da lista. Quando memória enche, MaraDNS apaga registros do começo da lista. Isto permite MaraDNS agir de uma maneira muito graciosa quando o cache começa a encher. </UL> Alguns problemas de segurança conhecidos são evitados: MaraDNS não usa printf() em uma maneira que tornaria a formatação da string possívilmente vulneravel; MaraDNS não usa qualquer função global potencialmente perigosa; e MaraDNS não terá os manipuladores notáveis até que eu posso entender um modo para fazer seguramente que o servidor de DNS não seja vulnerável às armadilhas de segurança conhecidas de construção de manipulador notável pobre. <p> Eu analiso o código, e quando eu acho qualquer coisa que tenha a possibilidade de permitir os dados de estarem num estado indefinido, eu reviso o código em questão. Por exemplo, quando eu estava analisando o código no release 0.8.35 do MaraDNS; eu achei um caso onde os dados puderiam potencialmente ficar indefinido. Em detalhe, se certas string não pudessem ser alocadas ou copiadas uma sobre as outras --casos que nunca podem acontecer-- o código que remove elementos do cache tentaria free () liberar memória mais tarde. Embora este fosse um caso onde era impossível explorar o código em questão, eu senti era prudente para atualizar o código para não ter este problema --conseqüentemente a atualização de segurança" vagamente formulada" para o release 0.8.99 do MaraDNS. <p> MaraDNS também obriga que o servidor seja executado como um usuário sem privilégios, e fortemente encoraja que MaraDNS seja executado em um ambiente chroot (). Em adição, o cache de DNS usa uma estrutura de dados separada que os registros de DNS local, fazendo isto difícil, se não impossível, para o cache afete os registros locais. Este design significa que, até mesmo se uma falha de segurança existir em MaraDNS, a possibilidade de tal falha permite ao atacante que tem privilégios elevados é próxima de zero. <A name=history> </A> <h2>A história de segurança do MaraDNS</h2> Houve alguns problemas de segurança encontrados no MaraDNS: dois razoavelmente principais e um bug de segurança secundário. Também havia um problema de segurança principal causado pelo comportamento errôneo do kernel do Linux, um problema de segurança secundário em <tt>fetchzone </tt> ferramenta do MaraDNS 1.1/1.2, e alguns problemas teóricos de segurança causados por algumas pesquise dentro da implementação de AES em processadores de cache modernos. <p> Aqui estão todos os problemas de segurança já descobertos do MaraDNS: <ol> <li> O primeiro problema de segurança principal foi descoberto por Roy Arends, um dos desenvolvedores do BIND, e foi causado pelo fato que as primeiras versões do MaraDNS não conferia se um determinado pacote de DNS era uma pergunta ou uma resposta. Isto consertado antes do lançamento da versaõ 1.0 do MaraDNS. <p> Desde que uma resposta DNS parece com uma pergunta de DNS, com a exceção de um um bit de diferença, este bug permitia para um atacante enviar para um pacote spoofed DNS que resultaria no MaraDNS enviar uma resposta para si mesmo (ou para outro servidor MaraDNS) que resultaria em uma outra resposta enviada, e assim por diante. <p> A razão pela qual este pequeno problema de segurança passou era por causa de um esforço de overzealous para honrar o espírito de RFC para ser "liberal nisso que um aceita e conservador em que a pessoa envia." Desde então, eu revisei a especificação de DNS para ver existe qualquer outro caso onde um pacote malformado poderia causar este tipo de problema de segurança, e fiz um esforço para qualquer caso desse tipo já não existe mais no MaraDNS. <p> Impacto: Negação remota de serviço <p> <li> Outro problema de segurança principal foi achado por min ao executar uma auditoria do código durante o ciclo de testes beta. Envolveu o código de descompressão, e foi causado porque a compressão de DNS é difícil de implemente, e fácil para criar buracos de segurança. Eu solucionei este assunto reescrevendo o código completamente em questão com segurança em mente. Este problema de segurança apareceu no MaraDNS 0.9.01 (reescrevendo depois). <p> Impacto: Negação remota de serviço <p> <li> Outro problema principal que permitiu uma negação remota de serviço foi causado por algum comportamento errône do kernel Linux. As pessoas que usam BSD ou outro kernel não foram afetados por este problema de segurança. Este problema apareceu no MaraDNS 1.0.28 e no MaraDNS 1.1.35. <p> Impacto: Negação remota de serviço. <p> <li> Um velho problema de segurança secundário o núcleo do gerador de pseudo-random number. Em casos onde haviam um nulo ASCII na chave para o gerador de número pseudo-fortuito, MaraDNS teria menos que 128 bits completos de entropia para o nucleo. Também havia um assunto relacionado, até com menos importancia, onde em certas circunstâncias raras, exemplos múltiplos de MaraDNS poderiam gerar os mesmos números pseudo-fortuitos potencialmente, se duas cópias do MaraDNS usasem o mesmo arquivo de nucleo de acaso estático, e foi começado ao mesmo tempo. Estes assuntos foram consertados antes da liberação do MaraDNS 0.8.24. <p> Impacto: Teórico spoofing dos registros de DNS. <p> <li> Outro problema secundário, mais recentemente descoberto, que só estava presente dentro da fase de desenvolvimento (1.1) do MaraDNS. A ferramenta <tt>fetchzone </tt> não executava validações de entrada o suficiente e era especialmente vulnerável para pacotes que poderiam enviar dados fora-de-bailiwick. Eu consertei este problema em ambos os modos; primeiro dando para a ferramenta de fetchzone mais validação de contribuição. Mais tarde, eu modifiquei o parser do csv2 para não aceitar o tipo de dados que teria ativado o bug de segurança do <tt>fetchzone </tt>. Este problema foi consertado no MaraDNS 1.1.38 (os aprimoramentos do csv2 apareceram no MaraDNS 1.1.47). <p> Impacto: Spoofing dos registros de DNS. <p> <li> A theoretical security problem with the underlying random number generator that MaraDNS uses to generate secure random numbers was discovered by D. J. Bernstein. Since the underlying random number generator uses a fairly simple key schedule (well, a simple key schedule for a cryptographic routine), and since the random number generator uses table lookups, modern CPUs will very slighly vary (on the order of billionths of a second) in the amount of time used to generate a secure random number, depending on the underlying key. Bernstein needed to examine over 200 million packets, obtaining very precise timing information on each packet, to extract a key. <p> I worked around this security problem by having the random number generator rekey every million packets. These changes were done in MaraDNS 1.0.27 and 1.1.35. <p> <A href=http://marc.10east.com/?l=maradns-list&m=111494679116870>Lista de email postada que descreve este assunto</A> <p> Impact: Theoretical remote spoofing of DNS records. <li> More recently, Dag Arne Osvik, Adi Shamir (the "S" in RSA), and Eran Tromer discovered some sophisticated cache data leakage attacks against AES, the algorithm from which MaraDNS' secure random number generator is derived. I have responded to this issue by tweaking MaraDNS' secure random number generator to essentially not leak sensitive key data via cache lookups. <p> <A href=http://www.maradns.org/download/patches/maradns-1.0.34-rng.patch>Patch que descreve os problemas e como eu trabalhei para resolver.</A> <p> Impacto: Teórico spoofing local dos registros de DNS.
