Kotak Pasir dalam Cohere AI Terrarium: Fungsi, Risiko dan Kerentanan Kritikal

Informatec Digital » Sumber » Kotak Pasir dalam Cohere AI Terrarium: Fungsi, Risiko dan Kerentanan Kritikal

Apabila kita bercakap tentang menjalankan kod Python yang tidak dipercayai atau dijana AI , salah satu cabaran terbesar adalah bagaimana untuk melakukannya dengan selamat , cepat dan tanpa membelanjakan wang yang banyak untuk infrastruktur. Dalam konteks inilah Terrarium muncul, penyelesaian daripada Cohere AI yang direka bentuk sebagai kotak pasir untuk mengehos dan menjalankan kod jenis ini dalam bekas yang digunakan di awan, terutamanya di Google Cloud Run.

Pendekatan ini membolehkan pembangun dan syarikat memanfaatkan Terrarium sebagai persekitaran terpencil untuk menggunakan kod pengguna atau model LLM pada kos yang berpatutan dan prestasi yang agak baik. Walau bagaimanapun, dari semasa ke semasa, kelemahan yang sangat serius juga telah terbongkar , termasuk satu dengan pengecam CVE yang mendedahkan kelemahan kritikal dalam keselamatan kotak pasir dan telah meletakkan Terrarium dalam perhatian.

Apakah itu Terarium dan untuk apa ia direka bentuk?

Terrarium pada asasnya merupakan persekitaran runtime terpencil untuk Python , yang direka bentuk untuk berfungsi sebagai bekas Docker yang boleh digunakan , contohnya, di Google Cloud Run. Tujuan utamanya adalah untuk menyediakan kotak pasir di mana kod yang berpotensi berbahaya atau tidak diketahui (seperti skrip yang dihantar pengguna atau coretan yang dijana bahasa) boleh digunakan tanpa membahayakan infrastruktur utama secara langsung.

Falsafah di sebalik projek ini tertumpu pada penyediaan perkhidmatan yang berpatutan dan berkependaman rendah yang mudah diintegrasikan ke dalam aliran kerja sedia ada. Terrarium direka bentuk untuk dipanggil melalui permintaan HTTP, menghantar kod Python untuk dilaksanakan—dan secara pilihan memasukkan fail—dan menerima kembali hasil pelaksanaan bersama-sama dengan fail yang dijana.

Dalam praktiknya, ini bermakna sistem luaran, API atau alat dalaman boleh mewakilkan pelaksanaan kod Python kepada Terrarium , memastikan kod tersebut berada dalam persekitaran yang agak terhad, dengan peraturan yang jelas tentang sumber, masa pelaksanaan dan keupayaan yang dibenarkan.

Salah satu ciri reka bentuk utama Terrarium ialah pergantungannya pada Pyodide, binaan CPython kepada WebAssembly yang dilaksanakan dalam proses Node.js. Pendekatan ini bermakna kod Python tidak berjalan secara natif pada sistem hos, tetapi sebaliknya dalam penterjemah yang dienkapsulasi, secara teorinya mengukuhkan pengasingannya.

Prestasi, kos dan ciri utama kotak pasir

Salah satu daya tarikan Terrarium yang paling kuat ialah gabungan kos operasi yang rendah dan prestasi yang boleh diterima . Dalam penggunaan dunia sebenar di Google Cloud Run, dengan konfigurasi tipikal memori 2 GB, 1 vCPU dan sekurang-kurangnya satu contoh sentiasa aktif dengan penskalaan automatik atas permintaan, kos bulanan yang dilaporkan adalah sekitar $30 semasa fasa anotasi dalaman.

Dari segi kelajuan, ujian yang diterangkan menunjukkan bahawa Terrarium boleh menjana, sebagai contoh, imej PNG 200 dpi bagi plot matplotlib ringkas dalam masa jalan sekitar 900 ms atau versi SVG dalam masa kira-kira 500 ms. Masa ini merujuk kepada kod yang dihoskan pada Cloud Run, termasuk kitaran pemanggilan biasa perkhidmatan.

