Capítulo 12. Segurança

Esta tradução pode estar desatualizada. Para ajudar com as traduções, acesse a ferramenta de traduções do FreeBSD.

Índice

12.1. Por Que Segurança é Tão Importante

Bugs ocasionalmente são inseridos em software. Indiscutivelmente, os mais perigosos deles são aqueles que abrem vulnerabilidades de segurança. Do ponto de vista técnico, tais vulnerabilidades devem ser fechadas exterminando os bugs que as causam. No entanto, as políticas para lidar com meros bugs e vulnerabilidades de segurança são muito diferentes.

Um bug pequeno típico afeta apenas os usuários que ativaram alguma combinação de opções que acionam o bug. O desenvolvedor acabará lançando um patch seguido de uma nova versão do software, livre do bug, mas a maioria dos usuários não irá se incomodar em fazer a atualização de imediato porque o bug nunca os incomodou. Um bug crítico que pode causar perda de dados representa um problema grave. No entanto, usuários prudentes sabem que muitos acidentes são possíveis, e que além de erros de software, podem levar à perda de dados, e portanto eles fazem backups dos dados importantes, além disso, um bug crítico será descoberto muito rapidamente.

Uma vulnerabilidade de segurança é diferente. Primeiro, ela pode permanecer despercebida por anos, porque geralmente não causa mau funcionamento do software. Segundo, uma parte mal-intencionada pode usá-la para obter acesso não autorizado a um sistema vulnerável, para destruir ou alterar dados confidenciais; no pior dos casos, o usuário nem notará os danos causados. Terceiro, expor um sistema vulnerável geralmente ajuda os invasores a invadir outros sistemas que não poderiam ser comprometidos de outra forma. Portanto, fechar uma vulnerabilidade por si só não é suficiente: notifique a audiência afetada da maneira mais clara e abrangente, o que lhes permitirá avaliar o perigo e tomar as medidas adequadas.

12.2. Corrigindo Vulnerabilidades de Segurança

Embora seja sobre o assunto de ports e pacotes, uma vulnerabilidade de segurança pode inicialmente aparecer na distribuição original ou nos arquivos do port. No primeiro caso, o desenvolvedor de software original provavelmente lançará um patch ou uma nova versão instantaneamente. Atualize o port prontamente com relação à correção do autor. Se a correção for atrasada por algum motivo, marque o port como FORBIDDEN ou adicione um arquivo patch no port. No caso de um port vulnerável, conserte o port o mais rápido possível. Em ambos os casos, siga o procedimento padrão para enviar alterações a menos que tenha direitos para enviá-lo diretamente para a árvore de ports.

Ser um committer de ports não é suficiente para fazer um commit em um port arbitrário. Lembre-se que os ports geralmente possuem mantenedores, e eles devem ser respeitados.

Por favor, certifique-se de que a revisão do port é incrementada assim que a vulnerabilidade for fechada. É assim que os usuários que atualizam pacotes regularmente verão que precisam executar uma atualização. Além disso, um novo pacote será compilado e distribuído por FTP e mirrors WWW, substituindo o vulnerável. Atualize PORTREVISION a menos que tenha mudado o DISTVERSION durante a correção da vulnerabilidade. Isso é, incremente PORTREVISION se adicionar um arquivo de patch ao port, mas não o incremente se atualizar o port para a versão mais recente do software, pois DISTVERSION já terá sido alterado. Por favor, consulte a seção correspondente para mais informações.

12.3. Mantendo a Comunidade Informada

12.3.1. O Banco de Dados VuXML

Uma medida muito importante e urgente a ser tomada o mais cedo possível ao descobrir uma vulnerabilidade de segurança é notificar a comunidade de usuários de port sobre o perigo. Essa notificação serve a dois propósitos. Primeiro, se o perigo for realmente severo, será prudente aplicar uma solução instantânea. Por exemplo, parar o serviço de rede afetado ou até mesmo desinstalar o port completamente até que a vulnerabilidade seja fechada. Segundo, muitos usuários tendem a atualizar pacotes instalados apenas ocasionalmente. Eles saberão pela notificação que eles devem atualizar o pacote o quanto antes assim que uma versão com a correção estiver disponível.

Dado o grande número de ports na árvore, um aviso de segurança não pode ser emitido em cada incidente sem criar um flood e perder a atenção do público quando se tratar de assuntos realmente sérios. Portanto, vulnerabilidades de segurança encontradas em ports são registradas no banco de dados VuXML do FreeBSD. Os membros do Security Officer Team também monitoram os problemas que requerem suas intervenções.

