Esta página foi atualizada pela última vez em 2020-06.

Este processo está sujeito a alterações. Consulte esta página para obter o VRP atual.

This page was last updated April 2023.

Researchers: during your study and network testing, we ask that you refrain from the following: - Performing active exploits or Denial of Service attacks on the I2P network - Performing social engineering on I2P team and community members - Performing any physical or electronic attempts against I2P property and/or data centers

As I2P is an open-source community, many volunteers and development team members run their own I2P Sites as well as public (“non-private internet”) domains. These sites/servers are NOT in the scope of the vulnerability assessment / response process, only the underlying code of I2P is.

I. Ponto de contato para questões de segurança

security (at) geti2p.net - GPG Key fingerprint = EA27 06D6 14F5 28DB 764B F47E CFCD C461 75E6 694A

II. Equipe de resposta de segurança

Echelon is the trusted security point-of-contact. He forwards emails to team members as appropriate.

III. Resposta a incidentes

  1. O pesquisador envia o relatório por meio de: security (at) geti2p.net
  2. A Equipe de Resposta designa um Gerente de Resposta que é responsável pelo relatório específico com base na disponibilidade e/ou no conjunto de conhecimentos.
  3. In no more than 3 working days, Response Team should respond to researcher using only encrypted methods.
  4. O Response Manager faz perguntas para satisfazer todas as informações necessárias e confirmar se oenvio é realmente uma vulnerabilidade.
    1. Se o envio se mostrar vulnerável, prossiga.
    2. Se não vulnerável:
      1. O Response Manager responde com motivos pelos quais o envio não é uma vulnerabilidade.
      2. O Response Manager move a discussão para um ticket novo ou existente no Trac público, se necessário.
  5. Estabeleça a gravidade da vulnerabilidade:
    HIGH
    Afeta a rede como um todo, tem potencial para quebrar toda a rede ou está em uma escala de grande catástrofe.
    MEDIUM
    Afeta roteadores individuais ou deve ser explorado com cuidado.
    LOW
    Não é facilmente explorável.
  6. Responda de acordo com a gravidade da vulnerabilidade:
    1. HIGH severities must be notified on website and news feed within 3 working days of classification.
      1. A notificação deve listar as etapas apropriadas a serem executadas pelos usuários, se houver.
      2. A notificação não deve incluir quaisquer detalhes que possam sugerir uma via de exploração.
      3. Este último tem precedência sobre o primeiro.
    2. As gravidades MÉDIA e ALTA exigirão uma liberação pontual.
    3. As gravidades BAIXAS serão abordadas na próxima versão regular.
  7. A equipe de resposta aplica os patches apropriados.
    1. O Response Manager trabalha em um patch LOCALMENTE, os patches são compartilhados pela equipe de resposta por meio de e-mail criptografado por PGP até o momento em que seja seguro expor ao público.
    2. Os patches são revisados com o pesquisador.
    3. Quaisquer mensagens associadas a commits PUBLIC durante o tempo de revisão não devem fazer referência à natureza de segurança do branch PRIVATE ou de seus commits.
    4. O anúncio de vulnerabilidade é elaborado.
      1. Inclua a gravidade da vulnerabilidade.
      2. Inclua sistemas/aplicativos afetados.
      3. Inclua soluções (se houver) se o patch não puder ser aplicado.
    5. A data de lançamento é discutida.
  8. Na data de lançamento, a Equipe de Resposta coordena com os desenvolvedores para finalizar a atualização:
    1. O Gerenciador de Resposta propaga a "ramificação do hotfix" para o tronco.
    2. O Gerenciador de Resposta inclui rascunho de anúncio de vulnerabilidade nas notas de versão.
    3. Proceed with the Point or Regular Release. At this time, it is not possible to release an in-network update for only one operating system or architecture. In order that all affected products can be released as quickly as possible, the person responsible for that software should be able to perform necessary release processes in a timely manner. Importantly this should include consideration for package maintainers in Debian, Ubuntu and F-Droid.

