Design: Jelaskan keamanan

Hai!

Saya punya pertanyaan: Apakah masuk akal untuk menguraikan hal berikut dalam konteks ini:

"Selain itu, program yang memunculkan perilaku tidak terdefinisi pada tingkat bahasa sumber dapat dikompilasi ke dalam program WebAssembly yang melakukan hal lain, termasuk merusak konten tumpukan aplikasi, memanggil API dengan parameter arbitrer, menggantung, menjebak, atau mengonsumsi sejumlah sumber daya (dalam batas).
https://github.com/WebAssembly/design/blob/master/CAndC++.md#undefined-and-implementation-defined-behavior

Apa yang saya pikirkan adalah memberikan konteks/referensi yang mungkin (mungkin) berguna untuk pengembang web yang berasal dari latar belakang non-pribumi - dengan memberikan contoh dan diskusi lebih lanjut.

Misalnya, MSC14-C CERT Jangan perkenalkan dependensi platform yang tidak perlu, daftarkan empat jenis Perilaku Nonportabel (Perilaku Tidak Tertentu, Perilaku Tidak Terdefinisi, Perilaku Khusus Lokal, Perilaku yang Ditentukan Implementasi) dengan contoh. MSC15-CPP. perilaku tidak terdefinisi ke kerentanan C compiler mungkin diam-diam membuang beberapa pemeriksaan sampul , yang mungkin sangat penting dalam konteks ini (Robert Seacord membahas ini secara lebih rinci dalam "Pemeriksaan Penghapusan Diam dari Batasan" ).

Perawatan lebih mendalam:

• Yang Harus Diketahui Setiap Pemrogram C Tentang Perilaku Tidak Terdefinisi #1/3
• Yang Harus Diketahui Setiap Pemrogram C Tentang Perilaku Tidak Terdefinisi #2/3
• Yang Harus Diketahui Setiap Pemrogram C Tentang Perilaku Tidak Terdefinisi #3/3
• Panduan untuk Perilaku Tidak Terdefinisi dalam C dan C++, Bagian 1
• Panduan untuk Perilaku Tidak Terdefinisi dalam C dan C++, Bagian 2
• Panduan untuk Perilaku Tidak Terdefinisi dalam C dan C++, Bagian 3

Saran lain yang berpotensi relevan:

• INT02-CPP.
• INT08-CPP.
• INT10-CPP.
• INT18-C.
• INT32-C.

Apakah memiliki header CSP unik untuk mengontrol file wasm membantu? Saya merasa pemilik situs mungkin ingin mencegah subsumber daya memuat wasm.

Itu pertanyaan yang menarik. Jelas kita harus mengizinkan situs untuk melarang pemuatan dinamis dan evaluasi WebAssembly dalam kasus yang sama mereka melarang eval dan Function (ini hanya akan keluar dari integrasi modul ES6 dan pemeriksaan CSP pada Loader jalur

Ada baiknya menunjuk ke #53 untuk diskusi tentang beberapa masalah keamanan dengan penautan dinamis.

@jfbastien yup CORS dan SRI harus tersedia untuk pengembang jika memungkinkan.

@lukewagner Saya kira itu tergantung pada akses tingkat rendah ke sumber daya yang akan diaktifkan wasm. Seperti yang Anda katakan di luar kotak itu hanya JS. Namun tampaknya tujuan menyeluruh dari wasm adalah hal yang paling dekat dengan logam mesin; arahan CSP untuk kontrol global akan menyenangkan untuk dimiliki.
Seiring waktu, pendekatan yang lebih terperinci untuk fitur lain juga akan lebih baik.

Kemungkinan langsung lainnya adalah memanfaatkan API izin untuk akses tingkat rendah lainnya.

Yah, dekat dengan logam dalam arti kinerja. Dari perspektif keamanan, izin, dan kotak pasir, tidak ada diskusi tentang perbedaan WebAssembly dari JS.

Itu bukan perasaan yang saya dapatkan dari pengumuman pasca-MVP dan Brendan Eichs tapi ok :+1:

Saya pikir apa yang Anda maksud adalah bahwa kami telah sepakat bahwa, pasca-MVP, semantik WebAssembly akan diizinkan untuk menyimpang dari apa yang dapat di-polyfill secara efisien di JS. Perbedaan ini akan ada di sekitar fitur komputasi, tidak ada hubungannya dengan keamanan/izin. Itu berarti, meskipun tidak dapat di-polyfill _efisien_, fitur-fitur baru _dapat_ disimulasikan oleh penerjemah WebAssembly yang ditulis dalam JS ( Emterpreter-style ). Mungkin akan lebih baik untuk menambahkan catatan pada efek ini untuk mengikat apa yang kami maksud dengan "menyimpang dari JS".

Yup itu akan menjadi peningkatan yang bagus untuk dokumen itu, saya mungkin telah membaca dokumen terlalu cepat tetapi sepertinya tidak menjelaskannya.

Saya pikir itu adalah salah satu pembicaraan Eichs tentang menambahkan lebih banyak fitur threading dan memori yang membuat saya berpikir wasm akan mendapatkan fitur baru. Saya menduga ini kemungkinan akan ditambahkan ke JavaScript juga dan tunduk pada pengawasan fitur baru yang biasa.

"Tidak berbeda dengan POV keamanan dari JS" sekarang ada di Web.md .

Saya lebih suka menjelaskan perbedaannya dengan lebih baik. Merujuk ke JS tidak terlalu bagus dari perspektif berdiri sendiri, dan saya pikir kami benar-benar ingin mengurangi area permukaan keamanan yang dimiliki JS (katakanlah, skrip lintas-Asal dan semacamnya).

Saya akan membahas ini, sekarang saya telah membicarakannya di CppCon :-)

