Bagaimanakah anda menyerap data Apache Arrow IPC yang tidak dipercayai dengan selamat?

1. Senario dan model ancaman

Satu perkhidmatan analitik menerima strim Arrow IPC daripada penyewa luar dan menyerahkannya kepada pengguna Python, Rust, dan Java. Penyerang mungkin menghasilkan skema yang tidak konsisten, panjang yang terlalu besar, ofset di luar batas, sarang rekursif, kamus berniat jahat, atau penimbal yang melebihi belanjawan penerima. Matlamatnya adalah daya pemprosesan kelompok sambil memastikan kegagalan penghuraian hanya mempengaruhi permintaan semasa.

Tentukan sempadan kepercayaan terlebih dahulu: bait rangkaian, metadata IPC, kandungan penimbal, dan skema perniagaan adalah tidak dipercayai; penyewa yang disahkan tidak bermakna datanya selamat secara automatik. Model keselamatan harus merangkumi Arrow Columnar Format, C Data Interface, dan IPC dan bukannya hanya bergantung pada tetapan lalai pengikatan satu bahasa sahaja.

2. Nyatakan andaian keselamatan Arrow

Format lajur menerangkan penimbal, panjang, ofset, peta bit nol (null bitmaps), kamus, dan susun atur bersarang. Sifar-salin mengurangkan penyalinan tetapi boleh membenarkan pengguna membaca kawasan memori yang diterangkan oleh input luar. Pelaksanaan yang selamat mengesahkan metadata terhadap penimbal sebenar sebelum menyerahkan data kepada enjin pengiraan.

Jangan samakan spesifikasi format yang sah dengan input yang telah disahkan. Versi protokol, jenis sambungan, dan pelaksanaan bahasa mempunyai sempadan yang berbeza. Tetapkan versi dan set jenis yang disokong, dan tentukan dasar yang jelas untuk medan yang tidak diketahui.

3. Sahkan skema, panjang, dan ofset

Peringkat pertama hanya menghuraikan metadata yang terhad dan memeriksa bilangan medan, kedalaman sarang, jenis data, rujukan kamus, dan had baris kelompok. Bagi setiap penimbal, sahkan bahawa offset + length tidak boleh melimpah (overflow) dan berada dalam peruntukan sebenar. Untuk rentetan dan senarai panjang berubah-ubah, sahkan ofset monotonik yang kekal di dalam penimbal nilai.

if offset < 0 or length < 0: reject
if offset > buffer_size: reject
if length > buffer_size - offset: reject
if nesting_depth > MAX_DEPTH: reject

Gunakan aritmetik selamat limpahan, tolak integer negatif atau yang terlampau besar serta kiraan nol yang tidak serasi dengan skema. Jangan sekali-kali memperuntukkan panjang yang diisytiharkan oleh penyerang sebelum pengesahan.

4. Gunakan belanjawan sumber dan tekanan belakang (backpressure)

Tetapkan belanjawan setiap permintaan untuk bait metadata, lajur, baris, jumlah bait penimbal, kedalaman sarang, saiz kamus, dan masa CPU. Salurkan belanjawan ke dalam setiap penghurai kelompok; batalkan permintaan dan lepaskan peruntukan serta-merta apabila ia melebihi had.

Gunakan bacaan terhad dan tekanan belakang kelompok untuk strim IPC dan bukannya memuatkan keseluruhan muat naik ke dalam memori sekali gus. Hadkan pengembangan daripada pemampatan, kamus, dan rujukan berulang supaya input kecil tidak boleh menjadi peruntukan yang besar. Asingkan kuota bagi setiap penyewa supaya satu permintaan berniat jahat tidak dapat menggunakan semua pekerja (workers).

5. Tentukan bila perlu mengekalkan sifar-salin dan bila perlu menyalin