Selain prestasi, Terrarium mempunyai pengasingan lengkap antara pemanggilan . Selepas setiap panggilan, kotak pasir dikitar semula sepenuhnya: sistem fail maya Pyodide, pembolehubah global, pustaka yang dimuatkan dan sebarang keadaan dalaman dibuang. Matlamatnya adalah untuk menghalang sebarang pemanggilan daripada mewarisi data atau konteks daripada pelaksanaan sebelumnya, sekali gus mengurangkan risiko kebocoran maklumat.

Satu lagi perkara penting ialah, walaupun pengasingan yang teguh adalah matlamatnya, Cohere menjelaskan bahawa ia tidak menawarkan jaminan mutlak mengenai integriti sandbox . Ini telah pun membayangkan bahawa, meskipun terdapat lapisan perlindungan, terdapat kemungkinan kelemahan dapat ditemui, terutamanya dalam persekitaran yang serumit WebAssembly dan integrasinya dengan Node.js.

Terrarium direka bentuk agar mudah digunakan daripada perkhidmatan lain: hanya hantar permintaan HTTP ke titik akhir yang digunakan pada Cloud Run, bersama-sama dengan kod yang akan dilaksanakan dan token kebenaran (jika diperlukan oleh konfigurasi). Sebagai balasan, anda akan menerima fail JSON dengan hasilnya dan, jika berkenaan, fail yang dijana yang dikodkan dalam base64.

Pelaksanaan fail dan sokongan pustaka dalam Pyodide

Salah satu ciri menarik Terrarium ialah keupayaannya untuk berfungsi dengan fail input dan output secara asli . API membenarkan berbilang fail daripada sebarang jenis dilampirkan bersama-sama dengan kod Python dalam permintaan; fail-fail ini diletakkan dalam sistem fail maya yang didedahkan oleh Pyodide kepada penterjemah Python.

Semasa pelaksanaan, kod Python boleh membaca dan memanipulasi fail-fail ini seolah-olah ia berada di dalam kotak pasir. Setelah pelaksanaan selesai, Terrarium akan mengumpul semua fail yang dibuat atau diubah suai dan mengembalikannya sebagai respons kepada klien, biasanya dikodkan untuk pemindahan yang lancar melalui HTTP.

Berkenaan ekosistem perpustakaan, berdasarkan Pyodide, Terrarium mewarisi satu set pakej analisis saintifik dan data yang agak luas . Pakej yang disokong secara langsung termasuk: numpy, pandas, matplotlib, sympy, beautifulsoup4, python-sat, scikit-learn, scipy dan sqlite3 (yang terakhir tidak diaktifkan secara lalai, tetapi dengan pilihan untuk memuatkannya jika perlu).

Dalam kes khusus matplotlib, terdapat beberapa batasan: plt.show() tidak disokong dalam persekitaran ini, tetapi penggunaan plt.savefig() untuk menjana imej berfungsi dengan betul, selagi parameter berlebihan tidak dipaksa, seperti resolusi yang sangat tinggi yang akan meningkatkan penggunaan sumber.

Set pustaka ini menjadikan Terrarium amat berguna untuk tugasan seperti analisis data, visualisasi, prototaip model pembelajaran mesin dan manipulasi maklumat berstruktur, semuanya dilaksanakan dalam kotak pasir yang dikawal secara teorinya.

Seni bina dalaman: lapisan pengasingan dan penggunaan

Seni bina Terrarium dibina dalam beberapa lapisan yang direka untuk mengurangkan permukaan serangan dan mengasingkan kod yang tidak dipercayai sebanyak mungkin . Lapisan pertama ialah proses Node.js itu sendiri, yang bertindak sebagai hos dan memuatkan Pyodide, iaitu CPython yang dikompilasi ke WebAssembly.

Kod Python yang dihantar oleh pengguna dihuraikan, dikompilasi dan dilaksanakan dalam persekitaran WebAssembly , bukan secara natif pada sistem hos. Pendekatan ini secara semula jadi mengehadkan apa yang boleh dilakukan oleh kod, memandangkan Pyodide menggunakan sistem fail maya dalam memori, kekurangan akses langsung ke cakera hos dan tidak mempunyai keupayaan pemprosesan latar belakang tradisional.

