Berbagai Masalah Keamanan Ditemukan di GNU Screen

• Tinjauan keamanan GNU Screen menemukan eskalasi hak akses lokal, pembajakan TTY, paparan informasi, kondisi race pengiriman sinyal, dan crash pengiriman perintah, terutama pada Screen 5.0.0 dan instalasi setuid-root
• Yang paling serius, CVE-2025-23395, terjadi karena logfile_reopen() memproses path yang diberikan pengguna dengan hak akses root, sehingga memungkinkan pembuatan file milik root di lokasi sembarang atau menambahkan log ke file yang sudah ada
• Perilaku lama pada mode multiuser juga terbukti bermasalah; Attach() sementara mengubah TTY menjadi 0666, membuka kemungkinan pengguna lain membaca/menulis dan menyuntikkan input
• Risiko per distribusi bergantung pada cara instalasinya; Arch Linux dan NetBSD 10.1 menyediakan Screen 5.0.0 sebagai setuid-root sehingga sangat terdampak oleh kerentanan utama
• Rekomendasi saat ini adalah tidak memasang Screen sebagai setuid-root; fitur multiuser memerlukan opt-in berbasis grup tepercaya, penurunan hak akses secara default, eskalasi hak akses terbatas, dan pembersihan variabel lingkungan

---

Latar belakang pengungkapan dan patch

• Pada Juli 2024, pengelola upstream Screen meminta peninjauan codebase saat ini, dan tinjauan keamanan sebenarnya dimulai pada Januari 2025
• Hasil tinjauan menemukan eksploit root lokal yang memengaruhi distribusi setuid-root pada pembaruan besar Screen 5.0.0
• Selain itu ditemukan masalah dengan tingkat keparahan lebih rendah, dan sebagian juga memengaruhi Screen 4.9.1 serta versi sebelumnya yang masih ada di banyak distribusi
• Masalah-masalah tersebut dibagikan ke mailing list distros pada 30 April 2025 dan dipublikasikan pada 12 Mei 2025
• Laporan menyertakan kumpulan patch per versi
  • screen-4.9.1-patches.tar.gz
  • screen-5.0.0-patches.tar.gz

Konfigurasi Screen dan mode multiuser

• Screen 5.0.0 dirilis upstream sebagai rilis besar pada Agustus 2024, dan versi ini disediakan oleh Arch Linux, Fedora 42, serta NetBSD 10.1
• Banyak distribusi Linux dan UNIX masih menggunakan Screen 4.9.1 pada saat penulisan
• Mode multiuser Screen memungkinkan pengguna lain melakukan attach ke sesi Screen milik pengguna lain jika memiliki kredensial yang sesuai
  • Fitur ini hanya tersedia jika Screen dipasang dengan bit setuid-root
  • Karena kode Screen yang kompleks berjalan dengan hak akses root, permukaan serangan menjadi lebih besar
• Di antara sistem yang ditinjau, Arch Linux, FreeBSD, dan NetBSD memasang Screen sebagai setuid-root
• Gentoo Linux menerapkan bit setuid-root jika USE flag "multiuser" diaktifkan
• Sebagian distribusi menggunakan setgid alih-alih setuid
  • Default Gentoo Linux adalah setgid-utmp, yang memungkinkan Screen membuat catatan login di database utmp seluruh sistem
  • Fedora Linux menggunakan setgid-screen, yang memungkinkan Screen meletakkan socket di direktori seluruh sistem /run/screen

CVE-2025-23395: eksploit root lokal pada logfile_reopen()

• CVE-2025-23395 memengaruhi Screen 5.0.0 saat berjalan dengan hak akses setuid-root
• Fungsi logfile_reopen() tidak menurunkan hak akses saat memproses path yang diberikan pengguna
• Pengguna tanpa hak istimewa dapat membuat file di lokasi sembarang dengan atribut berikut
  • Pemilik: root
  • Grup: grup asli pengguna pemanggil
  • Mode file: 0644
• File yang sudah ada juga dapat dieksploitasi
  • Data yang ditulis ke PTY Screen akan di-append ke file tersebut
  • Mode dan kepemilikan file yang sudah ada tidak berubah
