Berbagai masalah keamanan ditemukan di GNU Screen

 (openwall.com)
2 poin oleh GN⁺ 2025-05-14 | 1 komentar | Bagikan ke WhatsApp
  • Kerentanan keamanan serius ditemukan pada GNU Screen 5.0.0 dan instalasi setuid-root
  • Isu utama mencakup eskalasi hak akses root lokal, pembajakan TTY, dan pembuatan PTY yang bisa ditulis semua orang
  • Banyak distribusi Linux dan UNIX terdampak sebagian atau seluruhnya
  • Patch sementara telah disediakan dan banyak distribusi perlu mengambil tindakan prioritas
  • Desain setuid-root Screen sendiri memiliki risiko keamanan mendasar

1. Pendahuluan

  • Pada Juli 2024, peninjauan keamanan dimulai ketika maintainer upstream Screen meminta code review
  • Sebelumnya tidak ditemukan masalah berarti, tetapi kali ini ditemukan kerentanan eskalasi hak akses root yang serius saat Screen 5.0.0 dijalankan dengan konfigurasi setuid-root
  • Selain itu, juga dikonfirmasi adanya sejumlah kerentanan keamanan yang lebih ringan yang memengaruhi versi sebelumnya (4.9.1 dan lainnya)
  • Laporan ini melampirkan set patch kerentanan per versi (4.9.1, 5.0.0)
  • Termasuk konfigurasi dan versi Screen per distribusi, kerentanan utama, risiko pengembangan terkait setuid-root, rekomendasi hardening keamanan, masalah dalam proses koordinasi pengungkapan, dan matriks dampak

2. Gambaran konfigurasi dan versi Screen

  • Pada Agustus 2024, Screen 5.0.0 dirilis dan disertakan di Arch Linux, Fedora 42, NetBSD 10.1
  • Versi 5.0.0 mencakup banyak refactoring, sebagian di antaranya berasal dari kode yang telah ada lebih dari 10 tahun
  • Sebagian kerentanan baru diperkenalkan di 5.0.0, dan sebagian lainnya juga ada di versi sebelumnya (4.9.1 dan lainnya)
  • Sebagian besar distribusi masih menggunakan 4.9.1
  • Mode multiuser Screen hanya dapat digunakan bila diinstal sebagai setuid-root, dan karena kompleksitas kodenya, permukaan serangannya meningkat besar
  • Di antara distribusi utama, Arch Linux, FreeBSD, dan NetBSD memasang Screen sebagai setuid-root; Gentoo hanya dapat memasangnya sebagai setuid-root melalui flag USE “multiuser”

3. Rincian isu keamanan

3.a) Perolehan root lokal melalui logfile_reopen() (CVE-2025-23395)

  • Saat Screen 5.0.0 dijalankan sebagai setuid-root, fungsi logfile_reopen() membuat file dari path masukan pengguna tanpa melepaskan hak istimewa terlebih dahulu
  • Penyerang dapat membuat file arbitrer yang dimiliki root untuk merekam dan menyalahgunakan data terminal
  • File yang sudah ada juga dapat disalahgunakan; misalnya, serangan seperti penyisipan kode ke shell script berprivilege dapat dilakukan
  • Arch Linux, NetBSD 5.0.0 sepenuhnya rentan, dan lingkungan tertentu di Fedora serta Gentoo rentan sebagian
  • Patch diterapkan dengan memulihkan secure file handling, dan ada dampak spesifik per distribusi

3.b) Pembajakan TTY saat menghubungkan sesi multiuser (CVE-2025-46802)

  • Di fungsi Attach(), ketika flag multiattach aktif, izin TTY sementara diubah menjadi 0666
  • Dalam proses ini, karena race condition, pengguna pihak ketiga dapat memperoleh akses baca/tulis ke TTY tersebut
  • Ada risiko penyadapan data masukan, manipulasi data, pencurian kata sandi, dan lain-lain
  • Ada juga jalur kode di mana izin TTY tidak dipulihkan ke keadaan semula
  • Patch diterapkan dengan menghapus manipulasi chmod 666; meski beberapa use case reconnect dapat rusak, perilaku itu sebelumnya juga tidak berfungsi

3.c) Kerentanan izin bawaan PTY (CVE-2025-46803)

  • Di 5.0.0, izin bawaan PTY berubah dari 0620 → 0622 (dapat ditulis semua orang)
  • Risiko potensial keamanan meningkat, khususnya karena semua pengguna bisa menulis ke PTY milik pengguna lain
  • Perubahan ini tampaknya masuk secara tidak sengaja, dan patch memperbaikinya dengan memulihkan safe default (0620) saat kompilasi
  • Arch Linux, NetBSD menjadi target dampak utama

3.d) Kebocoran informasi keberadaan file melalui pesan galat socket (CVE-2025-46804)

  • Dengan memanfaatkan variabel lingkungan SCREENDIR dan pesan Error, keberadaan file/direktori nyata dapat diperiksa dengan hak root
  • Ini adalah kebocoran informasi minor, tetapi berisiko pada semua lingkungan instalasi setuid-root

