Halaman ini terakhir diperbarui pada s2020-06.

Proses ini bisa berubah. Silakan lihat halaman ini untuk VRP terkini.

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. Point of Contact for Security Issues

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

II. Security Response Team

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

III. Incident Response

  1. Peneliti mengirimkan laporan melalui: security (at) geti2p.net
  2. Response Team menunjuk Response Manager yang bertanggung jawab atas laporan tertentu berdasarkan ketersediaan dan/atau knowledge-set.
  3. Tidak lebih dari 3 hari kerja, Response Team harus dengan penuh rasa terima kasih menanggapi peneliti dengan hanya menggunakan metode terenkripsi.
  4. Response Manager membuat pertanyaan untuk memuaskan informasi yang dibutuhkan dan untuk memastikan bahwa laporan tersebut memang merupakan kerentanan.
    1. Jika laporan terbukti adalah kerentanan, lanjutkan.
    2. Jika bukan kerentanan:
      1. Response Manager merespons dengan alasan mengapa laporan bukan merupakan kerentanan.
      2. Response Manager memindahkan diskusi ke tiket baru atau tiket yang sudah ada di Trac publik, jika perlu.
  5. Menetapkan tingkat keparahan kerentanan:
    HIGH
    Memberikan efek kepada jaringan secara keseluruhan, berpotensi menghancurkan keseluruhan jaringan atau berskala bencana besar.
    MEDIUM
    Memberikan efek kepada router individual, atau harus dieksploitasi secara hati-hati.
    LOW
    Tidak mudah dieksploitasi.
  6. Merespon sesuai dengan tingkat keparahan kerentanan:
    1. Tingkat keparahan yang tinggi harus diberitahukan di situs web dan news feed dalam 3 hari kerja.
      1. Pemberitahuan harus mencantumkan langkah-langkah yang tepat untuk diambil pengguna, jika ada.
      2. Pemberitahuan tersebut tidak boleh menyertakan rincian yang dapat menyarankan jalur eksploitasi.
      3. Yang terakhir lebih diutamakan daripada yang pertama.
    2. Tingkat keparahan yang SEDANG dan TINGGI akan memerlukan Point Release.
    3. Tingkat keparahan yang RENDAH akan diatasi di dalam Regular Release berikutnya.
  7. Response Team menerapkan patch yang sesuai.
    1. Manajer Respons membuat patch secara lokal, patch dibagikan oleh tim respons melalui email yang dienkripsi PGP sampai waktu yang aman untuk diekspos kepada publik.
    2. Patch diperiksa oleh peneliti.
    3. Setiap pesan yang terkait dengan komitmen PUBLIK selama peninjauan sebaiknya tidak mengacu pada sifat keamanan cabang PRIVATE atau commit-nya.
    4. Pengumuman kerentanan disusun.
      1. menyertakan tingkat keparahan dari kerentanan.
      2. Menyertakan sistem/aplikasi yang terpengaruh.
      3. Menyertakan solusi (jika ada) jika patch tidak bisa diterapkan.
    5. Tanggal rilis dibahas.
  8. Pada tanggal rilis, Response Team berkoordinasi dengan pengembang untuk menyelesaikan pembaruan:
    1. Response Manager menyebarkan "hotfix bramch" ke dalam trunk.
    2. Response Manager menyertakan draft pengumuman kerentanan dalam catatan rilis.
    3. Lanjutkan dengan Point atau Regular Release. Saat ini, tidak mungkin merilis pembaruan dalam jaringan hanya untuk satu sistem operasi atau arsitektur. Agar semua produk yang terpengaruh dapat dirilis secepat mungkin, orang yang bertanggung jawab untuk perangkat lunak itu harus dapat melakukan proses rilis yang diperlukan dalam tepat waktu. Yang penting, ini harus termasuk pertimbangan untuk package maintainer di Debian, Ubuntu dan F-Droid.