• Screen menurunkan hak akses dengan benar saat pertama kali membuka file log, tetapi kemungkinan eskalasi hak akses muncul saat Screen memutuskan file log perlu dibuka ulang
• Dalam pemeriksaan stolen_logfile(), jika link count file log asli menjadi 0 atau ukurannya berubah secara tidak terduga, logfile_reopen() dipanggil
• Kondisi ini dapat dipicu secara sengaja oleh pengguna tanpa hak istimewa
• Patch 0001 untuk Screen 5.0.0 memperkenalkan kembali penanganan file yang aman saat proses membuka ulang file log
• Masalah ini muncul ketika lf_secreopen() dihapus pada commit lama 441bca708bd, dan perubahan tersebut masuk ke rilis 5.0.0

CVE-2025-46802: pembajakan TTY saat attach sesi multiuser

• CVE-2025-46802 terjadi pada fungsi Attach() saat flag multiattach diaktifkan
• Saat attach ke sesi multiuser, Screen mengubah mode TTY saat ini menjadi 0666 dengan chmod()
• Path TTY divalidasi dengan syarat seperti berada di bawah /dev dan isatty(), sehingga perilaku ini saja tidak menjadi eksploit root lokal tersendiri
• Masalahnya adalah selama izin TTY dilonggarkan sementara, muncul kondisi race yang memungkinkan pengguna lain membaca dan menulis TTY tersebut
• Dalam pengujian sederhana berbasis API inotify Linux, skrip Python dapat membuka TTY terdampak setiap dua atau tiga percobaan
• Penyerang dapat melakukan hal berikut
  • Mencegat data yang dimasukkan ke TTY
  • Menyuntikkan data ke TTY
  • Menyesatkan pengguna agar memasukkan kata sandi
  • Menyuntikkan control sequence untuk membingungkan korban atau menargetkan masalah terkait di emulator terminal
• Pada sebagian jalur return di Attach(), mode TTY asli tidak dipulihkan
  • Contoh: ketika sesi target tidak ditemukan dan argumen "quiet" diaktifkan
• Patch menghapus chmod() sementara
  • Patch 0001 untuk Screen 4.9.1
  • Patch 0004 untuk Screen 5.0.0
• Tepat sebelum pengungkapan publik, ditemukan kemungkinan patch ini mematahkan sebagian use case reattach, tetapi use case tersebut ternyata sudah rusak juga di Screen 4.9.1
• Masalah ini sudah ada di versi Screen setidaknya sejak 2005, dan memengaruhi distribusi Linux serta BSD yang menyediakan dukungan multiuser melalui setuid-root
• Bahkan tanpa setuid-root, secara teori pengguna tetap terdampak karena mereka punya hak untuk mengubah mode TTY miliknya sendiri, tetapi Screen tidak akan melanjutkan ke sesi pengguna lain tanpa hak akses root

CVE-2025-46803: default PTY world-writable di Screen 5.0.0

• CVE-2025-46803 adalah masalah perubahan mode default PTY yang dialokasikan Screen dari 0620 menjadi 0622 di Screen 5.0.0
• Dengan default ini, siapa pun di sistem dapat menulis ke PTY Screen
• Dari sisi keamanan, masalahnya mirip dengan CVE-2025-46802, tetapi tanpa aspek kebocoran informasi
• Di Screen 4.9.1, default pada level kode adalah 0622, tetapi default 0620 dari konfigurasi autotools diterapkan sehingga default yang aman digunakan
• Di Screen 5.0.0, configure.ac ditulis ulang sehingga default 0620 pada level autoconf hilang, lalu switch configure pty-mode diperkenalkan kembali dengan default 0622
• Catatan rilis 5.0.0 tidak ditemukan dan hanya ada sebagian entri ChangeLog; perubahan default mode PTY tampaknya bukan keputusan yang disengaja
• Patch 0002 untuk Screen 5.0.0 memulihkan mode PTY default yang aman di configure.ac
  • Untuk menerapkan perubahan, autoreconf perlu dijalankan
• Packager disarankan meneruskan switch configure --with-pty-mode=0620 secara eksplisit
• Gentoo Linux dan Fedora Linux secara eksplisit meneruskan --with-pty-mode yang aman
• Arch Linux dan NetBSD tidak meneruskan switch tersebut sehingga default baru diterapkan dan keduanya rentan

CVE-2025-46804: paparan keberadaan file melalui pesan error path socket