Antara sekatan yang paling relevan ialah: tiada akses kepada sistem fail sebenar (hanya sistem fail maya dalaman Pyodide), ketiadaan threading dan multiprocessing sepenuhnya, ketidakupayaan untuk melancarkan subproses, tiada akses kepada memori hos yang menjalankan Node.js, tiada perkongsian keadaan antara panggilan (memandangkan keseluruhan persekitaran dimulakan semula), dan, secara reka bentuk, tiada akses kepada rangkaian atau internet . Had terakhir ini bertujuan sebagai keputusan reka bentuk yang boleh disemak semula pada masa hadapan, tetapi pada mulanya menambah satu lagi lapisan perbalahan.

Lapisan pengasingan kedua ialah penggunaan awan itu sendiri: proses Node.js berjalan di dalam bekas Docker , yang digunakan pada Google Cloud Run. Ini bukan sahaja mengehadkan masa jalan dan sumber yang tersedia tetapi juga memisahkan bekas yang menjalankan kod daripada mana-mana bahagian lain infrastruktur organisasi sekiranya berlaku pelanggaran kotak pasir hipotetikal.

Secara ringkasnya, reka bentuk asal Terrarium bergantung pada gabungan WebAssembly, Docker dan Cloud Run untuk membina persekitaran yang agak selamat untuk pelaksanaan Python, dengan halangan berturut-turut yang merumitkan pelarian dari kotak pasir ke sistem hos dan rangkaian dalaman.

Pelaksanaan setempat, pelaksanaan Docker dan pelaksanaan Google Cloud Run

Untuk menggunakan Terrarium dalam persekitaran pembangunan, Node.js perlu dipasang pada mesin . Setelah keperluan itu dipenuhi, prosedur biasa terdiri daripada memasang kebergantungan projek dan menjalankan pelayan setempat, bersama-sama dengan fungsi yang mengendalikan permintaan pelaksanaan kod.

Dengan pelayan berjalan, permintaan boleh dibuat kepada titik akhir setempat untuk menghantar fail ujian dan skrip Python , yang membolehkan pembangun mengesahkan tingkah laku kotak pasir sebelum digunakan ke persekitaran pengeluaran. Skrip tersedia untuk menjalankan suit ujian pada semua fail .py dalam direktori ujian, memudahkan pengesahan persekitaran.

Dalam persekitaran kontena, Terrarium boleh dibina sebagai imej Docker dan dijalankan sebagai kontena kendiri . Arahan biasa termasuk langkah bina, jalankan dan hentikan, serta arahan untuk mencari pengecam kontena yang sedang berjalan dan mengurusnya secara manual jika perlu.

Apabila Terrarium berhijrah ke Google Cloud Run, ia telah digunakan sebagai perkhidmatan HTTP penskalaan automatik dengan parameter sumber dan keserentakan yang boleh dikonfigurasikan. Adalah dinasihatkan untuk melaraskan nilai ini untuk mengimbangi prestasi, kos dan keselamatan . Contohnya, untuk beban kerja yang intensif, lebih banyak CPU dan memori boleh diperuntukkan dan keserentakan setiap tika boleh dihadkan untuk mengelakkan penyekatan.

Penting untuk diperhatikan bahawa Pyodide, apabila dikonfigurasikan untuk Terrarium, berjalan dalam proses utama Node.js. Ini bermakna jika kod Python anda menjadi sangat intensif sumber atau memasuki gelung yang kompleks, ia boleh menyekat keupayaan Node.js untuk bertindak balas terhadap permintaan lain. Pyodide mencadangkan penggunaan Workers untuk senario di mana perlu mengganggu atau mengasingkan pelaksanaan selanjutnya, tetapi pendekatan ini merumitkan integrasi dan, dalam beberapa kes, mengehadkan sokongan untuk perpustakaan seperti matplotlib.

Pengurusan perkhidmatan kesihatan dan isu kestabilan

Dalam penggunaan pada Google Cloud Run, salah satu cabaran praktikal adalah memantau kesihatan perkhidmatan dan pemulihan daripada ranap sistem . Cloud Run, secara lalai, tidak menyokong pemeriksaan kesihatan secara langsung yang ditakrifkan dalam Dockerfiles menggunakan HEALTHCHECK, jadi sedikit pelarasan tambahan diperlukan.

