Этот процесс может быть изменен. Пожалуйста, обратитесь к этой странице для текущего 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. Контакты по вопросам безопасности

II. Группа, ответственная за безопасность

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

III. Ответственные по чрезвычайным ситуациям

1. Researcher submits report via: security (at) geti2p.net
2. Ответственная группа назначает менеджера по ответам, отвечающего за конкретный ответ, на основе доступности и/или набора знаний.
3. In no more than 3 working days, Response Team should respond to researcher using only encrypted methods.
4. Ответственный менеджер делает запросы, чтобы удовлетворить любую необходимую информацию и подтвердить, что предмет действительно является уязвимостью.
   1. Если предмет окажется уязвимым, выполнить.
   2. Если не уязвим:
      1. Ответственный менеджер объясняет, почему предмет не является уязвимостью.
      2. Ответственный менеджер перемещает обсуждение в новый или существующий тикет на публичном трекере, если это необходимо.
5. Установить степень опасности уязвимости:

   HIGH

   Касается сети в целом, имеют потенциал, чтобы сломать всю сеть или имеют масштаб большой катастрофы.

   MEDIUM

   Affects individual routers, or must be carefully exploited.

   LOW

   Нелегко воспроизвести.

6. Ответить согласно степени опасности уязвимости:
   1. О ВЫСОКОЙ степени опасности должны быть уведомления на веб-сайте и в ленте новостей в течение 3 рабочих дней с момента классификации.
      1. В уведомлении должны быть перечислены соответствующие действия, которые должны предпринять пользователи, если таковые имеются.
      2. В уведомлении не должно содержаться никаких сведений, которые могли бы указывать на путь эксплуатации.
      3. Последнее имеет приоритет над первым.
   2. СРЕДНИЕ и ВЫСОКИЕ степени опасности потребуют Point Release.
   3. НИЗКИЕ степени опасности будут рассмотрены в следующем регулярном выпуске.
7. Ответственная группа применяет соответствующие исправления.
   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. Патчи рассматриваются совместно с исследователем.
   3. Любые сообщения, связанные с ПУБЛИЧНЫМИ коммитами во время проверки, не должны ссылаться на характер безопасности ПРИВАТНОЙ ветви или ее коммита.
   4. Составляется объявление об уязвимости.
      1. Добавьте серьезность уязвимости.
      2. Добавьте системы/приложения, к которым это применимо.
      3. Добавьте решения (если имеются), если патч не может быть применен.
   5. Дата релиза обсуждается.
8. На дату релиза ответственная группа координирует работу с разработчиками для завершения обновления:
   1. Ответственный менеджер сливает "hotfix branch" с основной версией.
   2. Ответственный менеджер включает черновик объявления об уязвимости в заметки о выпуске.
   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. Процесс раскрытия информации после выпуска

1. У ответственной группы есть 90 дней, чтобы выполнить все пункты в разделе III.
2. Если процесс реагирования на инциденты в разделе III успешно завершен:
   1. Ответственный менеджер связывается с исследователем и спрашивает, желает ли исследователь получить благодарность.
   2. Доработать проект объявления об уязвимости и включить в него следующее:
      1. Название проекта и URL.
      2. Затронутые версии.
      3. Версии, которые не затронуты (например, уязвимый код был введен в последней версии, и поэтому старые версии не затронуты).
      4. Непроверенные версии.
      5. Тип уязвимости и ее воздействие.
      6. Если уже получено или применимо, CVE-ID.
      7. Планируемая, согласованная дата релиза.
      8. Смягчающие факторы (например, уязвимость только в необычных, нестандартных конфигурациях).
      9. Обходные пути (пользователи могут вносить изменения в конфигурацию, чтобы уменьшить подверженность уязвимости).
      10. Если возможно, благодарности сообщившему о проблеме.
   3. Выпуск завершенного объявления об уязвимости на веб-сайте и в ленте новостей.
   4. 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. Для ВЫСОКИХ уровней опасности, релиз завершенного объявления об уязвимости в известных списках рассылки:
      1. oss-security@lists.openwall.com
      2. bugtraq@securityfocus.com
   6. Если возможно, разработчики запрашивают CVE-ID.
      1. Коммит, который применил исправление, также ссылается в будущие коммиты и включает CVE-ID.
3. If the Incident Response process in section III is *not* successfully completed:
   1. Response Team and developers organize an IRC meeting to discuss why/what points in section III were not resolved and how the team can resolve them in the future.
   2. Any developer meetings immediately following the incident should include points made in section V.
   3. If disputes arise about whether or when to disclose information about a vulnerability, the Response Team will publicly discuss the issue via IRC and attempt to reach consensus.
   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. Анализ инцидента

1. Isolate codebase
   1. Response Team and developers should coordinate to work on the following:
      1. Problematic implementation of classes/libraries/functions, etc.
      2. Focus on apps/distro packaging, etc.
      3. Operator/config error, etc.
2. Auditing
   1. Response Team and developers should coordinate to work on the following:
      1. Auditing of problem area(s) as discussed in point 1.
      2. Generate internal reports and store for future reference.
      3. If results are not sensitive, share with the public via IRC or public Trac.
3. Response Team has 45 days following completion of section III to ensure completion of section V.

VI. Решения

Any further questions or resolutions regarding the incident(s) between the researcher and response + development team after public disclosure can be addressed via the following:

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

VII. Непрерывное улучшение

1. Response Team and developers should hold annual meetings to review the previous year's incidents.
2. Response Team or designated person(s) should give a brief presentation, including:
   1. Areas of I2P affected by the incidents.
   2. Any network downtime or monetary cost (if any) of the incidents.
   3. Ways in which the incidents could have been avoided (if any).
   4. How effective this process was in dealing with the incidents.
3. After the presentation, Response Team and developers should discuss:
   1. Potential changes to development processes to reduce future incidents.
   2. Potential changes to this process to improve future responses.