iTerm2 Mengumumkan Pembaruan Keamanan Kritis

 (iterm2.com)
2 poin oleh GN⁺ 2025-01-03 | 2 komentar | Bagikan ke WhatsApp
  • iTerm2 3.5.11 adalah rilis yang dibangun pada 2 Januari 2025, dan pembaruan segera direkomendasikan karena adanya perbaikan keamanan kritis terkait integrasi SSH
  • Cakupan dampaknya mencakup pengguna 3.5.6~3.5.10 yang menggunakan fitur integrasi SSH serta semua versi beta setelah 3.5.6
  • Jika bug terjadi, input dan output akan dicatat ke /tmp/framer.txt di host jarak jauh, dan pengguna lain pada host jarak jauh yang sama dapat membaca file ini
  • Kondisinya adalah saat menggunakan it2ssh atau ketika Command di profil adalah "SSH" dan "SSH Integration" dipilih, serta Python 3.7 atau lebih baru tersedia di jalur pencarian default host jarak jauh
  • Pengguna harus meningkatkan ke 3.5.11 lalu menghapus /tmp/framer.txt di host jarak jauh yang terdampak

Cakupan Dampak dan Kondisi Terjadi

  • iTerm2 3.5.11 adalah rilis yang mencakup perbaikan keamanan kritis dan disarankan untuk segera diperbarui
  • Versi yang dapat terdampak adalah versi berikut yang menggunakan fitur integrasi SSH
    • 3.5.6
    • 3.5.7
    • 3.5.8
    • 3.5.9
    • 3.5.10
    • semua versi beta setelah 3.5.6
  • Bug ini menyebabkan fitur integrasi SSH menulis input dan output ke /tmp/framer.txt di host jarak jauh
    • File ini mungkin dapat dibaca oleh pengguna lain di host jarak jauh tersebut
  • Masalah terjadi ketika semua kondisi berikut terpenuhi
    • menggunakan perintah it2ssh
    • atau di Settings > Profiles > General, menu pop-up Command disetel ke "SSH", dan "SSH Integration" dipilih di dialog pengaturan SSH
      • pengaturan "Login Shell", "Command", "Custom Command" tidak termasuk dalam kondisi tersebut
    • Python 3.7 atau lebih baru terpasang di jalur pencarian default host jarak jauh

Pembaruan dan Verifikasi

  • Pengguna harus segera meningkatkan ke iTerm2 3.5.11
  • Di host jarak jauh yang terdampak, file /tmp/framer.txt harus dihapus
  • Kode yang menulis file log pada integrasi SSH telah dihapus dan tidak akan dirilis lagi dalam rilis publik
  • Nilai SHA-256 untuk file zip adalah sebagai berikut
    • 655e32b4a9466104f1b0d8847e852515bc332bdf434801762e01b9625caa43e2
  • Untuk memverifikasi file zip, https://keybase.io/verify dapat digunakan

Bacaan terkait

2 komentar

 
xguru 2025-01-03

Saya kaget ketika mengecek, ternyata versiku adalah 3.4.3. Akhir-akhir ini saya jarang pakai terminal, jadi saya juga kurang memperhatikannya, dan karena itu update pun jadi jarang dilakukan.
 