Bagi mereka yang mungkin tertarik untuk menggunakan WebAssembly sebagai target untuk implementasi kriptografi, menjelaskan perbedaan antara JS/asm.js JIT dan WebAssembly JIT dalam hal dukungan untuk implementasi waktu tetap akan berguna. Saya berpikir secara khusus tentang operasi seperti bitshifts, cabang yang diperkenalkan pasca-JIT, lompatan atau pencarian bersyarat, atau perubahan lain yang mungkin dilakukan JIT yang dapat menyebabkan kebocoran waktu.

Jika pengembang seharusnya tidak mengharapkan WebAssembly untuk mendukung implementasi waktu tetap dengan lebih baik daripada apa yang sudah kami miliki dengan asm.js, maka menyatakan itu akan membantu sebagai bagian dari mengelaborasi implikasi keamanan WebAssembly untuk desain aplikasi. Jika WebAssembly akan menyediakan beberapa cara aplikasi pengerasan yang lebih baik vs. apa yang ada saat ini (sekarang atau setelah MVP, saya belum membaca spesifikasi secara mendalam), itu akan bagus untuk diuraikan juga. https://github.com/jedisct1/libsodium.js/issues/24#issuecomment -128002942 memiliki lebih banyak lagi tentang masalah yang ada seputar kripto JavaScript sisi klien.

Omong-omong, ini semua sangat mengasyikkan. :D

Setuju bahwa kita harus memiliki pernyataan klarifikasi seperti yang disarankan oleh @dconnolly. Sampai sekarang diskusi yang kami lakukan adalah bahwa untuk MVP tidak akan ada jaminan tentang apa yang dapat/tidak dapat dilakukan oleh JIT, dan bahwa algoritma waktu-konstan bukanlah penggunaan wasm yang tepat setidaknya untuk MVP. Ini mungkin berubah di masa depan.

Pendapat saya saat ini adalah bahwa API eksternal (seperti yang ditawarkan oleh penyemat seperti platform web) diposisikan lebih baik untuk menawarkan jaminan seperti itu karena Anda sering memerlukan perakitan dan pemahaman yang baik tentang arsitektur mikro untuk menulis kode waktu konstan yang tepat. Pertimbangkan contoh ekstrem dari CPU yang melakukan terjemahan biner dinamis: WebAssembly tidak dapat menjamin apa yang dapat/tidak dapat dilakukan oleh CPU. Pandangan saya adalah bahwa WebAssembly berada pada tingkat abstraksi yang terlalu tinggi untuk mengekspresikan kode waktu-konstan yang sebenarnya.

Keren, terima kasih atas pencerahannya. Setuju bahwa API platform web adalah tempat terbaik untuk hal semacam ini, terutama primitif ( WebCrypto sedang/akan mendukung hal-hal penting, dengan ruang untuk penambahan di masa mendatang seperti kurva eliptik baru melalui catatan ). Menantikan bahasa tambahan tentang keamanan, ini akan membantu orang lain yang mungkin salah menafsirkan implikasi WebAssembly. :+1:

@jfbastien , apakah semua yang Anda katakan tentang jaminan waktu wasm masih berlaku hari ini?