IV. Post-release Disclosure Process

  1. Response Team memiliki waktu 90 hari untuk memenuhi semua poin di dalam bagian III.
  2. Jika proses Incident Response pada bagian III berhasil diselesaikan:
    1. Response Manager menghubungi peneliti dan menanyakan apakah peneliti menginginkan namanya disebut.
    2. Selesaikan draft pengumuman kerentanan dan masukkan hal-hal berikut:
      1. Nama proyek dan URL
      2. Beberapa versi diketahui terkena pengaruh.
      3. Versi yang diketahui tidak terpengaruh (misalnya, kode yang rentan dimasukkan dalam versi terbaru sehingga versi yang lebih lama tidak terpengaruh).
      4. Versi tidak diperiksa.
      5. Jenis kerentanan dan dampaknya.
      6. Jika sudah didapat atau bisa diterapkan, CVE-ID.
      7. Tanggal rilis yang direncanakan dan terkoordinasi.
      8. Faktor yang mengurangi (misalnya, kerentanan hanya terjadi dalam konfigurasi non-default yang tidak biasa).
      9. Workarounds (perubahan konfigurasi yang dapat dilakukan pengguna untuk mengurangi paparan terhadap kerentanan).
      10. Jika berlaku, ucapkan terima kasih kepada orang yang melaporkan.
    3. Pengumuman kerentanan rilis terakhir di situs web dan news feed.
      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. Untuk tingkat keparahan yang TINGGI, rilis pengumuman kerentanan akhir pada milis terkenal:
      1. oss-security@lists.openwall.com
      2. bugtraq@securityfocus.com
    6. Jika dapat diterapkan, pengembang dapat meminta CVE-ID.
      1. Komitment menerapkan perbaikan juga dijadikan rujukan di masa mendatang dan menyertakan CVE-ID.
  3. Jika proses Incident Response pada bagian III *tidak* berhasil diselesaikan:
    1. Response Team dan pengembang mengatur pertemuan IRC untuk membahas mengapa poin di bagian III tidak terselesaikan dan bagaimana tim dapat menyelesaikannya di masa mendatang.
    2. Setiap pertemuan pengembang yang diadakan segera setelah kejadian tersebut harus mencakup poin yang dibuat di bagian V.
    3. Jika perselisihan timbul tentang apakah harus mengungkapkan informasi tentang kerentanan atau kapan mengungkapkan kerentanan, Response Team akan mendiskusikan masalah ini melalui IRC dan berusaha mencapai konsensus.
    4. Jika konsensus mengenai waktu pengungkapan tidak terpenuhi (selambat-lambatnya 90 hari), peneliti (setelah 90 hari) memiliki hak untuk mengekspos kerentanan kepada publik.

V. Incident Analysis

  1. Isolate codebase
    1. Response team dan pengembang harus berkoordinasi untuk mengerjakan hal-hal berikut:
      1. Implementasi bermasalah pada classes/libraries/functions, dll.
      2. Fokus pada aplikasi/distro packaging, dll.
      3. Operator/config error, dll.
  2. Auditing
    1. Response team dan pengembang harus berkoordinasi untuk mengerjakan hal-hal berikut:
      1. Mengaudit area masalah(-masalah) sebagaimana dibahas pada butir 1.
      2. Buat laporan internal dan simpan referensi untuk masa mendatang.
      3. Jika hasil tidak sensitif, bagikan dengan publik melalui IRC atau public Trac.
  3. Response Team memiliki 45 hari setelah selesainya bagian III untuk memastikan penyelesaian seksi V.

VI. Resolutions

Pertanyaan atau resolusi lebih lanjut mengenai insiden antara tim peneliti dan tim pengembang + respon setelah pengungkapan publik dapat ditangani melalui:

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

VII. Perbaikan terus-menerus

  1. Response Team dan pengembang harus mengadakan pertemuan tahunan untuk meninjau insiden tahun sebelumnya.
  2. Response Team atau orang(-orang) yang ditunjuk harus memberikan presentasi singkat, termasuk:
    1. Area I2P yang terkena dampak insiden.
    2. Setiap downtime jaringan atau biaya moneter (jika ada) dari kejadian tersebut.
    3. Cara-cara di mana insiden bisa dihindari (jika ada).
    4. Seberapa efektif proses ini dalam menghadapi insiden tersebut.
  3. Setelah presentasi, Response Team dan pengembang harus mendiskusikan:
    1. Potensi perubahan pada proses pengembangan untuk mengurangi insiden di masa depan.
    2. Potensi perubahan pada proses ini untuk memperbaiki respons di masa depan.