• CVE-2025-46804 adalah kebocoran informasi ringan yang terjadi saat Screen berjalan dengan hak akses setuid-root
• Masalah ini ditemukan baik pada versi Screen lama maupun 5.0.0
• Screen memeriksa SocketPath dengan hak akses root dan mengekspos informasi path yang biasanya tidak dapat diketahui pengguna tanpa hak istimewa melalui pesan error
• Dengan menggunakan variabel lingkungan SCREENDIR, informasi berikut dapat disimpulkan
  • apakah /root/.lesshst adalah file biasa
  • apakah direktori /root/.cache ada
  • apakah path /root/test tidak ada
• Patch mengubah perilaku agar pada instalasi setuid-root hanya menampilkan pesan error umum jika path target tidak dikendalikan oleh UID asli proses
  • Patch 0002 untuk Screen 4.9.1
  • Patch 0005 untuk Screen 5.0.0
• Semua distribusi yang ditinjau terdampak

CVE-2025-46805: kondisi race TOCTOU pada pengiriman sinyal

• CVE-2025-46805 adalah kondisi race TOCTOU yang muncul saat mengirim sinyal ke PID yang diberikan pengguna dalam konteks setuid-root
• CheckPid() menurunkan hak akses ke ID pengguna asli, lalu memeriksa apakah kernel mengizinkan pengiriman sinyal ke PID target
• Sinyal sebenarnya dikirim kemudian melalui Kill(), dan saat itu hak akses root dapat digunakan
• Di antara pemeriksaan dan pengiriman sebenarnya, PID yang sebelumnya diperiksa dapat digantikan oleh privileged process lain
• Ada juga kemungkinan menipu proses daemon Screen yang privileged agar mengirim sinyal ke dirinya sendiri
• Saat ini hanya SIGCONT dan SIGHUP yang dapat dikirim, sehingga dampaknya kemungkinan sebatas denial of service lokal atau pelanggaran integritas ringan
• Masalah ini berasal dari perbaikan CVE-2023-24626 yang tidak lengkap
  • Sebelum perbaikan tersebut, sinyal terkait dapat dikirim ke proses sembarang tanpa kondisi race
• Patch mengubah agar sinyal sebenarnya juga dikirim dengan hak akses UID asli seperti CheckPid()
  • Patch 0003 untuk Screen 4.9.1
  • Patch 0006 untuk Screen 5.0.0
• Semua distribusi yang ditinjau terdampak

Crash pengiriman perintah akibat penggunaan strncpy() di Screen 5.0.0

• Screen 5.0.0 memiliki masalah terkait strncpy() yang tidak dianggap sebagai isu keamanan, tetapi perlu diperbaiki terlebih dahulu
• Pada commit 0dc67256, beberapa pemanggilan strcpy() diganti dengan strncpy()
• strncpy() bukan fungsi untuk penanganan string yang aman, melainkan fungsi yang mem-padding buffer panjang tetap dengan nol; sehingga ia tetap menulis 0 hingga akhir buffer tujuan bahkan setelah byte \0 pertama
• Dalam loop pemrosesan argumen command line di attacher.c, MAXPATHLEN tetap diteruskan sebagai ukuran tujuan setelah iterasi pertama
• Karena pointer p sudah bertambah tetapi ukuran yang sama tetap diberikan, pemanggilan strncpy() berikutnya menulis byte \0 melewati akhir buffer
• Di Arch Linux, saat mengirim lebih dari satu argumen perintah ke sesi Screen yang sedang berjalan, build dengan _FORTIFY_SOURCE aktif menampilkan error berikut
  • *** buffer overflow detected***: terminated
  • Aborted (core dumped)
• Tanpa _FORTIFY_SOURCE, mungkin tidak ada error yang terlihat, dan -fsanitize=address juga mungkin tidak menunjukkan error
• Pemanggil dapat menimpa MAXPATHLEN byte setelah buffer cmd dengan 0, tetapi karena setelahnya ada buffer writeback[MAXPATHLEN] dengan ukuran yang sama, dinilai tidak ada kemungkinan eksploit yang menguntungkan penyerang
• Patch 0003 untuk Screen 5.0.0 mengganti strncpy() dengan snprintf() dan meneruskan ukuran sisa buffer tujuan secara akurat
• Semua distribusi yang menyediakan Screen 5.0.0 terdampak

Cakupan dampak per distribusi