Kekalkan sifar-salin baca sahaja hanya selepas membuktikan pemilikan penimbal, jangka hayat (lifetime), dan batasannya, serta mengesahkan bahawa kod hiliran tidak boleh mengubahnya. Penimbal terima rangkaian, mmap sementara, atau memori FFI rentas bahasa yang mungkin dilepaskan, digunakan semula, atau ditulis mestilah disalin ke dalam arena terkawal.

Menyalin bukanlah satu kegagalan; ia adalah sempadan keselamatan yang mengubah jangka hayat yang tidak dipercayai kepada jangka hayat yang terkawal. Pilih bagi setiap lajur: kongsi penimbal numerik yang disahkan, dan salin rentetan, kamus, atau lajur bersarang apabila belanjawan mengizinkan. Catat bait yang disalin dan kependaman daripada menyembunyikan risiko di sebalik "sifar-salin penuh."

6. Asingkan penghuraian, ralat, dan keserasian

Jalankan penghurai dalam pekerja atau proses yang dikekang dengan had CPU, memori, deskriptor fail, dan masa dinding (wall-time). Kembalikan sebab berstruktur seperti versi tidak disokong, ketidakpadanan skema, ofset di luar batas, atau belanjawan melebihi had; jangan sekali-kali memaparkan semula muatan mentah atau alamat dalaman.

Gunakan senarai izin untuk jenis sambungan, metadata tidak diketahui, dan medan masa hadapan. Untuk keserasian, tukar kepada skema dalaman sebelum memasuki enjin pertanyaan. Sebelum menaik taraf Arrow 25 atau pengikatan bahasa, jalankan korpus berniat jahat yang sama sebagai ujian kebezaan dan bandingkan kelas ralat, memori puncak, dan keputusan.

7. Perhati, lakukan fuzzing, dan bertindak balas terhadap insiden

Catat penyewa, versi format, cincangan (hash) skema, sebab penolakan, saiz input, tempoh penghuraian, memori puncak, bait yang disalin, dan pembatalan; buat cincangan muatan daripada mencatat kandungan sensitif dalam log. Beri amaran pada setiap kelas penolakan dan bezakan klien yang salah konfigurasi daripada serangan berterusan.

Lakukan fuzzing pada skema rawak, ofset, peta bit nol, kamus, dan strim yang dipotong, menggunakan AddressSanitizer, MemorySanitizer, atau alat yang setara untuk mengesan nahas dan akses di luar batas. Simpan pembiak baka minimum (minimized reproducers) dan lakukannya semula sebagai ujian regresi selepas pembaikan. Untuk anomali pengeluaran, asingkan penyewa atau versi format terlebih dahulu, kemudian analisa sampel dan putar kelayakan yang terjejas.

8. Rubrik dan susulan

Mesti dijelaskan

• Anggap metadata, penimbal, dan skema perniagaan Arrow sebagai tidak dipercayai; sahkan panjang, ofset, kedalaman, dan rujukan kamus.
• Kawal memori dan CPU dengan belanjawan, tekanan belakang, dan pemencilan daripada menganggap sifar-salin sebagai matlamat tanpa syarat.
• Sediakan sempadan salinan, ralat berstruktur, fuzzing, keterlihatan, dan strategi peningkatan taraf.

Soalan susulan

• Satu lajur rentetan mempunyai ofset monotonik, tetapi nilai akhir melebihi penimbal. Pada lapisan manakah anda menolaknya?
• Bagaimanakah anda menghalang kamus atau senarai bersarang daripada berkembang menjadi kos sumber tanpa had?
• Bagaimanakah anda membuktikan bahawa pengikatan Python, Rust, dan Java mencapai kesimpulan yang sama untuk satu input berniat jahat?

Panduan pemarkahan

Jawapan yang cemerlang menghubungkan pengesahan format, tadbir urus sumber, pemilikan memori, dan bukti masa jalan: tolak susun atur yang mustahil, gunakan kelompok dalam lingkungan belanjawan, dan buktikan dengan pemencilan, fuzzing, dan metrik bahawa input yang tidak dipercayai tidak boleh menjadi kegagalan seluruh perkhidmatan.