Bagaimana cara menghindari serangan urutan melarikan diri di terminal?

Membaca detail CVE-2009-4487 (yaitu tentang bahaya urutan melarikan diri dalam file log) Saya sedikit terkejut.

Mengutip CVE-2009-4487 :

nginx 0.7.64 menulis data ke file log tanpa membersihkan karakter yang tidak dapat dicetak, yang memungkinkan penyerang jarak jauh untuk mengubah judul jendela, atau mungkin menjalankan perintah sewenang-wenang atau menimpa file, melalui permintaan HTTP yang berisi urutan keluar untuk emulator terminal.

Jelas, ini bukan tentang lubang keamanan di nginx, tetapi di emulator terminal.

Tentu, mungkin catfile log ke terminal hanya terjadi secara tidak sengaja, tetapi grepfile log cukup umum. lessmungkin membersihkan urutan pelarian, tetapi siapa tahu perintah shell apa tidak mengubah urutan pelarian ...

Saya cenderung setuju dengan respons Varnish :

Kebijaksanaan dari terminal-response-escapes secara umum telah dipertanyakan secara berkala, tetapi masih belum ada program emulasi terminal utama yang cocok untuk membuang sekuens-sekuens ini, mungkin dalam upaya kesesuaian kompatibilitas dengan teknologi 1970-an yang tidak lagi digunakan. [..] Daripada menyalahkan semua dan semua program yang menulis file log, akan jauh lebih produktif, dari sudut pandang keamanan, untuk membuat program emulasi terminal berhenti melakukan hal-hal bodoh, dan dengan demikian memperbaiki ini dan masalah keamanan lainnya sekali dan untuk semua.

Demikian pertanyaan saya:

Bagaimana saya bisa mengamankan xterm saya, sehingga tidak mungkin lagi untuk mengeksekusi perintah atau menimpa file melalui urutan escape?

Emulator terminal apa untuk X yang diamankan dari serangan ini?

Terminal VT100 (yang ditiru oleh semua emulator terminal modern) mendukung sejumlah perintah bermasalah, tetapi emulator atau distribusi modern menonaktifkan yang lebih bermasalah dan kurang bermanfaat. Berikut adalah daftar urutan melarikan diri yang berpotensi tidak lengkap (tidak termasuk yang hanya membuat tampilan tidak dapat dibaca dengan beberapa cara):