Sistem	Versi Screen	Hak akses khusus	Dampak
Arch Linux	5.0.0	setuid-root	3.a, 3.b, 3.c, 3.d, 3.e, 3.f
Debian 12.10	4.9.0	tidak ada	sebagian 3.b
Ubuntu 24.04.2	4.9.1	tidak ada	sebagian 3.b
Fedora 42	5.0.0	setgid-screen	sebagian 3.b, 3.f
Gentoo	4.9.1	setgid-utmp, setuid-root jika USE flag multiuser diaktifkan	sebagian 3.b
openSUSE TW	4.9.1	tidak ada	sebagian 3.b
FreeBSD 14.2	4.9.1	setuid-root	3.b, 3.d, 3.e
NetBSD 10.1	5.0.0	setuid-root	3.a, 3.b, 3.c, 3.d, 3.e, 3.f
OpenBSD 7.7	4.9.1	tidak ada	sebagian 3.b

Kekhawatiran dan rekomendasi terkait desain setuid-root

• Mode multiuser Screen melibatkan tiga UID
  • effective UID 0 untuk privileged operation
  • UID asli pengguna yang membuat sesi
  • UID asli pengguna yang melakukan attach ke sesi
• Kode Screen saat ini tampaknya memiliki struktur yang menyulitkan pembedaan ini secara tepat
• Sesi multiuser Screen yang dibuat oleh root “menurunkan hak akses” ke 0, yaitu UID asli pembuat sesi, sehingga pada praktiknya tidak terjadi penurunan hak akses
• Dalam proses refactoring Screen 5.0.0, logika keamanan yang sudah lama ada rusak, sehingga muncul CVE-2025-23395 dan CVE-2025-46803
• Sebelum refactoring tambahan, diperlukan test suite yang dapat memverifikasi properti keamanan implementasi
• Pengembang yang menangani binary setuid-root harus memahami risiko area tersebut
• Screen terus berjalan dengan hak akses yang dinaikkan dan hanya menurunkan hak akses secara selektif pada operasi yang dianggap berbahaya
• Program setuid-root yang tangguh seharusnya menurunkan hak akses secara default dan hanya menaikkannya pada operasi yang benar-benar memerlukan hak akses tinggi
• Dalam konteks setuid-root, diperlukan logika untuk menghapus semua variabel lingkungan kecuali yang diizinkan secara eksplisit
• Variabel lingkungan seperti PATH harus dibersihkan agar hanya menunjuk ke direktori sistem tepercaya
• Saat ini, rekomendasinya adalah tidak memasang Screen sebagai setuid-root, bukan hanya Screen 5.0.0 tetapi juga seri 4.9 yang lebih lama
• Sebagai alternatif, fitur multiuser dapat disediakan secara opt-in, dan hanya anggota grup tepercaya yang diizinkan menjalankan versi Screen multiuser

Proses koordinasi pengungkapan dan status upstream

• Pada Februari 2025, masalah dilaporkan secara privat ke upstream Screen dan pengungkapan terkoordinasi diusulkan
• Upstream menunjukkan minat untuk menjaga masalah tetap privat hingga perbaikan bug sebelum publikasi, dan menyampaikan bahwa mereka memerlukan 1–2 bulan
• Sekitar sebulan kemudian aktivitas upstream dan diskusi patch dimulai, tetapi diskusi tersebut tidak cukup produktif
• Hingga mendekati masa embargo maksimum 90 hari, tidak ada komunikasi tambahan; sementara itu distribusi seperti NetBSD memperbarui ke Screen 5.0.0 sehingga sepenuhnya terdampak CVE-2025-23395
• Diputuskan bahwa upstream belum cukup familier dengan codebase Screen dan belum sepenuhnya memahami masalah keamanan yang dilaporkan
• Upstream menginginkan publikasi lebih awal saat sebagian masalah belum terselesaikan, sehingga draf segera dikirim ke mailing list distros
• Setelah itu, pihak SUSE mengembangkan langsung perbaikan yang terlewat, serta menyesuaikan dan mendokumentasikan patch yang sempat dibahas dalam bentuk draf di upstream
• Dengan kapasitas upstream khusus, prosedur pengungkapan terkoordinasi diperkirakan dapat selesai dalam sekitar 2 minggu
• Upstream Screen tampaknya mengalami kekurangan tenaga dan keahlian, yang sangat mengkhawatirkan mengingat ini adalah utilitas open source yang banyak digunakan