Saya melihat dalam dokumen saat ini bahwa eksekusi deterministik adalah tujuan kecuali dalam daftar kecil kasus tepi yang terdokumentasi, yang terdengar berpotensi positif untuk algoritma waktu konstan. Namun, webassembly.org/docs/security mengakui bahwa serangan waktu dimungkinkan dan mencantumkan beberapa potensi mitigasi di masa depan, tetapi tidak jelas apakah implikasinya adalah bahwa "kode kereta C Anda tidak akan diperbaiki secara ajaib... belum" atau "kerentanan saluran samping mungkin diperkenalkan yang tidak akan terjadi dengan kompiler C biasa".

Selain jaminan keras, akan sangat membantu setidaknya untuk memahami di mana kita berdiri di antara "algoritma waktu konstan 100% pasti akan kacau" dan "tidak ada alasan yang jelas untuk tidak selalu mengharapkan karakteristik waktu yang sebanding dengan output biner asli dentang". Untuk poin @dconnolly , beberapa bahasa yang secara khusus membandingkan ini dengan asm.js juga akan sangat berguna — terutama dengan mempertimbangkan kedua implementasi seperti Firefox yang sepenuhnya menghormati pernyataan 'use asm' dan yang seperti Chrome yang memainkannya sedikit lebih longgar .

@buu700 hasil deterministik untuk semua opcode tidak menyiratkan bahwa waktu dijamin untuk opcode apa pun. Dentang juga tidak menjamin eksekusi waktu-konstan, dan waktu-konstan tidak semua yang Anda butuhkan jika Anda menulis kode sensitif-infoleak.

Saat ini, WebAssembly tidak berusaha menjamin apa pun sehubungan dengan kebocoran info.

Mengerti, terima kasih telah mengklarifikasi bagian tentang determinisme @jfbastien.

Sejauh waktu/saluran samping (dan mengabaikan jaminan atau kekurangannya), sepertinya tidak ada yang relevan dalam spesifikasi tentangnya saat ini dan belum ada data yang berguna tentang bagaimana implementasi aktual dibandingkan dengan dentang? Apa yang sebenarnya saya maksud, setelah membaca komentar Anda sebelumnya, adalah apakah ada alasan yang melekat untuk implementasi wasm untuk selalu _lebih buruk_ daripada gcc/dentang di area ini. Anda telah menyebutkan tingkat abstraksi sebagai perhatian, tetapi tidak jelas apa yang Anda gunakan sebagai perbandingan dasar untuk waktu konstan "cukup baik" (C asli, perakitan, perangkat keras, dll.).

Dengan kata lain, dengan pilihan antara menjalankan kode sensitif infoleak pada dentang dan kemungkinan implementasi spesifikasi WebAssembly terbaik/paling matang/paling kuat secara hipotetis dari spesifikasi WebAssembly hari ini, apakah yang pertama masih lebih disukai berdasarkan pemahaman Anda?

Pada titik waktu ini, saya tidak akan bergantung pada dentang atau WebAssembly untuk kode yang peka terhadap infoleak. Satu-satunya cara saya saat ini tahu untuk benar-benar mendapatkan jaminan yang saya inginkan adalah dengan menulis Majelis yang membaca manual untuk CPU tertentu yang saya targetkan, dan dengan kolaborasi erat dari kernel. Mengetahui "x86" atau "ARM 64" bahkan tidak cukup jika Anda benar-benar ingin mandiri dalam mengatur waktu.

Anda bisa mendapatkan beberapa jaminan dengan beberapa kompiler/bahasa, tetapi jika hanya satu infoleak yang diperlukan untuk mengalahkan kode Anda, maka "beberapa" tidak cukup sebagai jaminan.

Sempurna, terima kasih, saya pikir itu menjawab pertanyaan saya. Menyetujui semua poin tentang pemodelan ancaman infoleak umum; Saya hanya ingin mendapatkan ide apakah wasm harus dianggap lebih bocor daripada target kompilasi C (bebas asm) lainnya, yang sepertinya Anda katakan belum tentu demikian?

Saya tidak berpikir "lebih bocor" adalah ukuran yang berguna. Metriknya adalah "apakah itu bocor sama sekali?" Jawaban untuk WebAssembly, dentang, C++, dan C, adalah "ya".

Secara khusus, yang ada dalam pikiran saya adalah algoritma yang dirancang untuk mencapai sifat resistansi saluran samping tertentu dengan implementasi C murni, seperti contoh libsodium/NaCl yang ditautkan oleh @dconnolly. Ini tentu ideal jika sesuatu akan bertahan dari setiap skenario serangan yang mungkin, tetapi juga berguna untuk mengetahui delta antara dua hal (bahkan jika keduanya payah, dengan beberapa ukuran mengisap), dan dalam hal ini apakah menggunakan WebAssembly alih-alih ABI Linux sebagai target kemungkinan akan mematahkan model ancaman libsodium yang dimaksudkan.