3.e) Race condition TOCTOU dalam pengiriman sinyal (CVE-2025-46805)

  • Karena jeda waktu antara fungsi CheckPid() dan Kill(), ada risiko sinyal dikirim dengan hak root ke PID yang berbeda dari yang dimaksud
  • Umumnya hanya sinyal seperti SIGCONT, SIGHUP, dan sejenisnya yang diizinkan, sehingga dampaknya terbatas, tetapi tetap dapat menyebabkan denial-of-service (DoS) atau kerusakan integritas ringan

3.f) Overflow saat pengiriman perintah akibat penggunaan strncpy() yang salah

  • Di 5.0.0, penggunaan strncpy() yang salah menyebabkan buffer overflow dan crash program
  • Jika tidak ditambal dengan benar, memori setelah MAXPATHLEN dapat tertimpa saat pengiriman perintah, yang berujung pada kondisi layanan tidak tersedia
  • Ini bukan masalah keamanan, tetapi tetap perlu segera diperbaiki demi stabilitas

4. Risiko tambahan terkait implementasi setuid-root

  • Dikonfirmasi adanya kelemahan logika penanganan UID banyak pengguna dalam mode multiuser
  • Logika drop privilege dalam status setuid-root tidak lengkap
  • Pada sesi yang dibuat oleh root, penurunan hak akses efektif tidak dilakukan dengan semestinya sehingga secara keseluruhan risikonya tinggi

5. Rekomendasi umum untuk memperkuat keamanan

  • Dalam proses refactoring kode skala besar, terkonfirmasi bahwa logika keamanan yang sudah ada runtuh
  • Mengingat karakteristik biner setuid-root, perlu diperkenalkan test suite keamanan serta semua penanganan filesystem/variabel lingkungan dirancang secara konservatif
  • Khususnya, eksekusi penuh setuid-root tidak direkomendasikan, dan fitur multi-user sebaiknya dibatasi hanya lewat mekanisme opt-in untuk grup tepercaya
  • Variabel lingkungan (PAH dan lainnya) harus diwajibkan hanya menunjuk ke path tepercaya

6. Masalah dalam proses koordinasi pengumuman kerentanan

  • Proses koordinasi dengan upstream berjalan tidak efisien, sehingga pengembangan patch dan pengungkapan mengalami keterlambatan
  • Karena kurangnya pemahaman kode dan kapasitas di pihak upstream, respons yang erat sulit dilakukan
  • Pada akhirnya, pihak distribusi memimpin pengembangan patch, dan laporan dipublikasikan sesuai jadwal yang telah dikoordinasikan
  • Juga terkonfirmasi adanya kekurangan kapasitas pemeliharaan dan pengelolaan pada proyek Screen itu sendiri

7. Matriks dampak

  • Arch Linux (5.0.0, setuid-root): terdampak semua kerentanan 3.a, 3.b, 3.c, 3.d, 3.e, 3.f
  • Debian/Ubuntu dan banyak distribusi lain: 3.b (dampak sebagian)
  • Fedora 42 (5.0.0, setgid-screen): terdampak 3.b (dampak sebagian), 3.f
  • Gentoo (4.9.1, setgid-utmp): 3.b (dampak sebagian), dan pada ebuild unstable + flag USE multiuser terdampak sama seperti 5.0.0
  • FreeBSD 14.2 (4.9.1, setuid-root): terdampak 3.b, 3.d, 3.e
  • NetBSD 10.1 (5.0.0, setuid-root): terdampak 3.a, 3.b, 3.c, 3.d, 3.e, 3.f
  • OpenBSD 7.7 (4.9.1): 3.b (dampak sebagian)
  • openSUSE TW: 3.b (dampak sebagian)

8. Jadwal

  • 2024-07-01: menerima permintaan code review dari upstream
  • 2025-01-08: mulai review
  • 2025-02-07: melaporkan kerentanan ke upstream secara privat, meminta pengungkapan terkoordinasi
  • 2025-02~04: diskusi patch berlangsung, jadwal disesuaikan ulang karena isu periode embargo
  • 2025-05-12: laporan ini dan pengumuman resmi dipublikasikan

9. Tautan referensi

  • GNU Savannah [halaman proyek Screen]
  • openSUSE Bugzilla, patch terkait, CVE referensi, laporan bug, dan tautan dokumentasi

Bacaan terkait