Linimasa utama

• 2024-07-01: Permintaan peninjauan dari upstream diterima
• 2025-01-08: Pekerjaan tinjauan keamanan dimulai
• 2025-02-07: Laporan privat dan usulan pengungkapan terkoordinasi dikirim ke upstream Screen
• 2025-02-11: Bug privat dibuat di bug tracker GNU Savannah
• 2025-04-30: Keputusan alokasi CVE dan draf dibagikan ke mailing list distros
• 2025-05-07: Patch final untuk Screen 4.9.1 dan 5.0.0 dibagikan ke mailing list distros dan upstream
• 2025-05-12: Laporan dipublikasikan di blog dan mailing list oss-security

[GN⁺]

Komentar Hacker News

• Saya tidak tahu Screen punya mode multi-pengguna seperti ini, tapi mungkin fitur inilah yang memungkinkan alat seperti tmate
  Dengan kredensial yang sesuai, pengguna lain bisa menempel ke sesi Screen milik pengguna lain, dan konon fitur ini hanya mungkin jika Screen dipasang sebagai setuid-root
  Jadi saya jadi penasaran apakah tmux juga terdampak kerentanan sejenis

  • tmux memakai Unix domain socket, jadi tidak berlaku
    Saya tidak tahu mengapa screen memilih pendekatan setuid di sini; sepertinya tidak perlu hak root sama sekali
    Di bagian bawah tulisan ada penjelasan yang masuk akal bahwa para pengembang screen saat ini tidak sepenuhnya akrab dengan codebase-nya; kalau begitu, mungkin cara termudah untuk membuat fitur ini berjalan adalah setuid-root
  • Ini fitur yang cukup bagus
    Dalam sesi pelatihan, saya pernah memberi tiap siswa akun login di laptop saya, membatasi shell SSH ke screen -x, lalu memakai access control list screen agar tiap siswa hanya bisa memakai jendelanya sendiri
    Selama praktik, sebagai pemilik screen saya bisa menampilkan layar tiap siswa ke proyektor supaya seluruh kelas bisa melihat hasilnya
    Saya tidak akan heran kalau ada banyak lubang keamanan
  • Benar, screen -x

• Di Debian, GNU screen tidak dipasang dengan hak setuid-root

  • Paket di Debian Stable, yaitu bookworm, terlalu lama sehingga tidak terdampak kerentanan 5.0.0
    Dulu saya tidak suka Debian selalu tertinggal versi perangkat lunaknya, tapi sekarang saya baik-baik saja memakai paket lama untuk sebagian besar hal dan hanya memakai sumber paket lain untuk beberapa aplikasi yang saya benar-benar tidak ingin bergantung pada perangkat lunak sangat lama, seperti browser
  • Di Slackware 15, /usr/bin/screen menunjuk ke screen-4.9.0, dan executable-nya juga bukan suid
  • Gentoo juga sama
    Namun di Gentoo ada SETGID untuk grup utmp, dan saya tidak begitu tahu apa dampaknya
  • Di Fedora tampaknya setuid-root

• Artikel blog yang sudah dirender ada di sini: https://security.opensuse.org/2025/05/12/screen-security-iss...

• Saya pernah mengirim email ke penulis GNU Screen karena fitur logging file tidak terdokumentasi dengan baik: http://www.zoobab.com/screenrc
  GNU membutuhkan sistem pelacakan isu yang lebih baik

  • Ada sesi tanya jawab dengan penulis Tmux, dan sekitar 16 tahun lalu pun ia sudah mengeluhkan kurangnya dokumentasi
    https://undeadly.org/cgi?action=article&sid=20090712190402
  • Ini didokumentasikan secara rinci di manual GNU screen: https://www.gnu.org/software/screen/manual/screen.html#Log
  • Banyak proyek lama punya masalah bahwa isu terkubur di kedalaman tak berujung mailing list yang tidak terindeks
    Kritik bahwa Discord membuat informasi semacam ini tidak dapat diakses memang valid, tetapi IRC yang masih dipakai sebagian proyek sebenarnya bisa dibilang dua kali lebih buruk
    Saya berharap proyek-proyek seperti ini pindah ke tempat seperti Gitea, Forgejo, Codeberg, GitLab, atau GitHub agar hal-hal terkait terkumpul di satu tempat dan punya kemudahan ditemukan