Committers podem eles mesmos atualizar o banco de dados VuXML, ajudar o Security Officer Team e fornecer informações cruciais para a comunidade mais rapidamente. Aqueles que não são committers ou que descobriram uma vulnerabilidade excepcionalmente severa não devem hesitar em contatar o Security Officer Team diretamente, conforme descrito na página Informações de Segurança do FreeBSD.

O banco de dados VuXML é um documento XML. Seu arquivo fonte vuln.xml é mantido dentro do port security/vuxml. Portanto, o caminho completo do arquivo será PORTSDIR/security/vuxml/vuln.xml. Toda vez que uma vulnerabilidade de segurança é descoberta em um port, favor adicionar uma entrada para ela nesse arquivo. Até que esteja familiarizado com o VuXML, a melhor coisa a fazer é encontrar uma entrada existente que seja parecida, depois copiá-la e usá-la como modelo.

12.3.2. Uma Breve Introdução ao VuXML

O formato XML completo é complexo e está muito além do escopo deste livro. No entanto, para obter informações básicas sobre a estrutura de uma entrada VuXML, apenas a noção de tags é necessária. Os nomes de tags XML são colocados entre colchetes angulares. Cada abertura <tag> deve ter um fechamento correspondente </tag>. As tags podem ser aninhadas. Se aninhadas, as tags internas devem ser fechadas antes das externas. Há uma hierarquia de tags, ou seja, regras mais complexas de aninhamento. Isso é semelhante ao HTML. A principal diferença é que o XML é eXtensible, isto é, com base na definição de tags personalizadas. Devido à sua estrutura intrínseca, o XML por outro lado coloca dados amórficos de uma maneira mais organizada. O VuXML é especialmente adaptado para marcar descrições de vulnerabilidades de segurança.

Agora considere uma entrada VuXML realista:

<vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"> (1)
  <topic>Several vulnerabilities found in Foo</topic> (2)
  <affects>
    <package>
      <name>foo</name> (3)
      <name>foo-devel</name>
      <name>ja-foo</name>
      <range><ge>1.6</ge><lt>1.9</lt></range> (4)
      <range><ge>2.*</ge><lt>2.4_1</lt></range>
      <range><eq>3.0b1</eq></range>
    </package>
    <package>
      <name>openfoo</name> (5)
      <range><lt>1.10_7</lt></range> (6)
      <range><ge>1.2,1</ge><lt>1.3_1,1</lt></range>
    </package>
  </affects>
  <description>
    <body xmlns="http://www.w3.org/1999/xhtml">
      <p>J. Random Hacker reports:</p> (7)
      <blockquote
        cite="http://j.r.hacker.com/advisories/1">
        <p>Several issues in the Foo software may be exploited
          via carefully crafted QUUX requests.  These requests will
          permit the injection of Bar code, mumble theft, and the
          readability of the Foo administrator account.</p>
      </blockquote>
    </body>
  </description>
  <references> (8)
    <freebsdsa>SA-10:75.foo</freebsdsa> (9)
    <freebsdpr>ports/987654</freebsdpr> (10)
    <cvename>CAN-2010-0201</cvename> (11)
    <cvename>CAN-2010-0466</cvename>
    <bid>96298</bid> (12)
    <certsa>CA-2010-99</certsa> (13)
    <certvu>740169</certvu> (14)
    <uscertsa>SA10-99A</uscertsa> (15)
    <uscertta>SA10-99A</uscertta> (16)
    <mlist msgid="201075606@hacker.com">http://marc.theaimsgroup.com/?l=bugtraq&amp;m=203886607825605</mlist> (17)
    <url>http://j.r.hacker.com/advisories/1</url> (18)
  </references>
  <dates>
    <discovery>2010-05-25</discovery> (19)
    <entry>2010-07-13</entry> (20)
    <modified>2010-09-17</modified> (21)
  </dates>
</vuln>