Prosedur biasa melibatkan penerangan perkhidmatan Cloud Run dengan gcloud , mengeksport konfigurasi ke fail service.yaml. Dalam YAML tersebut, konfigurasi livenessProbe telah ditambah, yang dikaitkan dengan imej kontena, supaya Cloud Run dapat mengesan bila perkhidmatan berhenti bertindak balas dengan betul.

Sebaik sahaja konfigurasi diubah suai, perkhidmatan sedia ada digantikan dengan arahan gcloud yang sesuai, supaya Cloud Run akan memantau status kontena secara aktif dan memulakannya semula jika pemeriksaan langsung gagal. Operasi ini hanya diperlukan pada kali pertama perkhidmatan baharu digunakan dengan imej khusus tersebut.

Pada peringkat Docker tulen, terdapat batasan tambahan: enjin Docker itu sendiri tidak menawarkan permulaan semula automatik berdasarkan semata-mata pada HEALTHCHECK . Tambahan pula, proses dengan PID 1 dalam kontena amat dilindungi dan tidak begitu mudah untuk ditamatkan dari dalam. Oleh itu, dalam sesetengah persekitaran, penggunaan alat pihak ketiga seperti docker-autoheal dipertimbangkan, yang memantau kesihatan kontena dan memaksa permulaan semula apabila masalah dikesan.

Berkenaan kestabilan pelaksanaan, pasukan tersebut mendapati bahawa ralat seperti "RangeError: Saiz tindanan panggilan maksimum melebihi" kerap muncul dalam Pyodide semasa mengendalikan beban kerja yang sangat berat. Ini lebih biasa berlaku apabila menggunakan nilai dpi yang sangat tinggi dalam penjanaan PNG dengan matplotlib atau semasa melaksanakan operasi panda yang sangat kompleks, menunjukkan batasan dalaman dalam pengurusan tindanan dalam persekitaran WebAssembly.

Kerentanan kritikal CVE-2026-5752 dalam Terrarium

Lama-kelamaan, satu kelemahan kritikal telah ditemui dalam Terrarium , yang dikenal pasti sebagai CVE-2026-5752 dan diberi penarafan 9,3 pada skala CVSS. Tahap keterukan ini menunjukkan kecacatan yang berpotensi memberi impak yang sangat tinggi terhadap keselamatan sistem yang menggunakan sandbox ini.

Kerentanan ini membolehkan penyerang melakukan pelaksanaan kod sewenang-wenangnya dengan keistimewaan root dalam proses hos . Vektor serangan bergantung pada penelusuran rantai prototaip berniat jahat dalam persekitaran Pyodide WebAssembly, dengan berkesan memintas sekatan kotak pasir.

Aspek yang paling membimbangkan ialah mengeksploitasi kelemahan ini tidak memerlukan keistimewaan khas atau interaksi pengguna tambahan . Penyerang yang boleh menyuntik kod ke dalam kotak pasir (contohnya, dengan mengeksploitasi fungsi pelaksanaan kod dalam alat yang menggunakan Terrarium) boleh memanfaatkan kelemahan ini untuk keluar dari persekitaran terkawal.

Sebaik sahaja dieksploitasi, kerentanan ini boleh membenarkan akses tanpa kebenaran kepada fail sistem sensitif , seperti /etc/passwd atau sumber kontena dalaman yang lain , dan juga membolehkan peningkatan kepada hos atau perkhidmatan lain yang berkongsi infrastruktur yang sama, bergantung pada konfigurasi keselamatan keseluruhan.

Situasi ini menimbulkan risiko yang ketara kepada semua organisasi yang menggunakan Terrarium sebagai kod pengguna atau persekitaran pelaksanaan model AI . Ia bukan sekadar kelemahan teori, tetapi senario di mana pelanggaran kotak pasir boleh menyebabkan pendedahan data, gangguan perkhidmatan dalaman dan pergerakan lateral dalam rangkaian.

Kesan terhadap perniagaan, pembangun dan pengguna akhir

Penemuan kelemahan ini secara langsung menjejaskan mana-mana syarikat atau pembangun yang telah mengintegrasikan Terrarium ke dalam infrastruktur mereka untuk menjalankan kod Python yang tidak dipercayai . Alat pembangunan kolaboratif, platform pembelajaran, perkhidmatan analitik atas permintaan atau produk bantuan kod berasaskan AI boleh didedahkan jika mereka menggunakan Terrarium sebagai lapisan masa jalan mereka.