GN⁺ 2025-01-03
Pendapat di Hacker News

  • Ini terlihat seperti kasus debugging dengan print() yang masuk ke produksi
    https://github.com/gnachman/iTerm2/commit/63ec2bb0b95078a97a...
    https://github.com/gnachman/iTerm2/blame/5db0f74bf647f6d53ea...

    • Kodenya sendiri bukan sesuatu yang aneh; strukturnya hanya menulis ke file saat mode verbose aktif
      Commit yang mematikan mode verbose adalah commit ini, tepat sebelum seluruh log framer dihapus: https://github.com/gnachman/iTerm2/commit/014ba7ec40fc790f65...
      Commit yang mengaktifkan mode VERBOSE ada di sini: https://github.com/gnachman/iTerm2/commit/5db0f74bf647f6d53e...
      Kemungkinan saat implementasi atau debugging, mereka mengubahnya ke VERBOSE=1 lalu lupa mengembalikannya ke VERBOSE=0 sebelum commit
    • Dalam pengembangan TypeScript, kami menjadikan console.log sebagai error lint sehingga tidak bisa di-merge, dan sesekali saat ada kebutuhan yang sah kami memakai console.info
      Debugging dengan print itu sendiri tidak masalah dan ada waktunya untuk dipakai, tetapi sebaiknya ada pengaman agar tidak tertinggal tanpa sengaja. Ini kesalahan yang sangat mudah terjadi
    • Jadi ini sudah ada selama 3 tahun?

  • Cukup serius bahwa akibat bug pada fitur SSH integration, input dan output dicatat ke file /tmp/framer.txt di host jarak jauh, dan file itu juga bisa dibaca oleh pengguna lain di host jarak jauh tersebut
    File seperti ini mungkin juga masih tertinggal di mesin yang dulu pernah diakses lewat SSH, tetapi sekarang sudah tidak punya izin akses lagi

    • Syarat terjadinya harus memenuhi keduanya
      1. Saat memakai perintah it2ssh, atau saat menu pop-up Command di Settings > Profiles > General disetel ke "SSH" dan "SSH Integration" dicentang. "Login Shell", "Command", dan "Custom Command" tidak termasuk
      2. Python 3.7 atau lebih baru harus terpasang di path pencarian default host jarak jauh
    • Bug ini sepertinya hampir tidak akan terjadi. Karena ini adalah fitur yang sangat khusus, sampai-sampai 99% orang di sini mungkin belum pernah mendengar atau memakainya
      Namun jika Anda tipe orang yang memakai ssh sebagai perintah terminal default alih-alih bash atau zsh, kemungkinan besar Anda juga memakai banyak fitur tidak biasa di aplikasi lain, jadi Anda perlu memperhatikan permukaan serangan lain, bukan hanya iTerm

  • Saya sudah lama memakai iTerm2 dengan baik untuk pekerjaan dan keperluan pribadi, dan saya akan terus memakainya serta berniat berdonasi lagi seperti dulu

  • Saya selalu sedikit menghela napas saat melihat kalimat seperti “Saya sangat menyesali kesalahan ini dan akan mengambil langkah agar hal seperti ini tidak terjadi lagi”
    Intinya adalah langkah apa yang akan diambil, tetapi saya juga tidak yakin apa yang perlu dilakukan agar hal seperti ini tidak terulang. Mungkin bisa dibuat alat otomatis yang menjalankan semua fitur, menangkap system call, lalu memastikan tidak ada file yang dibuka atau ditulis, tetapi untuk aplikasi GUI itu tampak terlalu sulit sampai-sampai sepertinya tidak akan dicoba. Dengan langkah yang lebih ringan dari itu, rasanya sulit menjamin hal ini tidak terjadi lagi

    • Banyak sekali uang sudah digelontorkan untuk fuzzing Chrome/Chromium, tetapi tetap saja setiap tahun masih ditemukan puluhan kerentanan serius. Produk besar lain juga sama
      Secara realistis, tampaknya sulit bagi programmer untuk melakukan jauh lebih baik dari itu, jadi tidak adil jika semua tanggung jawab ditimpakan kepada satu orang ini
    • Dari singkatnya pengumuman keamanan itu, sepertinya penulis ingin mengungkap detail terkait insiden secepat mungkin
      Namun menurut saya, singkatnya tulisan tidak berarti ia tidak memahami besarnya kesalahan. Meski begitu, saya berharap nantinya akan ada tulisan blog mendalam yang membahas detail lanjutan semacam ini
    • Kalimat ini adalah hal yang paling tidak buruk yang bisa dikatakan, sekaligus juga hal terbaik yang bisa dikatakan
      Tidak meminta maaf akan lebih buruk, dan tidak mengatakan akan mengambil langkah pencegahan juga akan lebih buruk. Kalau semua langkah sudah siap sekarang juga, justru itu aneh. Pertama-tama harus A) memperbaiki bug, B) merilis versi perbaikan, C) mengumumkan bug dan rilis perbaikannya, lalu D) melakukan analisis pascainsiden; jika semua ini dicampur jadi satu, prosesnya akan terlihat kacau
      Mengklaim bisa mencegah semua bug atau semua penulisan file yang tidak disengaja juga aneh. Mustahil membuktikan bahwa sebuah program sama sekali tidak pernah menulis ke file
      Titik awal yang baik adalah menghapus logging SSH seperti yang memang dilakukan, lalu meneliti metode otomatis untuk memverifikasi akses file. Dalam pengembangan macOS ada banyak alat yang jauh melampaui alat umum di ekosistem lain, jadi mungkin ada cara seperti dokumentasi teknis era 1990-an yang menentukan NSArray berisi path yang diizinkan untuk diakses, atau integrasi dtrace bawaan di Instruments. Menjalankannya di CI dan memastikan cakupan tes mungkin sudah mendekati yang terbaik yang bisa dilakukan
      Sepertinya pokok perdebatannya adalah apakah “akan mengambil langkah agar hal seperti ini tidak terjadi lagi” dibaca sebagai “akan mengambil langkah sampai bisa menjamin 100% mutlak selamanya tidak akan pernah terjadi lagi”. Untuk orang-orang muda yang mudah terpengaruh, tulisan blog ini bagus sekali dan hampir tidak ada lagi yang bisa dilakukan lebih baik dari ini
    • Kalau Anda software engineer, hal seperti ini akan terus terjadi, terlepas dari skalanya. Pada akhirnya orang akan membuat kesalahan
      Langkah yang bisa dilakukan adalah menjadikan kejadian ini pelajaran agar lebih berhati-hati saat masuk ke jalur tersebut
    • Di komentar lain ada yang menyebut pendekatan memakai linter agar PR yang berisi console.log tidak bisa di-merge, dan menurut saya itulah pendekatan yang akan saya ambil
      Mencegah state yang tidak valid agar tidak mungkin ada adalah prinsip yang cukup berguna

  • Pada umumnya ini mungkin soal preferensi pribadi, tetapi pada 2025 apakah ada alasan yang sangat meyakinkan untuk memakai iTerm2 alih-alih Terminal bawaan macOS?
    Saya sering mendapat rekomendasi, tetapi jadi berhati-hati karena khawatir dengan isu keamanan dan privasi seperti bug SSH kali ini

    • Bagi saya fitur kuncinya adalah Edit > Selection Respects Soft Boundaries. Ini memungkinkan menyalin teks di dalam jendela yang didefinisikan di dalam terminal, misalnya di dalam panel split tmux atau emacs, dan iTerm mengenali hal-hal seperti karakter pipe sebagai batas jendela
      Satu lagi adalah jika tanpa sengaja menutup tab atau jendela, lalu dalam beberapa detik menekan ⌘z, jendelanya muncul kembali seolah-olah tidak pernah ditutup
      Dan kontras warna minimum juga bagus. Jika tema warna terminal dan tema warna program yang sedang berjalan tercampur buruk hingga tidak bisa dibaca, iTerm dapat mendeteksinya dan otomatis menimpanya dengan warna berkontras lebih tinggi
      Namun itu hanya fitur kunci bagi saya. iTerm adalah monster bongsor seperti Word dengan ribuan fitur. Tidak semua orang membutuhkan semuanya, tetapi juga tidak ada kesepakatan soal fitur mana yang dibutuhkan
    • Saya tadinya mau bertanya apakah Terminal sama sekali tidak pernah punya isu keamanan, lalu mencoba mencari halaman catatan rilisnya, tetapi tidak menemukannya
      Saya juga mencari terminal di beberapa catatan rilis macOS, tetapi tidak menemukan apa pun. Ada yang tahu informasi ini dipublikasikan di mana? Atau memang tidak dipublikasikan?
      [1] https://developer.apple.com/documentation/macos-release-note...
      [2] https://support.apple.com/en-us/120283
      [3] https://support.apple.com/en-in/109035
      [4] https://support.apple.com/en-us/106337
    • Satu-satunya alasan saya beralih ke iTerm2 adalah karena saya ingin warna terminal berubah saat terhubung ke host lain lewat SSH
      Saya ingin warnanya berubah menjadi biru saat SSH ke mesin kantor, dan ungu saat SSH ke mesin rumah. Saya juga mencoba melakukannya di terminal bawaan, tetapi ada masalah membingungkan tergantung bagaimana sesi berakhir, dan orang-orang merekomendasikan iTerm2 karena katanya menyelesaikan ini. Setidaknya dalam kasus saya, memang terselesaikan
    • Saya sudah memakai Kitty(https://sw.kovidgoyal.net/kitty) sebagai terminal utama selama beberapa tahun, dan jika dipakai bersama tmux hasilnya luar biasa
      Saya juga sering mendengar https://ghostty.org/ bagus, tetapi belum sempat mengeceknya
      Sebagai tambahan, saya salah membaca pertanyaannya sebagai “apa saja alternatifnya”
    • Pada akhirnya ini bergantung pada sudah berapa lama Anda memakai macOS dan kebiasaan kecil serta keanehan apa yang terbentuk
      Bagi saya, kemampuan memakai mode layar penuh dengan cara yang berbeda dari layar penuh native macOS saja sudah bernilai. Namun mungkin di dunia ini hanya ada sekitar tujuh orang yang menganggap hal itu penting

  • Saya sangat bersimpati pada pengembang yang mengembangkan iTerm dengan dana yang relatif kecil. Ia juga sudah menerima kritik lebih banyak dari yang semestinya karena integrasi AI
    Pada saat yang sama, sekarang saya sangat khawatir apakah saya masih boleh terus memakai iTerm
    Saat mengakses lingkungan HPC, aksesnya bisa saja hanya diberikan untuk periode singkat, data harus dibersihkan sendiri setelah digunakan, dan kita berharap tidak ada kebocoran data. Jika selama setahun terakhir saya menggunakan integrasi SSH iTerm saat menangani data riset pribadi, itu akan menjadi masalah. Saya mungkin harus mengirim email memalukan kepada admin untuk meminta mereka memeriksa apakah ada log dan apakah itu milik saya, lalu setelahnya harus mengumumkan bahwa data telah bocor
    Saya memang memakai beberapa fitur lanjutan, tetapi sekarang jadi bertanya-tanya apakah aman memakai apa pun di luar fitur dasar. Kalau begitu, rasanya saya bisa saja memakai terminal lain. Saya belum menemukan terminal lintas platform yang terasa senative iTerm di MacOS, termasuk Ghostty

    • Saya sangat merekomendasikan wezterm
    • Apakah satu isu sepanjang waktu panjang keberadaannya menjadi alasan untuk pindah ke terminal lain?
      Ini mirip seperti membuang mobil hanya karena ban pernah bocor sekali. Dengan mempertimbangkan keunggulan dan fiturnya, iTerm mungkin tetap menjadi pilihan terbaik
    • Jika Anda seorang peneliti, menjaga lingkungan komputasi yang aman bukanlah tanggung jawab pribadi
      Jika setiap individu harus memverifikasi sendiri keamanan seluruh sistem dan semua software yang digunakan, berarti organisasi itu tidak memiliki keamanan
      Administrator sistem yang kompeten dan memahami keamanan dapat dengan mudah mengatur agar file yang dibuat melalui SSH tidak secara default memiliki izin yang bisa dibaca semua orang. Mereka juga bisa menambahkan mekanisme penguncian lain untuk mengisolasi file pengguna sepenuhnya, dan bahkan menonaktifkan folder yang bisa ditulis secara global seperti /tmp/
      Jika ada yang menyalahkan seseorang karena memakai software yang rentan secara keamanan, seharusnya tanyakan balik mengapa sistem mereka begitu rentan secara keamanan
    • Saya memakai Prompt dari Panic

  • Beberapa tahun lalu saya melaporkan masalah iTerm2 yang membocorkan riwayat pencarian sensitif ke file konfigurasi, dan masalah itu cepat diperbaiki
    Namun sampai sekarang masih bisa ditemukan orang-orang yang tanpa sengaja membocorkan riwayat pencarian di repositori dotfiles publik
    [1]: https://gitlab.com/gnachman/iterm2/-/issues/8491
    [2]: https://github.com/search?q=NoSyncSearchHistory+path%3A*.pli...

  • Saran “jangan pakai iTerm2 saja” agak sulit saya pahami
    Masalah seperti ini bisa terjadi di proyek mana pun, dan mengganti alat tidak memberi perlindungan yang berarti. Justru setelah insiden seperti ini, praktik keamanan sering kali menjadi lebih kuat. Mirip lelucon lama tentang apakah akan memecat engineer yang membuat kesalahan, lalu manajernya menjawab, “Kenapa dipecat? Dia baru saja mendapat pelajaran yang tak akan terlupakan”
    Melihat rekam jejak iTerm2, sepertinya tidak sering ada isu keamanan yang fatal, dan kecil kemungkinan mereka mengulangi kesalahan yang sama. Kalau itu berulang, barulah dievaluasi lagi
    Aplikasi Terminal macOS mungkin terlihat berisiko lebih rendah karena lebih sederhana dan lebih jarang diperbarui. Namun karena closed source, ia tidak bisa diaudit, dan itu punya risikonya sendiri. Pada akhirnya semua alat punya trade-off, dan pilihan harus menyeimbangkan fitur yang dibutuhkan dengan potensi risikonya

    • Apakah menurut Anda praktik pengembangan memengaruhi tingkat kemunculan bug keamanan? Dan apakah riwayat masa lalu mencerminkan tingkat kemunculan bug keamanan itu?
      Banyak orang menganggap kedua hal ini sebagai keyakinan yang masuk akal. Itu pandangan yang jauh lebih bernuansa daripada sekadar “semua proyek bisa punya bug”. Sudut pandang hitam-putih seperti itu tidak banyak membantu dalam penilaian risiko

  • iTerm2 terasa makin terlalu kompleks dan membengkak, dan isu keamanannya juga tampak terlalu banyak
    Sudah lama saya tidak mencari emulator terminal baru di macOS, tapi sepertinya sekarang waktunya
    GNU Screen juga tampaknya stagnan, jadi mungkin sudah saatnya melakukan hal yang selama ini tertunda: beralih ke tmux

    • Belakangan saya mencoba Ghostty dan sejak itu sepenuhnya pindah dari iTerm2. Rasanya familier sekaligus matang
    • “Terlalu kompleks” dan “membengkak” adalah ungkapan serbaguna, jadi perlu dijelaskan lebih spesifik
      Secara pribadi, saya tidak merasa iTerm2 termasuk salah satu dari keduanya
    • Saya cukup sering memakai integrasi tmux di iTerm2. Itu membuat scroll mouse di jendela tmux terasa natural
      Saya belum melihat terminal lain yang menyediakan dukungan tmux setara
    • Saya sudah memakai Terminal.app sejak 10.0, dan tidak pernah merasa perlu menggantinya
      Apa yang kurang dari Terminal sehingga memakai aplikasi lain akan memperbaiki penggunaan sehari-hari?
    • Masih memakai GNU Screen? GNU Screen maupun tmux pernah punya isu keamanan di masa lalu, tetapi GNU Screen lebih parah, jadi saya pindah
      Zellij adalah terminal multiplexer yang dibuat dengan Rust dan layak dilihat. Terutama karena key binding-nya mudah ditemukan, itu sangat bagus. Bentuknya mendekati TUI yang selama ini saya bayangkan

  • Ini hanya berlaku untuk integrasi SSH, bukan saat sekadar menjalankan "ssh" di iTerm, kan?
    Di host yang saya akses dengan ssh biasa, saya tidak menemukan file /tmp/framer.txt

    • Dari catatan rilis, sepertinya ini hanya berlaku saat memakai integrasi SSH bawaan, dan ketika server memiliki versi Python yang relatif baru
      Kondisi kedua kemungkinan besar juga terpenuhi di distro enterprise. Misalnya, RHEL 9 memasang Python 3.9 secara default