• Perintah file log sewenang-wenang dalam rxvt dan Eterm dilaporkan oleh HD Moore . Ini memang bug utama, untungnya lama diperbaiki.
• Perintah jawab balik, juga dikenal sebagai Status Terminal Kembali, dipanggil oleh ENQ( Ctrl+E). Ini memasukkan teks ke terminal seolah-olah pengguna telah mengetiknya. Namun, teks ini tidak di bawah kendali penyerang: ini adalah nama terminal itu sendiri, biasanya seperti xtermatau screen. Pada sistem saya (pemerasan Debian), xterm mengembalikan string kosong secara default (ini dikendalikan oleh answerbackStringsumber daya).
• Perintah Kirim Perangkat Atribut, ESC [ cdan teman-teman. Terminal merespons dengan ESC [ … c(di mana …kaleng berisi digit dan tanda baca ASCII saja). Ini adalah cara untuk menanyakan beberapa kemampuan terminal, sebagian besar sudah usang tetapi mungkin digunakan oleh aplikasi lama. Sekali lagi, respons terminal tidak dapat dibedakan dari input pengguna, tetapi tidak di bawah kendali penyerang. Urutan kontrol mungkin terlihat seperti tombol fungsi, tetapi hanya jika pengguna memiliki konfigurasi yang tidak biasa (tidak ada pengaturan yang biasa saya temui yang memiliki urutan pelarian tombol fungsi yang valid yang merupakan awalan dari respons terminal).
• Berbagai fungsi kontrol perangkat (DCS lolos, dimulai dengan ESC P).
  • Saya tidak tahu bahaya apa yang dapat dilakukan melalui DECUDK(mengatur kunci yang ditentukan pengguna) pada emulator terminal tipikal.
  • DECRQSS(Request Status String) adalah perintah lain yang ditanggapi terminal dengan urutan pelarian, kali ini dimulai dengan \eP; ini bisa bermasalah karena \ePmerupakan kunci yang valid ( Alt+ Shift+ P).
  • Xterm memiliki dua fitur eksperimental lagi: ESC P + p …dan ESC P + q …, untuk mendapatkan dan mengatur string termcap. Dari deskripsi, ini mungkin digunakan setidaknya untuk memodifikasi efek tombol fungsi.
• Beberapa perintah laporan status: ESC [ … n(Laporan Status Perangkat). Terminal merespons dengan urutan pelarian. Sebagian besar urutan pelarian ini tidak sesuai dengan urutan pelarian kunci fungsi. Satu terlihat bermasalah: laporannya ESC [ 6 nadalah dari bentuk di mana dan adalah urutan digit, dan ini bisa terlihat seperti dengan beberapa pengubah.ESC [ x ; y RxyF3
• Perintah manipulasi jendela ESC [ … t.
  • Beberapa di antaranya memungkinkan jendela xterm diubah ukurannya, ditandai, dll., Yang mengganggu.
  • Beberapa di antaranya menyebabkan terminal merespons dengan urutan pelarian. Sebagian besar urutan melarikan diri ini terlihat berisiko rendah, namun ada dua perintah berbahaya: jawaban untuk ESC [ 2 0 tdan ESC [ 2 1 tmenyertakan label ikon jendela dan judul masing-masing, dan penyerang dapat memilih ini.
  • Setidaknya di bawah Debian squeeze, xterm mengabaikan perintah-perintah ini secara default; mereka dapat diaktifkan dengan mengatur allowWindowOpssumber daya, atau secara selektif melalui disallowedWindowOpssumber daya. Gnome-terminal di bawah Ubuntu 10,04 bahkan mengimplementasikan jawab jawab judul secara default. Saya belum memeriksa terminal atau versi lain.
• Perintah untuk mengatur judul terminal atau nama ikon. Di bawah xterm dan sebagian besar terminal X lainnya, yaitu . Di bawah Layar, urutan jalan keluar adalah . Saya menemukan kekhawatiran atas perintah ini berlebihan. Meskipun mereka mengizinkan sejumlah kerusakan, setiap halaman web memiliki masalah yang sama. Bertindak berdasarkan jendela semata-mata berdasarkan judulnya dan bukan pada kelasnya sama dengan membuka file yang namanya diberikan kepada Anda oleh pihak yang tidak dipercaya, atau tidak mengutip ekspansi variabel dalam skrip shell, atau menepuk hidung anjing di hidung - jangan mengeluh jika Anda digigit.ESC ] digit ; title ESC \ESC k title ESC \

Saya menemukan tanggapan Varnish tidak jujur. Rasanya seperti mencoba untuk mengalihkan kesalahan, atau dalam mode nazi keamanan (masalah keamanan apa pun, asli atau tidak, membenarkan pengelompokan fitur).

Kebijaksanaan dari terminal-response-escapes secara umum telah dipertanyakan secara berkala, tetapi masih belum ada program emulasi terminal utama yang cocok untuk membuang sekuens-sekuens ini, mungkin dalam upaya kesesuaian kompatibilitas dengan teknologi 1970-an yang tidak lagi digunakan. (...)
Daripada menyalahkan setiap dan semua program yang menulis file log, akan jauh lebih produktif, dari sudut pandang keamanan, untuk membuat program emulasi terminal berhenti melakukan hal-hal bodoh, dan dengan demikian memperbaiki masalah keamanan ini dan lainnya sekaligus dan untuk semua.

Banyak balasan yang merupakan fitur berguna: aplikasi memang perlu mengetahui hal-hal seperti posisi kursor dan ukuran jendela. Pengaturan judul jendela juga sangat berguna. Sangat mungkin untuk bergantung sepenuhnya pada ioctlpanggilan untuk ini, namun ini akan membutuhkan kode dan utilitas tambahan untuk melakukan ioctlpanggilan ini dan menerjemahkannya ke dalam teks gaya unix yang meneruskan deskriptor file. Mengubah antarmuka ini sekarang akan banyak pekerjaan, untuk sedikit manfaat.

File teks tidak seharusnya mengandung karakter yang tidak dicetak seperti karakter kontrol. File log umumnya diharapkan menjadi file teks. File log tidak boleh mengandung karakter kontrol.

Jika Anda khawatir file mungkin berisi urutan keluar, buka di editor, atau lihat lesstanpa -ratau -Ropsi, atau melihatnya cat -v.

Tidak sesederhana itu; banyak orang memiliki kode untuk menetapkan xtermjudul sebagai bagian dari prompt atau dll., dan untuk alasan yang sangat bagus (seperti yang diketahui orang yang shutdownsalah mesin dari jendela terminal yang salah!). Oleh karena itu, memperbaikinya dengan benar melibatkan pengenalan konteks keamanan dan dengan demikian secara serius mempersulit interaksi antara shell dan emulator terminal dan mungkin juga orang-orang bodoh. Atau Anda dapat menggunakan solusi sewa rendah untuk membersihkan segala sesuatu yang mungkin ditampilkan di terminal; ini sebagian besar mengurangi ke melarikan diri karakter kontrol, yang mungkin harus dilakukan pula hanya untuk membuatnya menonjol (karena dalam file log mereka dapat menunjukkan seseorang mencoba menyuntikkan shellcode).

(Selain itu, punycode adalah contoh yang lebih parah dari jenis masalah yang sama - dan bagaimanapun juga telah dijadikan standar resmi. Kadang-kadang keamanan diturunkan untuk mengurangi desain tidak aman yang berada di luar kendali seseorang.)