1 komentar

 
GN⁺ 2025-05-14
Opini Hacker News
  • Screen memiliki mode multi-user yang memungkinkan beberapa pengguna masuk ke sesi yang sama; saya rasa fitur inilah yang memungkinkan alat seperti tmate, dan saya penasaran apakah tmux punya kerentanan yang sama
    • tmux menggunakan Unix domain socket; saya tidak paham kenapa screen memakai pendekatan setuid, sepertinya tidak butuh hak root; menurut penjelasan di TFA, tampaknya pengembang screen saat ini belum sepenuhnya memahami codebase sehingga memilih cara setuid-root karena lebih mudah untuk mengimplementasikan fungsinya
    • Fitur ini benar-benar hebat; dalam sesi pelatihan, saya memberi tiap siswa akun login mereka sendiri di laptop saya dan membatasi shell ssh ke 'screen -x <jendela pengguna tertentu>' agar siswa hanya bisa memakai jendela yang diizinkan oleh ACL screen tersebut; saya lalu menampilkan layar tiap siswa satu per satu lewat proyektor; tapi tidak mengejutkan kalau ternyata ini penuh lubang keamanan
    • Saya pernah memakai perintah screen -x
  • Di Debian, GNU screen tidak dipasang dengan hak setuid root
    • Paket Debian Stable (bookworm) sudah terlalu lama sehingga tidak terdampak oleh kerentanan 5.0.0; dulu saya tidak suka karena Debian terlalu lambat dalam versi software, tapi sekarang saya hanya memakai sumber paket terpisah untuk beberapa aplikasi yang memang perlu versi baru, dan sisanya tetap baik-baik saja dengan versi lama
    • Gentoo juga sama, tapi di Gentoo ada SETGID pada grup utmp; saya tidak terlalu paham artinya apa
    • Di Slackware 15, screen tidak memiliki suid
    • Di Fedora, tampaknya dipasang sebagai setuid
  • Memperkenalkan versi blog yang sudah dirender: https://security.opensuse.org/2025/05/12/screen-security-issues.html
  • Saya mengirim email ke penulis artikel karena dokumentasi tentang fitur pencatatan file log GNU Screen kurang memadai; saya rasa GNU butuh sistem pelacakan isu yang lebih baik; referensi terkait: http://www.zoobab.com/screenrc
  • observed behaviour sudah ada di Screen sejak 2005; ini adalah anti-pattern yang lama ditutupi oleh alat seperti rkhunter; saya yakin screen sudah setuid root sejak era 90-an
  • Cukup mengejutkan bahwa upstream (tim pengembang resmi) terlibat kali ini; sekitar 5 tahun lalu saya sedih karena pengembangan GNU screen tampaknya benar-benar berhenti; penasaran apakah masih begitu sekarang, dan apakah ada fitur untuk menambahkan jendela baru ke screen tanpa melakukan attach ke layar
    • upstream-lah yang meminta tim SUSE melakukan peninjauan; tenaga pengembang kurang dan saat ini pemeliharaannya tampaknya kurang baik; kalau memang begitu, sayang sekali; meski ada pengganti seperti tmux, banyak orang sudah lama memakai Screen, jadi menyedihkan melihat alat mengalami penuaan
    • Satu-satunya keterlibatan mereka adalah mendistribusikannya sebagai setuid-root; hanya distro yang mengaturnya seperti ini yang rentan, yang lain tidak terdampak; saat patch resmi lambat, distro biasanya menambal sendiri
    • Saya tidak menganggap berhentinya pengembangan alat GNU (kecuali perbaikan bug) selalu buruk; itu bisa jadi tanda bahwa fiturnya sudah cukup matang
    • Sulit berkomunikasi dengan upstream, jadi saya tidak punya informasi rinci soal bug fix/rilis; permintaan peninjauan keamanan memang diajukan, tapi tampaknya sulit menghubungi mereka
    • Dalam open source, bahkan ketika sebuah software sudah selesai dan ada penggantinya, sering tidak ada insentif cukup besar untuk langsung beralih sehingga muncul inersia; sebaliknya, ada juga kasus ketika hanya mereknya yang dibeli lalu diubah total jadi sesuatu yang berbeda (seperti Audacity); belum ada solusi yang bagus
  • Tautan versi yang sudah dirender: https://security.opensuse.org/2025/05/12/screen-security-issues.html
  • Saya penasaran berapa banyak pengembang yang benar-benar memakai sendiri semua alat open source populer ini, dan seberapa banyak uang yang berputar di bidang yang memakai alat-alat tersebut
  • Seingat saya, tmux masuk ke bawaan OpenBSD sejak 4.6 dan sudah diaudit; ini alternatif yang baik bagi orang yang lebih peduli pada keamanan
    • Melihat screen disebut membuat saya ingat pernah beralih ke tmux di masa lalu, lalu tanpa sengaja jadi tidak memakai screen lagi sampai sempat bingung sendiri
  • Menarik melihat screen dan setuid disebut bersamaan; saya pernah memberi chmod u+s ke screen saat mencoba menyelesaikan masalah aneh, dan rasanya janggal harus melakukan itu; tapi kemudian saya tahu screen memang punya fitur yang bergantung pada setuid dan di beberapa sistem memang didistribusikan seperti itu; lalu setelah diberi u+s, screen membaca ~/.screenrc milik root alih-alih ~/.screenrc saya (saya anggap sebagai solusi sementara); saya menduga tiap build screen bisa berbeda dalam dukungan setuid
    • Memang begitu cara kerja setuid; saat bit khusus disetel pada biner, artinya program itu selalu dijalankan sebagai user yang ditentukan