IV. Processo de Divulgação Pós-lançamento

  1. Response Team has 90 days to fulfill all points within section III.
  2. Se o processo de Resposta a Incidentes na seção III for concluído com êxito:
    1. O Response Manager entra em contato com o pesquisador e pergunta se o pesquisador deseja crédito.
    2. Finalize o rascunho do anúncio de vulnerabilidade e inclua o seguinte:
      1. Nome do projeto e URL.
      2. Versões conhecidas por serem afetadas.
      3. Versões conhecidas por não serem afetadas (por exemplo, o código vulnerável foi introduzido em uma versão recente e, portanto, as versões mais antigas não são afetadas).
      4. Versões não verificadas.
      5. Tipo de vulnerabilidade e seu impacto.
      6. Se já obtido ou aplicável, um CVE-ID.
      7. A data de lançamento é planejada e coordenada.
      8. Fatores atenuantes (por exemplo, a vulnerabilidade só é exposta em configurações incomuns e não padrão).
      9. Soluções alternativas (alterações de configuração que os usuários podem fazer para reduzir sua exposição à vulnerabilidade).
      10. Se for o caso, créditos ao repórter original.
    3. Lançamento de anúncio de vulnerabilidade finalizado no site e no feed de notícias.
      1. If the vulnerability may be exploited while the network is being upgraded, delay the announcement until the vulnerable routers are upgraded.
      2. After the update is successful, write the announcement for the news feed, send it for translation, and release it.
      3. When translations come in, news operators should pull in the translations and update their feeds.
    5. Para severidades ALTAS, libere o anúncio de vulnerabilidade finalizado em listas de discussão conhecidas:
      1. oss-security@lists.openwall.com
      2. bugtraq@securityfocus.com
    6. Se aplicável, os desenvolvedores solicitam um CVE-ID.
      1. A confirmação que aplicou a correção também é feita referência em uma confirmação futura e inclui uma CVE-ID.
  3. Se o processo de Resposta a Incidentes na seção III *não* for concluído com êxito:
    1. A equipe de resposta e os desenvolvedores organizam uma reunião de IRC para discutir por que/quais pontos na seção III não foram resolvidos e como a equipe pode resolvê-los no futuro.
    2. Quaisquer reuniões de desenvolvedores imediatamente após o incidente devem incluir pontosfeitos na seção V.
    3. Se surgirem disputas sobre se ou quando divulgar informações sobre umavulnerabilidade, a Equipe de Resposta discutirá publicamente o problema via IRC etentará chegar a um consenso.
    4. If consensus on a timely disclosure is not met (no later than 90 days), the researcher (after 90 days) has every right to expose the vulnerability to the public.

V. Análise de Incidentes

  1. Isolar a base de código
    1. A equipe de resposta e os desenvolvedores devem se coordenar para trabalhar no seguinte:
      1. Implementação problemática de classes/bibliotecas/funções, etc.
      2. Concentre-se em empacotamento de aplicativos/distro, etc.
      3. Erro de operador/configuração, etc.
  2. Auditoria
    1. A equipe de resposta e os desenvolvedores devem se coordenar para trabalhar no seguinte:
      1. Auditoria da(s) área(s) problemática(s), tal como referido no ponto 1.
      2. Gere relatórios internos e armazene para referência futura.
      3. Se os resultados não forem sensíveis, partilhe com o público através de IRC ou Trac público.
  3. Response Team has 45 days following completion of section III to ensure completion of section V.

VI. Resoluções

Quaisquer outras perguntas ou resoluções sobre o(s) incidente(s) entre o pesquisador e a equipe de resposta + desenvolvimento após adivulgação pública podem serabordadas através do seguinte:

  1. Trac
  2. IRC
  3. Email
  4. Twitter

VII. Aperfeiçoamento Contínuo

  1. A equipe de resposta e os desenvolvedores devem realizar reuniões anuais para revisar os incidentes do ano anterior.
  2. A Equipe de Resposta ou a(s) pessoa(s) designada(s) deve(m) fazer uma breve apresentação, incluindo:
    1. Áreas da I2P afetadas pelos incidentes.
    2. Qualquer tempo de inatividade da rede ou custo monetário (se houver) dos incidentes.
    3. Maneiras pelas quais os incidentes poderiam ter sido evitados (se houver).
    4. Como esse processo foi eficaz para lidar com os incidentes.
  3. Após a apresentação, a Equipe de Resposta e os desenvolvedores devem discutir:
    1. Possíveis mudanças nos processos de desenvolvimento para reduzir incidentes futuros.
    2. Possíveis mudanças nesse processo para melhorar as respostas futuras.