• Zellij cukup bagus sebagai alternatif modern untuk screen dan tmux, default-nya juga bagus, dan UI-nya dibuat agar mudah ditemukan
  Saya merekomendasikannya bagi orang yang merasa rasio manfaat terhadap usaha untuk terminal multiplexer kurang jelas
  https://zellij.dev
  https://github.com/zellij-org/zellij

  • Saya mencobanya beberapa tahun lalu dan cukup mulus
    Namun dibanding tmux, latency-nya terasa jelas, dan saya masih terus memakai tmux
    Saat itu saya memang memakai koneksi yang sudah punya latency, jadi mungkin saya agak sensitif
  • Terakhir kali saya melihat Zellij, ia tampak seperti proyek baru yang bagus di ekosistem multiplexer, tetapi tidak mendukung mekanisme copy/paste berbasis keyboard murni
    Saya memakai fitur itu sangat sering, jadi tidak bisa tanpanya, dan sampai fitur itu ditambahkan saya tidak punya pilihan selain memakai tmux
  • Bagus sih, tapi saya sangat suka screen dan perintah-perintahnya sudah tertanam sebagai muscle memory
    Saya sudah memakainya lebih dari 20 tahun

• Mengejutkan bahwa upstream terlibat di sini
  Sekitar 5 tahun lalu saya dengan sedih menyimpulkan bahwa pengembangan GNU screen sudah benar-benar berhenti, jadi saya penasaran apakah ternyata belum begitu
  Saya tidak tahu apakah screen masih punya fitur untuk menambahkan jendela baru tanpa menempel ke screen yang sudah ada

  • Upstream meminta tim SUSE untuk meninjaunya
    Sepertinya mereka kekurangan tenaga pengembang, dan mungkin upstream tidak punya keahlian untuk memeliharanya dengan baik
    Kalau benar, itu menyedihkan. Saya tahu ada tmux dan alternatif lain, tetapi banyak orang sudah memakai Screen sangat lama dan menyedihkan melihat sebuah alat perlahan membusuk
  • Disebutkan bahwa komunikasi dengan upstream sulit, sehingga saat ini mereka tidak punya informasi rinci tentang perbaikan bug dan rilis yang dibuat pihak sana
    Mereka memang meminta peninjauan keamanan, tetapi tampaknya sulit menjaga komunikasi, dan saya tidak tahu keseluruhan situasinya
  • Keterlibatannya sebatas mendistribusikannya sebagai setuid-root
    Distro yang mengaturnya seperti ini rentan, dan distro yang tidak mengaturnya begitu tidak rentan
    Menurut saya itu keterlibatan yang sangat dangkal. Kalau upstream terlalu lambat, distro yang melakukan patch
  • Berhentinya pengembangan alat GNU tidak selalu menyedihkan. Tentu saja perbaikan bug dikecualikan
    Pada dasarnya itu bisa dianggap sebagai tanda bahwa alat tersebut sudah selesai
  • Di open source ada masalah inersia ketika satu perangkat lunak berakhir dan perangkat lunak lain dibuat untuk menggantikannya
    Tidak ada insentif untuk segera beralih, karena itu bukan pembaruan melainkan migrasi
    Sebaliknya, buruk juga kalau seseorang membeli merek dagang perangkat lunak lama lalu mengubahnya menjadi sesuatu yang benar-benar berbeda seperti kasus Audacity
    Jadi tampaknya tidak ada solusi yang bagus

• Versi yang sudah dirender: https://security.opensuse.org/2025/05/12/screen-security-iss...

• Kalau ingatan saya benar, tmux masuk ke sistem dasar sejak OpenBSD 4.6 dan merupakan alat yang sudah, atau terus, diaudit
  Cocok bagi orang yang menginginkan alternatif yang sedikit lebih aman

  • Melihat screen muncul lagi mengingatkan saya pada masa ketika saya dulu pindah ke tmux lalu melupakan screen

• Perilaku yang diamati sudah ada di versi Screen setidaknya sejak 2005, dan sudah menjadi antipola selama itu; alat seperti rkhunter juga menanganinya
  Meski begitu, saya rasa screen sudah setuid root sejak era 90-an

• Berapa banyak pengembang sebenarnya yang menjalankan alat open source paling populer?
  Seberapa banyak uang yang dimiliki industri yang memakai alat-alat itu?