Bisakah menyimpan file menjadi potensi risiko keamanan?

Ya , ini merupakan risiko potensial, lihat CVE-2003-0063, atau CVE-2008-2383 atau CVE-2010-2713, atau CVE-2012-3515 atau OSVDB 3881, atau CVE-2003-0020 atau yang serupa yang tercantum di sini ... Beberapa lagi di komentar di bawah juga.

Perbarui itu bukan hanya potensi risiko, itu adalah risiko nyata .rxvt-unicode (versi 2.7—9.19, ditambal pada 9.20) memungkinkan akses baca/tulis ke properti jendela X, ini dapat mengaktifkan eksekusi perintah sewenang-wenang yang dibantu pengguna, masalah ini telah ditetapkan CVE-2014-3121, detail lebih lanjut di sini https ://bugzilla.redhat.com/show_bug.cgi?id=1093287 .

Baru-baru ini (Oktober 2019) iTerm2 versi hingga v3.3.5 ditemukan memiliki kelas masalah yang sama:tampilan konten berbahaya dapat mengaktifkan tmux terintegrasi dan mengizinkan eksekusi perintah, lihat CVE-2019-9535.

Topik ini juga memiliki cakupan yang baik di sini:https://unix.stackexchange.com/questions/73713/how-safe-is-it-to-cat-an-arbitrary-file dan analisis menyeluruh dari masalah mendasar dari Gilles di sini:https://unix.stackexchange.com/questions/15101/how-to-avoid-escape-sequence-attacks-in-terminals .

Penjelasan

Apa yang Anda amati adalah efek samping dari perilaku sekuens escape tertentu:beberapa di antaranya memasukkan karakter (biasanya juga berisi sekuens escape) langsung ke dalam buffer masukan terminal . Semua atas nama kompatibilitas ke belakang, tentu saja. xterm standar lolos yang dijelaskan menggunakan istilah "Laporkan " lakukan ini. Perilaku ini mengizinkan program untuk meminta/mengatur properti terminal (atau lainnya) "dalam pita" daripada melalui ioctls atau API lainnya.

Seakan itu belum cukup buruk, beberapa urutan seperti itu bisa berisi baris baru , yang berarti bahwa apa pun yang membaca dari terminal (shell Anda) akan melihat apa yang tampaknya merupakan perintah pengguna yang lengkap.

Inilah cara yang rapi untuk menggunakan ini, dengan read bash untuk mencetak jalan keluar (sebagai perintah) lalu segera baca dan pisahkan balasan menjadi variabel:

IFS=';' read -sdt -p $'\e[18t' csi8 rows cols
echo rows=$rows cols=$cols