Komentar tertaut pada utas masalah libsodium sangat informatif tentang bagaimana perpustakaan berinteraksi dengan asm.js, tetapi sebagai non-ahli, tidak jelas bagi saya seperti apa analisis spesifik yang ditulis ulang untuk WebAssembly (selain dari dukungan i64 dan browser yang sedang lebih konsisten dalam menangani wasm daripada asm.js).

Tapi bagaimanapun, saya mengerti apa poin asli Anda dari setahun yang lalu sekarang, dan yang benar-benar saya khawatirkan adalah apakah Anda membuat pernyataan yang lebih kuat daripada yang sebenarnya (itu sebagai spesifikasi dikenal untuk memperkenalkan kelemahan saluran sampingan baru yang spesifik tidak ditemukan di C/dentang standar, sebagai lawan dari itu tidak ada yang secara umum cocok untuk tujuan itu), jadi terima kasih telah mengklarifikasi itu.

>

Saya tidak berpikir "lebih bocor" adalah ukuran yang berguna.

@jfbastien , keamanan kuantitatif adalah bidang yang berkaitan dengan pengukuran keadilan
itu. Metrik umum adalah berapa banyak bit informasi yang diungkapkan oleh a
serangan yang berhasil -- 1 bit vs 32 bit, katakanlah, membuat perbedaan besar (dan dalam
prakteknya hampir setiap sistem memiliki potensi kebocoran kecil melalui sisi
saluran). Seringkali kuantifikasi seperti itu agak sulit.

>

Saya tidak berpikir "lebih bocor" adalah ukuran yang berguna.

@jfbastien , keamanan kuantitatif adalah bidang yang berkaitan dengan pengukuran keadilan
itu. Metrik umum adalah berapa banyak bit informasi yang diungkapkan oleh a
serangan yang berhasil -- 1 bit vs 32 bit, katakanlah, membuat perbedaan besar (dan dalam
prakteknya hampir setiap sistem memiliki potensi kebocoran kecil melalui sisi
saluran). Seringkali kuantifikasi seperti itu agak sulit.

Saya menyadari hal ini, dan sama sekali tidak tertarik karena kebocoran adalah kebocoran. Jika itu penting bagi pengembang maka pada akhirnya akan menggigit kita (pelaksana WebAssembly). Saya tidak berpikir WebAssembly harus mencoba mengatasi masalah ini dalam waktu dekat mengingat prioritas kami yang lain, dan bahwa WebCrypto sudah ada sebagai upaya (terlepas dari kekurangan yang mungkin dimiliki, mengatasi masalah ini lebih baik daripada di mana WebAssembly saat ini ). Anda tentu saja dapat menjelajahi ini di waktu luang Anda.

@jfbastien , setuju bahwa topik ini tidak memiliki prioritas sekarang, itu
Wasm tidak lebih bocor dari C, dan kami tidak tahu cara yang baik untuk mengatasinya
dia. Tetapi penyederhanaan yang berlebihan seperti "kebocoran adalah kebocoran" tidak membantu dalam hal itu
masalah -- setiap sistem bocor sampai tingkat tertentu, jadi jumlahnya sebenarnya semua
itu penting. Dan hanya menunggu sampai "itu menggigit kita" bukanlah strategi yang
akan menginspirasi banyak kepercayaan di antara calon korban nyata, yaitu
pengguna peramban.

setuju bahwa ... Wasm tidak lebih bocor dari C

Bagus, terima kasih telah mengonfirmasi hal itu secara eksplisit! Itu saja saya datang ke sini untuk: pengertian umum tentang apa yang harus saya bandingkan dengan, bukan jaminan apakah itu "tidak akan bocor".

@rossberg-chromium Saya tidak berpikir saya akan setuju dengan gagasan bahwa wasm tidak lebih bocor daripada C. Pada akhirnya itu tergantung pada bagaimana setiap mesin mengimplementasikan semuanya. Misalnya, JavaScriptCore mengurutkan kode dan berhenti mengurutkan kode ketika kehabisan memori yang dapat dieksekusi. Ini adalah kebocoran yang tidak ada dengan kode C. Saya berharap, ketika mesin wasm menjadi lebih maju, wasm kemungkinan akan bocor seperti sesuatu seperti JVM. Pada akhirnya, saya tidak spek atau pelaksana cenderung berusaha untuk mengakomodasi mencegah kebocoran informasi, terutama tidak dengan mengorbankan kinerja.