Dari sudut pandangan pengguna akhir, risikonya bukan sahaja infrastruktur penyedia perkhidmatan mungkin terjejas, tetapi juga maklumat peribadi atau profesional yang disimpan pada platform tersebut mungkin bocor atau dimanipulasi tanpa notis terlebih dahulu jika penyerang berjaya mengeksploitasi kerentanan tersebut.

Keadaan ini menjadi lebih rumit oleh fakta bahawa Terrarium tidak lagi diselenggara secara aktif . Ini bermakna tampalan rasmi untuk menyelesaikan masalah tersebut tidak dijangka, menyebabkan organisasi yang terus bergantung pada penyelesaian ini dengan kerentanan yang diketahui dan tiada sokongan.

Dalam konteks ini, penggunaan Terrarium secara berterusan tanpa langkah tambahan menimbulkan risiko keselamatan yang besar . Penyerang yang menyedari vektor eksploitasi boleh menyasarkan perkhidmatan yang terus menggunakan teknologi ini secara khusus, mencari kelemahan dalam keselamatan keseluruhan sistem.

Tambahan pula, dalam persekitaran di mana berbilang perkhidmatan berkongsi rangkaian dalaman yang sama atau kluster kontena yang sama, kebocoran dari Terrarium boleh membuka pintu kepada pergerakan lateral ke dalam sistem lain yang kelihatan terpencil , sekali gus menguatkan potensi impak serangan yang berjaya.

Strategi dan alternatif mitigasi untuk dipertimbangkan

Memandangkan kerentanan sebesar ini dan kekurangan penyelenggaraan aktif, cadangan pertama untuk organisasi adalah untuk segera menilai penggunaan Terrarium mereka semasa . Jika ia digunakan untuk menjalankan kod pihak ketiga atau kod yang dijana oleh model AI, pendedahan adalah lebih besar dan memerlukan tindakan segera.

Langkah-langkah jangka pendek termasuk melumpuhkan sementara ciri-ciri yang membenarkan pelaksanaan kod sewenang-wenangnya dalam pengeluaran sementara alternatif yang lebih selamat dinilai. Pilihan lain termasuk mengukuhkan dasar rangkaian, menyegmentasikan perkhidmatan yang menggunakan Terrarium selanjutnya dan menyekat akses kepada kontena daripada sistem lain.

Dalam jangka masa sederhana, mungkin lebih bijak untuk berhijrah kepada penyelesaian sandboxing atau pelaksanaan terpencil lain yang mempunyai penyelenggaraan aktif dan komuniti atau penyedia di belakangnya untuk menampal kelemahan. Ini mungkin melibatkan perkhidmatan terurus, persekitaran pelaksanaan tanpa pelayan dengan sekatan yang lebih ketat atau seni bina mikroservis yang direka bentuk khusus dengan keselamatan secara lalai.

Walau apa pun, insiden ini menekankan kepentingan mengintegrasikan amalan keselamatan yang baik ke dalam kitaran hayat pembangunan : audit kebergantungan yang kerap , semakan komponen pihak ketiga yang digunakan dalam seni bina, pemantauan CVE yang berkaitan dan pelan tindak balas pantas apabila kegagalan kritikal dikesan.

Syarikat yang membina alatan berasaskan AI yang membolehkan pengguna akhir menjalankan atau menjana kod harus menganalisis reka bentuk kotak pasir mereka dengan teliti , memastikan proses pengasingan sentiasa dikemas kini dan mengelakkan bergantung pada projek terbengkalai untuk fungsi sensitif seperti menjalankan kod yang tidak dipercayai.

Segala-galanya tentang Terrarium mencerminkan sejauh mana kod pengguna dan model LLM yang dijalankan memerlukan pendekatan keselamatan yang ekstrem . Kotak pasir berprestasi tinggi dan berkos rendah mungkin kelihatan sangat menarik, tetapi jika kerentanan kritikal muncul tanpa tampalan yang kelihatan, keseimbangan akan terganggu dan risiko menjadi tidak boleh diterima untuk banyak kes penggunaan yang serius.