1	Os nomes das tags devem ser auto explicativos, por isso vamos dar uma olhada apenas nos campos que precisam ser preenchidos:
2	Esta é a tag de nível superior de uma entrada VuXML. Ela tem um atributo obrigatório, `vid`, especificando um identificador universalmente único (UUID) para essa entrada (entre aspas). Gere um UUID para cada nova entrada VuXML (e não se esqueça de substituí-lo pelo modelo UUID, a menos que esteja escrevendo a entrada desde o início). Use uuidgen(1) para gerar um UUID VuXML.
3	Esta é uma descrição de uma linha do problema encontrado.
4	Os nomes dos pacotes afetados são listados nesta tag. Vários nomes podem ser fornecidos, pois vários pacotes podem ser baseados em um único master port ou produto de software. Isso pode incluir branches stable e de desenvolvimento, versões de localidade e slave ports englobando diferentes escolhas de opções importantes de configuração em build-time.
5	Versões afetadas de pacote(s) são especificadas com um ou mais intervalos usando uma combinação de elementos `<lt>`, `<le>`, `<eq>`, `<ge>` e `<gt>`. Verifique se os intervalos de versão fornecidos não se sobrepõem.Em uma especificação de range, (asterisco) indica o menor número de versão. Em particular, `2.` é menor do que `2.a`. Portanto, um asterisco pode ser usado em um intervalo para corresponder todas as possíveis versões `alfa`, `beta` e `RC`. Por exemplo,`<ge>2.</ge><lt>3.</lt>` irá seletivamente corresponder a cada versão `2.x` enquanto `<ge>2.0</ge><lt>3.0</lt>` não irá, pois a versão `2.r3` será ignorada e a versão `3.b` estará dentro do range.O exemplo acima especifica que as versões afetadas vão de `1.6` até menor que `1.9`, versões `2.x` antes de `2.4_1` e versão `3.0b1`.
6	Vários grupos de pacotes relacionados (essencialmente, ports) podem ser listados na seção `<affected>`. Isso pode ser usado se vários produtos de software (como FooBar, FreeBar e OpenBar) crescerem da mesma base de código e ainda compartilharem seus bugs e vulnerabilidades. Observe a diferença de listar vários nomes em uma única seção <package>.
7	Os intervalos de versão têm que incluir `PORTEPOCH` e `PORTREVISION` se aplicáveis. Lembre-se que, de acordo com as regras de agrupamento, uma versão com um valor diferente de zero para o `PORTEPOCH` é maior que qualquer versão sem `PORTEPOCH`, por exemplo, `3.0,1` é maior que `3.1` ou até mesmo do que `8.9`.
8	Este é um resumo do problema. XHTML é usado neste campo. Pelo menos `<p>` e `</p>` tem que aparecer. Marcações mais complexas podem ser usadas, mas apenas por uma questão de precisão e clareza: Sem enfeitar, por favor. Esta seção contém referências a documentos relevantes. Quanto mais referências aplicadas, melhor.
9	Isto é um aviso de segurança do FreeBSD.
10	Isto é um relatório de problemas do FreeBSD.
11	Isto é um identificador MITRE CVE.
12	Isto é um ID de bug do SecurityFocus.
13	Isto é um aviso de segurança US-CERT.
14	Isto é uma nota de vulnerabilidade US-CERT.
15	Isto é um alerta de Cyber Segurança US-CERT.
16	Isto é um Alerta Técnico de Cyber Segurança US-CERT.
17	Esta é uma URL para uma postagem arquivada em uma lista de discussão. O atributo `msgid` é opcional e pode especificar o ID da mensagem no post.
18	Esta é uma URL genérica. Apenas se nenhuma das outras categorias de referência for aplicável.
19	Esta é a data em que o problema foi divulgado (YYYY-MM-DD).
20	Esta é a data quando a entrada foi adicionada (YYYY-MM-DD).
21	Esta é a data em que qualquer informação na entrada foi modificada pela última vez (YYYY-MM-DD). Novas entradas não devem incluir este campo. Adicione-a ao editar uma entrada existente.

12.3.3. Testando Alterações no Banco de Dados VuXML

Este exemplo descreve uma nova entrada para uma vulnerabilidade no pacote dropbear que foi corrigido na versão dropbear-2013.59.

Como pré-requisito, instale uma nova versão do port security/vuxml.

Primeiro, verifique se já existe uma entrada para esta vulnerabilidade. Se houvesse essa entrada, ela deveria corresponder com a versão anterior do pacote, 2013.58:

% pkg audit dropbear-2013.58

Se não houver nenhuma, adicione uma nova entrada para esta vulnerabilidade.

% cd ${PORTSDIR}/security/vuxml
% make newentry

Verifique sua sintaxe e formatação:

% make validate

Pelo menos um desses pacotes precisa ser instalado:textproc/libxml2, textproc/jade.

Verifique se a seção <affected> da entrada irá coincidir com os pacotes corretos:

% pkg audit -f ${PORTSDIR}/security/vuxml/vuln.xml dropbear-2013.58

Certifique-se de que a entrada não produza correspondências incorretas.

Agora, verifique se as versões corretas do pacote são correspondidas pela entrada:

% pkg audit -f ${PORTSDIR}/security/vuxml/vuln.xml dropbear-2013.58 dropbear-2013.59
dropbear-2012.58 is vulnerable:
dropbear -- exposure of sensitive information, DoS
CVE: CVE-2013-4434
CVE: CVE-2013-4421
WWW: http://portaudit.FreeBSD.org/8c9b48d1-3715-11e3-a624-00262d8b701d.html

1 problem(s) in the installed packages found.

A versão anterior é encontrada enquanto a última não.

Última alteração em: 9 de março de 2024 por Danilo G. Baio

Início