Esta página fue actualizada por última vez el 2020-06.

Este proceso está sujeto a cambio. Por favor, refiérase a esta página para el actual VRP.

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. Punto de contacto para problemas de seguridad

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

II. Equipo de respuesta de seguridad

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

III. Respuesta al incidente

  1. El investigador presenta el informe mediante: security (at) geti2p.net
  2. El equipo de respuesta designa un gestor de respuesta que se ocupa del informe en particular en base a la disponibilidad y/o al conjunto de conocimientos.
  3. In no more than 3 working days, Response Team should respond to researcher using only encrypted methods.
  4. El gestor de respuesta formula preguntas para satisfacer cualquier información necesaria y para confirmar si la entrega efectivamente indica una vulnerabilidad.
    1. Si la entrega prueba indicar una vulnerabilidad, se continúe.
    2. Si no indica vulnerabilidad:
      1. El gestor de respuesta responde con las razones por las que la entrega no indica una vulnerabilidad.
      2. Si es necesario, el gestor de respuesta mueve la conversación a un 'ticket' nuevo o existente en un Trac público.
  5. Establezca la gravedad de la vulnerabilidad:
    HIGH
    Repercute en la red como conjunto, tiene potencial para desbaratar la red entera o está al nivel de una gran catástrofe.
    MEDIUM
    Affects individual routers, or must be carefully exploited.
    LOW
    No es explotable con facilidad.
  6. Responda de acuerdo a la gravedad de la vulnerabilidad:
    1. Las de gravedad ALTA deben notificarse en el sitio web y en la suscripción de novedades en 3 días laborables desde su clasificación.
      1. La notificación debe, en su caso, enumerar los pasos adecuados a seguir por los usuarios.
      2. La notificación no debe incluir detalle alguno que pudiera sugerir una vía para explotar la vulnerabilidad.
      3. La última toma precedencia sobre la anterior.
    2. Las de gravedad MEDIA y ALTA requerirán una versión puntual.
    3. Las de gravedad BAJA serán abordadas en la siguiente versión regular.
  7. El equipo de respuesta aplica el/los parche(s) apropiado(s).
    1. Response Manager works on a patch LOCALLY, patches are shared by the response team via PGP-encrypted e-mail until such a time as it is safe to expose to the public.
    2. Los parches se revisan con el investigador.
    3. Cualquier mensaje asociado con consignaciones (commits) PÚBLICAS durante el periodo de revisión no debe hacer referencia a la naturaleza de seguridad del ramal (branch) PRIVADO o de sus consignaciones.
    4. Se crea el borrador del anuncio de vulnerabilidad.
      1. Incluye la gravedad de la vulnerabilidad.
      2. Incluye los sistemas/aplicaciones afectados.
      3. Incluye soluciones (en su caso) por si no se puede aplicar el parche.
    5. Se discute la fecha de publicación.
  8. En la fecha de publicación, el equipo de respuesta se coordina con los desarrolladores para culminar la actualización:
    1. El gestor de respuesta propaga el "hotfix branch" (ramal de corrección urgente) a trunk (ramal troncal).
    2. El gestor de respuesta incluye el borrador de anuncio de vulnerabilidad en las notas de la versión.
    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. Proceso de divulgación post-publicación

  1. El equipo de respuesta tiene 90 días para satisfacer todos los puntos dentro de la sección III.
  2. Si el proceso de respuesta a incidente en la sección III se completa con éxito:
    1. El gestor de respuesta contacta con el investigador y le pregunta si desea aparecer en los créditos.
    2. Finalice el borrador de anuncio de vulnerabilidad e incluya lo siguiente:
      1. Nombre del proyecto y URL.
      2. Versiones que se sabe que están afectadas.
      3. Versiones que se sabe que no están afectadas (por ejemplo, si el código vulnerable fue introducido en una versión reciente, las versiones anteriores no están afectadas).
      4. Versiones no comprobadas.
      5. Tipo de vulnerabilidad y su impacto.
      6. Si ya se obtuvo o se aplica, un CVE-ID (identificador de vulnerabilidades).
      7. La fecha planeada de publicación coordinada.
      8. Factores de mitigación (por ejemplo, la vulnerabilidad sólo se expone con configuraciones infrecuentes, y no predeterminadas).
      9. Soluciones auxiliares (cambios que el usuario puede hacer en la configuración para reducir su exposición a la vulnerabilidad).
      10. Si se aplica, créditos al informante original.
    3. Anuncio de fin de la vulnerabilidad mediante la versión en el sitio web y en la suscripción de novedades.
      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, anuncio de fin de la vulnerabilidad mediante la versión en listas de correo bien-conocidas:
      1. oss-security@lists.openwall.com
      2. bugtraq@securityfocus.com
    6. Si se aplica, los desarrolladores solicitan un CVE-ID (identificador de vulnerabilidad).
      1. Se hace referencia también a la consignación (commit) que aplicó la corrección en una futura consignación, y se incluye un CVE-ID.
  3. Si el proceso de respuesta a incidente en la sección III *no* se completó con éxito:
    1. El equipo de respuesta y los desarolladores organizan una reunión en el IRC para discutir por qué y qué puntos de la sección III no se resolvieron, y cómo puede el equipo resolverlos en el futuro.
    2. Cualquier reunión de desarrolladores inmediatamente a continuación del incidente debe incluir los puntos en la sección V.
    3. Si surgen disputas acerca de si divulgar o no información acerca de una vulnerabilidad, o cuándo hacerlo, el equipo de respuesta discutirá públicamente el problema en el IRC e intentará alcanzar un consenso.
    4. Si no se alcanza un conseso para una divulgación a tiempo (no más tarde de 90 días), el investigador (tras 90 días) está totalmente legitimado para exponer la vulnerabilidad al público.

V. Análisis del incidente

  1. Aislar el código base
    1. El equipo de respuesta y los desarrolladores deben coordinarse para trabajar en lo siguiente:
      1. Implementaciones problemáticas de clases/librerías/funciones, etc.
      2. Orientarse al empaquetado de aplicaciones/distribuciones, etc.
      3. Errores de operador/configuración, etc.
  2. Auditoría
    1. El equipo de respuesta y los desarrolladores deben coordinarse para trabajar en lo siguiente:
      1. Auditado de la(s) área(s) problemáticas tal como se discutió en el punto 1.
      2. Generar informes internos y almacenarlos para futura referencia.
      3. Si los resultados no son información sensible, compartirlos con el público vía IRC o mediante el Trac público.
  3. El equipo de respuesta dispone de 45 días tras completar la sección III para asegurar el completado de la sección V.

VI. Resoluciones

En relación a el/los incidente(s), cualquier pregunta o resolución adicional entre el investigador y el equipo de respuesta y desarrollo tras la divulgación pública, puede ser abordado mediante lo siguiente:

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

VII. Mejora continua

  1. El equipo de respuesta y los desarrolladores deben mantener reuniones anuales para revisar los incidentes del año anterior.
  2. El equipo de respuesta o la(s) persona(s) designada(s) debe(n) proporcionar una presentación breve, incluyendo:
    1. Áreas de I2P afectadas por los incidentes.
    2. Cualquier periodo de inactividad de la red o coste monetario (en su caso) de los incidentes.
    3. Maneras en las que los incidentes podrían haber sido evitados (en su caso).
    4. En qué medida fue efectivo este proceso para encargarse de los incidentes.
  3. Tras la presentación, el equipo de respuesta y los desarrolladores deben discutir:
    1. Cambios potenciales en el desarrollo de procesos para reducir futuros incidentes.
    2. Cambios potenciales en este proceso para mejorar futuras respuestas.