Urutan ini dapat bervariasi menurut terminal, tetapi untuk rxvt dan diturunkan, kueri grafik escape menyertakan baris baru (contoh menggunakan bash dan $'' string, lihat doc/rxvtRef.txt di sumber)` :

$ echo $'\eGQ'
$ 0
bash: 0: command not found

Pelarian ini mengirimkan \033G0\n ke buffer input terminal (atau digit 1 bukannya 0 jika Anda memiliki rxvt berkemampuan grafis ).

Jadi, gabungkan pelarian ini dengan urutan lain yang berperilaku serupa:

echo $'\x05' $'\e[>c' $'\e[6n' $'\e[x' $'\eGQ'

bagi saya ini menyebabkan 11 upaya untuk menjalankan berbagai perintah:1 , 2c82 , 20710 (rxvt saya string versi), 0c5 , 3R (5 dan 3 adalah koordinat kursor), 112 dan 0x0 .

Dapat dieksploitasi?

Dengan rxvt dan emulator terminal terbaru, Anda seharusnya "hanya" dapat membuat serangkaian urutan numerik yang terbatas. Di emulator terminal lama dimungkinkan (beberapa CVE tercantum di atas) untuk mengakses clipboard, ikon jendela dan teks bilah judul untuk membuat lebih banyak string berbahaya untuk pemanggilan (satu pengecualian kecil saat ini adalah jika Anda menyetel answerbackString string sumber daya X, tetapi itu tidak dapat diatur langsung menggunakan metode ini). Cacatnya kemudian memungkinkan pembacaan sewenang-wenang dan akses tulis ke sesuatu yang lolos ke status atau penyimpanan dalam urutan escape yang memasukkan data ke dalam buffer masukan.

rxvt memerlukan perubahan waktu kompilasi untuk mengaktifkan, tetapi urxvt membantu memiliki -insecure opsi baris perintah yang mengaktifkan beberapa fitur yang lebih menarik:

$ echo $'\e]2;;uptime;\x07' $'\e[21;;t' $'\eGQ' 
bash: l: command not found
17:59:41 up 1448 days,  4:13, 16 users,  load average: 0.49, 0.52, 0.48
bash: 0: command not found

Ketiga urutan tersebut adalah:

1. \e]2;...\x07 atur judul jendela;
2. \e[21;;t judul jendela kueri, tempatkan di buffer input;
3. \eGQ kemampuan grafik kueri, yang menambahkan \n untuk memasukkan buffer.

Sekali lagi, tergantung pada terminal, fitur lain seperti ukuran font, warna, ukuran terminal, kumpulan karakter, buffer layar alternatif, dan lainnya dapat diakses meskipun lolos. Modifikasi yang tidak diinginkan setidaknya merupakan ketidaknyamanan, jika bukan masalah keamanan langsung. Versi xterm saat ini batasi fitur yang berpotensi bermasalah melalui resource "Izinkan*".

CVE-2014-3121

Sebelum v9.20, urxvt tidak juga menjaga akses baca dan tulis ke properti X (kebanyakan digunakan oleh manajer jendela). Tulis akses baca (atau lebih tepatnya, akses ke urutan yang menggemakan string yang berpotensi arbitrer) sekarang membutuhkan -insecure opsi.

$ echo $'\e]3;xyzzy=uptime;date +%s;\x07'
$ xprop -id $WINDOWID xyzzy
xyzzy(UTF8_STRING) = 0x75, 0x70, 0x74, 0x69, 0x6d, 0x65, 0x3b, 0x64, 0x61, 0x74, \
0x65, 0x20, 0x2b, 0x25, 0x73, 0x3b

Ini dapat dengan mudah digunakan untuk memasukkan string arbitrer ke dalam buffer input terminal. Saat escape sequence untuk mengkueri sebuah properti dipanggil (bersama dengan \eGQ yang membantu yang menambahkan baris baru):

 $ echo $'\e]3;?xyzzy\x07' $'\eGQ'
 $ 3;uptime;date +%s;0
 bash: 3: command not found
 17:23:56 up 1474 days,  6:47, 14 users,  load average: 1.02, 1.20, 1.17
 1400603036
 bash: 0: command not found

Beberapa perintah, mempertahankan spasi putih dan karakter meta shell. Ini dapat dieksploitasi dalam berbagai cara, dimulai dengan memasukkan biner yang tidak dapat dipercaya tentunya, ide lebih lanjut dalam H.D. Makalah pendek Moore (2003).

Tindak lanjut

Untuk escape sequence yang Anda tanyakan tentang:1;112;112;1;0x1;2 Ini adalah:Minta Parameter Terminal (DECREQTPARM) dan Kirim Atribut Perangkat :

$ echo $'\e[x' $'\e[0c'
;1;1;112;112;1;0x1;2c

Yang kedua (\e[0c ) sama dengan ^E (menggunakan rxvt ). Ada beberapa urutan pelarian di sana juga. urutan lengkap yang ditulis untuk masing-masing adalah:

\e[1;1;1;112;112;1;0x
\e[?1;2c

Tentu saja ya.

Tambahkan baru 25-01-2020:

Sejak saya beralih dari LATIN-1 enkode ke UTF-8 sebagai enkode default di sebagian besar sistem saya, saya menemukan beberapa fitur yang menarik sekitar ini (sekarang ada dua panjang untuk satu string)...

Sebagai contoh, karena saya suka bermain dengan bash , saya telah bertanya mengapa lokalisasi bash tidak akan berfungsi dengan string multilines. Fitur bash ini menampilkan bug, di mana solusinya terdiri dari penggunaan eval . Jika ini bukan celah keamanan , ini bisa menjadi atau menghasilkan satu...

Dalam setiap evolusi dari hampir semua hal (bahasa, pustaka, alat, protokol, aplikasi, perangkat keras, penginstal, konsol, dll...) ada fitur baru, dengan potensi bug baru...

Untungnya, jumlahnya sedikit karena dapat diperbaiki dengan cepat (mendekati satu hari dari mengungkapkan), tetapi mereka!

Jadi pasti ya, tetap hati-hati!

Penggunaan cat dengan benar perintah.

Sepertinya Anda menggunakan emulator terminal modern , beberapa urutan keluar dapat digunakan untuk memodifikasi Buffer keyboard .

Mungkin ada perintah shell yang tepat yang disuntikkan.

Anda bisa menggunakan argumen -e dari cat untuk operasi yang aman, lihat man cat .

  -e     equivalent to -vE

  -E, --show-ends
         display $ at end of each line

  -v, --show-nonprinting
         use ^ and M- notation, except for LFD and TAB

Lalu

$ cat -e suspectfile.raw
$ cat -e suspectfile.raw | less

atau di bawah bash:

$ less < <(cat -e suspectfile.raw)

atau bahkan

$ which less cat
/usr/bin/less
/bin/cat
$ rawless() { /usr/bin/less < <(/bin/cat -e "[email protected]");}

Keterangan

Saat Anda membaca command not found , ini menyiratkan bahwa ada sesuatu yang disuntikkan secara efektif.

Injeksi utama fitur yang tidak dihapus adalah urutan identifikasi diri Anda , digunakan di banyak enkapsulasi VT-100.

Urutan ini adalah Escape Z yang akan menyuntikkan string 1;2c ke buffer keyboard Anda, yang berarti VT-100 (dalam konvensi AVO).

Berbicara tentang cat , Anda dapat mencoba:

$ cat <<< $'\033Z'

Atau urutan ANSI lainnya:CSI c (Atribut Perangkat ):

$ cat <<< $'\033[c'

akan mencetak baris kosong, tetapi pada baris berikutnya diminta, Anda akan melihat 1;2c (atau mungkin dengan nomor lain, tergantung terminal yang digunakan) seolah-olah Anda memukul mereka:

$ 65;1;9c█

... tetapi dengan -e beralih:

$ cat -e <<< $'\033Z'
^[Z$
$ cat -e <<< $'\033[c'
^[[c$

Dimana -e => -vE , -v ubah \033 ke dalam ^[ dan -E beri $ masuk di akhir baris (dan tidak ada yang akan diletakkan di baris berikutnya, Anda penyangga keyboard tidak terpengaruh).

Anda mungkin menemukan banyak hal lucu di Panduan Pengguna VT100 (seperti:cat <<< $'\033#8';)

(Mereka adalah terminal modern ! Di masa lalu... )

Mencoba menggunakan bash

Ada sedikit perintah bash untuk membilas buffer keyboard dan mendapatkan kontennya:

$ cat <<<$'\033[c';buf='';while read -t .1 -n 1 chr;do
        buf+="$chr"
  done;printf "\n>|%q|<\n" $buf

^[[?65;1;9c
>|$'\E[?65;1;9c'|<

Dan sedikit fungsi untuk menguji rantai apa pun:

$ trySeq() {
    printf -v out "$1"
    echo -n "$out"
    buf=""
    while read -t.1 -n1 char
      do buf+="$char"
    done
    [ "$buf" ] && printf "\r|%q|->|%q|<\e[K\n" "$out" "$buf"
}

Jadi saya bisa mencoba:

$ for seq in $'\e['{c,{1..26}{n,t,x}};do
      trySeq "$seq";done
|$'\E[c'|->|$'\E[?65;1;9c'|<
|$'\E[1x'|->|$'\E[3;1;1;120;120;1;0x'|<
|$'\E[5n'|->|$'\E[0n'|<
...

( Mungkin dengan beberapa tidak berbahaya efek pada konsol Anda;)

Contoh praktis kecil

Bayangkan, beberapa dapat menempatkan sesuatu seperti ini di lingkungan Anda:

$ source <(printf '%dc() {
     printf "You\\047ve been hitted\\041\\n"
   };\n' {0..100};printf 'alias %s=1c\n' {0..100};)

Lalu, jika Anda

$ cat <<<$'\e[c'

$ 65;1;9c█

Kursor akan tetap berada di akhir baris baris perintah.

Dari sana, jika Anda secara otomatis menekan Return bukannya Ctrl + c , Anda akan membaca sesuatu seperti:

$ 65;1;9c
You've been hitted!
You've been hitted!
You've been hitted!
$ █

Dan sekarang?

Dari sana, sayangnya, tidak ada standar .

Setiap terminal virtual implementasi dapat mendukung ANSI penuh dan/atau standar DEC penuh...

Namun karena ada beberapa masalah keamanan, banyak yang tidak...

Anda dapat mengamati beberapa perilaku menggunakan satu terminal yang tidak akan Anda amati menggunakan yang lain...

xterm, konsol linux, terminal gnome, konsole, fbterm, Terminal (Mac OS)... daftar emulator terminal tidak terlalu pendek!

Dan masing-masing memiliki bug dan batasannya sendiri dibandingkan dengan standar DEC dan ANSI.

Pada kenyataannya, Anda mungkin menemukan beberapa konsol virtual yang bisa lebih diunggulkan dari yang lain dan di mana injeksi keyboard dapat merusak keamanan Anda.

Itu salah satu alasannya karena saya lebih suka menggunakan xterm yang selalu sama (lama). daripada alat unggulan lainnya.

Terminal kaca "asli" memiliki urutan pelarian untuk mencetak layar ke printer. Mereka melakukannya dengan menjalankan perintah dan mem-pipe konten layar saat ini ke stdin dari perintah print.

Perintah tersebut dapat dikonfigurasi dengan urutan escape lainnya.

Cara klasik mengeksploitasi ini adalah dengan membuat file dengan nama yang menyematkan urutan escape untuk menyetel perintah printer dan mengubahnya ke beberapa skrip pilihan Anda, lalu memiliki file ke-2 dengan urutan escape cetak di dalamnya.

Ketika seseorang kemudian menjalankan ls di direktori itu mereka akan menjalankan kode Anda. Itu bagus jika itu adalah root pengguna!

Secara teori, emulator terminal modern seharusnya tidak melakukan hal semacam itu lagi.

Terminal.app tampaknya didasarkan pada nsterm NextStep, jadi mungkin ada segala macam keanehan di dalamnya.

Mungkin coba persempit byte mana yang menghasilkan command not found pesan?

Sepertinya ada escape sequence untuk menaikkan dan menurunkan terminal:

http://the.taoofmac.com/space/apps/Terminal

beberapa info lebih lanjut di sini:

http://invisible-island.net/ncurses/terminfo.src.html#toc-_Apple__Terminal_app

Jika Anda ingin mengirim konten ke stdin program,

program -para meters < /path/file.ext