Teku dan Besu telah mengemas kini imej Docker masing-masing selepas insiden eMudhra, kerana kunci sijil yang lemah membawa risiko kepada perisian yang menyambung ke perkhidmatan luar, termasuk beberapa penghuraian pengesah Ethereum.
- Teku 26.10.3 dan Besu 26.10.2 telah menghapus kepercayaan sijil yang terkesan dalam imej Docker akibat peristiwa eMudhra.
- Teku menyatakan, nod rangkaian utama lalai tidak terjejas, dan tahap paparan sebenar bergantung kepada sambungan HTTPS serta runtime Java yang digunakan oleh pengendali.
- Risiko yang diungkapkan berkaitan dengan perkhidmatan dan pengesah operasi yang disamar, tetapi tiada kes dimanfaatkan dilaporkan dalam pemberitahuan Teku.
Masalah paling langsung bagi pengendali ialah: apakah perisian mereka akan menerima sijil palsu semasa menyambungkan ke perkhidmatan lain. Jawapannya bergantung pada sambungan yang digunakan dan pemasangan Java, jadi kemas kini klien tidak bermaksud setiap pengesah menghadapi risiko yang sama.
Perbaharui imej Docker Teku dan Besu
Timm penghala Ethereum telah menerbitkan kemas kini untuk memperbaiki masalah sijil yang bermula di luar blok rantai. Perubahan yang berkaitan melibatkan cara perisian menentukan sama ada perkhidmatan jauh itu sah.
Teku 26.10.3 dan Besu 26.10.2 telah menghapus kepercayaan terhadap akar sijil yang terkesan daripada imej Docker mereka. Pelancaran ini timbul akibat penemuan kunci lemah yang berkaitan dengan penerbit sijil eMudhra.
Bagi pengendali validator, masalahnya ialah penyerang menyamar sebagai perkhidmatan yang disambungkan oleh perisian. Bergantung pada peranan perkhidmatan tersebut, respons palsu boleh mengganggu tanggungjawab, atau mempengaruhi arah pembayaran caj blok tertentu.
Namun, ini tidak bermakna setiap penverifikasi Ethereum terdedah kepada risiko. Pemberitahuan keselamatan Teku menyatakan bahawa nod rangkaian utama laluan tidak terjejas, dan tiada laporan penggunaan dimaklumkan pada masa ini.
Perbezaannya terletak pada cara pemasangan. Pengendali yang menggunakan perkhidmatan HTTPS luaran perlu memeriksa sambungan yang mungkin tidak wujud dalam pelaksanaan komponen sepenuhnya tempatan.
Kemas kini ini berlaku untuk persekitaran pemasangan tertentu. Imej Docker selepas patch mengandungi modifikasi runtime yang dibungkus dalam kontena, manakala perisian yang dipasang daripada fail arsip mungkin menggunakan Java yang disediakan secara berasingan oleh pengendali.
Peristiwa ini mempengaruhi infrastruktur di sekitar validator, manakala peraturan konsensus Ethereum tidak berubah.
Mengapa masalah sijil boleh berubah menjadi risiko keselamatan?
Sijil membantu perisian menentukan sama ada ia terhubung ke perkhidmatan yang diharapkan. Lembaga penerbit sijil yang dipercayai akan memberi sokongan terhadap identiti yang berkaitan dengan sijil pelayan.
Mekanisme ini biasa digunakan dalam laman web HTTPS, tetapi juga berlaku untuk aplikasi yang tidak berkomunikasi melalui pelayar. Perkhidmatan latar belakang juga mungkin bergantung pada pengesahan identiti ini.
Pihak penerbit sijil mungkin menggunakan sijil perantara di bawah sijil akar yang dipercayai. Kunci sulit yang berkaitan dengan sijil perantara ini mesti dikekalkan keselamatannya, kerana ia boleh digunakan untuk mengeluarkan lebih banyak sijil.
Dalam kejadian ini, masalah bukan sahaja seseorang mendapat maklumat log masuk biasa ke pelayan. Kunci sederhana yang terjejas boleh dipulihkan daripada maklumat yang sudah diumumkan.
Penerangan daripada pasukan keselamatan Go menyatakan bahawa kelemahan ini membolehkan pemulihan kunci peribadi pada peringkat mikro saat. Penerangan itu juga menunjukkan bahawa penyerang kemudian boleh mencipta sijil untuk domain yang tidak mereka kawal.
Sesuatu aplikasi yang rentan mungkin menerima sijil tersebut jika ia menganggap sijil itu akhirnya boleh dilacak kembali kepada pihak yang dipercayainya. Dengan cara ini, penyamaran boleh lulus pemeriksaan yang seharusnya menolak penipu.
Namun, penyerang masih memerlukan cara tertentu untuk mengintersep atau mengalihkan sambungan mangsa. Kunci lemah tidak secara automatik meletakkan mereka di antara setiap pengguna dan setiap pelayan.
Syarat ini mempersempit cara serangan berlaku, tetapi tidak menjadikan pencabutan sijil tidak berbahaya. Selagi perisian menganggap peniru sebagai titik akhir yang sah, penyekatan rangkaian akan menjadi lebih berbahaya.
Penyelidikan Kudelski Security mengkaji peringkat sijil yang terkesan. Masalahnya ialah, perisian mungkin menerima sijil yang ditandatangani oleh kunci yang boleh diperbanyak oleh penyerang.
eMudhra menyalahkan kunci lemah kepada kesalahan pemprosesan
Pernyataan insiden eMudhra menyatakan bahawa seorang penyelidik melaporkan 8 kunci tengah lemah pada 17 Oktober. Syarikat tersebut mencabut 8 kunci tersebut pada hari berikutnya.
Syarikat menyatakan bahawa sijil perantara ini dihasilkan semasa upacara kunci pada 30 April 2025. Menurut syarikat, langkah wrap dan unwrap yang cacat menghasilkan salinan lemah selain kunci kuat asal.
Syarikat menyatakan telah menggunakan modul keselamatan peranti yang disahkan. Penjelasannya menyalahkan kegagalan kepada satu langkah dalam proses sekeliling, bukan kepada kekurangan peranti semacam itu.
Perusahaan juga menyatakan bahawa 7 sijil perantara tersebut tidak pernah digunakan dalam persekitaran pengeluaran, dan satu lagi belum dikeluarkan sijil. Perusahaan menegaskan bahawa insiden ini tidak menyebabkan infrastruktur disusupi atau kebocoran data.
Pernyataan-pernyataan ini menjelaskan gambaran eMudhra terhadap operasi dalaman mereka. Namun, pemasok perisian masih perlu menghadapi kemungkinan lain: pihak lain mungkin memanfaatkan kunci yang boleh dipulihkan.
Sistem sijil tidak boleh hanya bergantung pada janji pihak operasi asal untuk tidak mengeluarkan apa-apa lagi. Sekali pihak lain dapat mereplikasi kunci tanda tangan tertentu, jaminan ini tidak lagi boleh mengawal semua sijil yang mungkin dicipta.
Oleh itu, tindakan respons telah melampaui syarikat yang menghasilkan kunci tersebut. Pengilang browser, pembekal sistem pengendalian, dan pasukan bahasa pengaturcaraan perlu mempertimbangkan perisian apa yang akan diterima oleh pengguna mereka.
Pembaikan-pembaikan ini akan disampaikan kepada pengguna melalui kemas kini yang berbeza. Penyemak imbas mungkin menerima senarai blok, sementara aplikasi Java yang berasingan mungkin masih terus menggunakan set sijil dipercayai lama.
Kunci lemah dan aplikasi yang menerima kunci tersebut adalah dua bahagian berbeza kepada masalah yang sama. Pencabulan sijil menyelesaikan masalah pada tahap rekod institusi, manakala klien masih memerlukan cara yang boleh dipercayai untuk mengenal pasti laluan kepercayaan yang perlu ditolak.
Perkhidmatan luar membawa risiko yang berbeza kepada validator
Node Ethereum terdiri daripada perisian yang menjalankan tugas yang berbeza. Dokumentasi klien Ethereum membezakan klien pelaksanaan dan klien konsensus: yang pertama menangani pelaksanaan transaksi dan status, manakala yang kedua mengikuti konsensus proof-of-stake.
Perisian validator menambah tanggungjawab mencadangkan blok dan membuktikan rantai. Pengendali boleh menjalankan komponen-komponen ini secara tempatan atau menyambungkan sebahagiannya melalui perkhidmatan luar.
Teku adalah klien konsensus, Besu adalah klien pelaksana. Keduanya menggunakan Java, yang merupakan sebab mengapa kepercayaan sijil semasa berjalan berkaitan dengan pelepasan mereka.
Perkhidmatan di luar mesin tempatan akan menambahkan pengesahan identiti kepada susunan ini. Perisian perlu mengesahkan bahawa endpoint yang merespons permintaan adalah penyedia yang diharapkan.
Sebagai contoh, pengendali mungkin menggunakan perkhidmatan tanda tangan jauh, bukan menyimpan operasi tanda tangan dalam proses yang sama. Ada juga yang bergantung pada titik akhir luaran untuk menyediakan data atau perkhidmatan pembinaan blok.
Kesan yang boleh ditimbulkan oleh penipu bergantung kepada apa yang dibenarkan dilakukan oleh perkhidmatan tersebut. Perkhidmatan yang hanya menerima data pemantauan mempunyai risiko yang berbeza berbanding perkhidmatan penyedia maklumat yang terlibat dalam keputusan tanda tangan.
Laluan rangkaian juga penting. Sambungan yang melalui infrastruktur awam mempunyai peluang penyadapan yang berbeza berbanding komponen yang hanya terhad kepada hos yang sama atau rangkaian peribadi yang dikawal ketat.
Jaringan peribadi tidak dapat mengelakkan semua kegagalan, tetapi ia boleh mengurangkan peluang penyerang mendapatkan lokasi yang diperlukan untuk mengganggu trafik.
Oleh itu, nama klien sahaja tidak boleh digunakan untuk menentukan sama ada terdedah atau tidak. Perisian yang sama boleh dideploy dalam persekitaran yang menggunakan titik akhir, perpustakaan kepercayaan, dan kawalan akses yang berbeza.
Masalah yang sebenarnya perlu dijawab ialah: sambungan mana yang melalui laluan yang terkesan menerima sijil. Setelah ini dikenal pasti, pengendali boleh menilai sejauh mana kuasa yang sepatutnya dimiliki oleh perkhidmatan yang disamar semasa pengesahan.
Mengapa imej Docker dan pemasangan arkib berbeza?
Imej Docker akan mengemas aplikasi bersama dengan persekitaran yang diperlukan untuk menjalankannya, yang mungkin termasuk runtime Java serta sijil yang dipercayai oleh runtime tersebut.
Memperbaharui Java di hos tidak akan menggantikan Java yang sudah ada dalam imej. Kontainer mungkin masih terus menggunakan fail yang dibundel sendiri.
Inilah sebabnya penerangan klien secara khusus menyebut perubahan Docker. Penerangan Teku menyatakan bahawa imej asas Eclipse Temurinnya belum mengandungi pembuangan berkaitan pada masa itu, oleh itu imej klien telah dimodifikasi secara langsung.
Nota rilis Besu juga menyatakan bahawa penghapusan sijil berlaku untuk imej Docker, dan secara jelas meminta pengguna yang memasang untuk memeriksa edisi Java yang mereka sediakan.
Pengarsipan pemasangan akan menyerahkan tanggung jawab ini kepada pengendali. Klien Ethereum mungkin telah dikemas kini, tetapi runtime tersendirinya mungkin masih mengandung penyimpanan sijil lama.
Sebaliknya, perbezaan serupa juga berlaku semasa pemeliharaan. Mengganti hos runtime akan mempengaruhi proses yang menggunakan runtime tersebut, tetapi tidak akan mempengaruhi pemasangan lain yang menggunakan laluan Java yang berbeza.
Peristiwa Oracle menasihatkan pengguna untuk mengemas kini runtime yang terjejas, atau mengikuti alternatif yang diberikan dalam dokumennya. Ia juga memerlukan peningkatan semula contoh yang sedang berjalan, serta mempertimbangkan setiap pemasangan berasingan.
Ini menjadikan proses yang sedang berjalan lebih penting daripada pembaruan yang telah dimuat turun. Pelayan boleh mengandungi fail yang telah dipatch, tetapi proses lama akan terus berjalan sehingga diganti atau dimulai semula.
Penyimpanan sijil tersuai kini menambahkan satu lagi variasi. Sesuatu organisasi mungkin menggunakan perpustakaan sijil yang diselenggarakan sendiri untuk perkhidmatan mereka, bukan hanya perpustakaan sijil yang disediakan secara lalai oleh Java.
Tugas sebenarnya adalah menentukan apa yang sebenarnya digunakan oleh klien. Cara pemasangan, lokasi masa berjalan, dan konfigurasi kepercayaan secara bersama-sama menentukan sama ada pembaikan yang telah dikeluarkan telah sampai ke sambungan yang memerlukannya.
Perbezaan pemeriksaan pencabutan dalam aplikasi yang berbeza
Revokasi bermakna sijil tidak lagi seharusnya diterima. Namun, ini tidak menjamin setiap aplikasi akan memeriksa maklumat revokasi terkini sebelum membina sambungan.
Cara aplikasi yang berbeza mendapatkan maklumat ini juga berbeza. Sebahagian akan menghantar permintaan ke perkhidmatan dalam talian, sebahagian lagi menggunakan senarai blok yang disediakan oleh pembekal, dan ada yang bergantung terutamanya pada sijil dalam perpustakaan percaya tempatan.
Tanggapan pasukan Go menjelaskan mengapa pemasok runtime mungkin perlu terlibat secara langsung. Pasukan tersebut melancarkan rilis keselamatan kecemasan pada 19 Oktober dan menyatakan bahawa versi pembaikan telah disediakan dalam tempoh kira-kira 7.5 jam selepas menerima pemberitahuan.
Tindakan ini menghalangi laluan sijil yang terjejas yang terlibat dalam aplikasi yang menggunakan tindakan pengesahan Go yang berkaitan. Pengguna Java perlu mendapatkan perlindungan melalui runtime dan tetapan kepercayaan masing-masing.
Pemberitahuan Teku menyatakan bahawa Java secara lalai tidak akan memeriksa revokasi. Inilah sebabnya walaupun eMudhra telah mencabut sijil perantara ini, ia masih penting untuk menghapuskan kepercayaan secara tempatan.
Penghapusan sijil akar dan blok sijil perantara juga boleh bertindak pada peringkat yang berbeza. Yang pertama menolak laluan rosak tertentu, manakala yang kedua boleh menolak rantai sijil yang lebih luas yang menuju ke sijil akar yang dihapuskan.
Penerapan yang betul adalah tanggungjawab pemasok dan organisasi yang memelihara aplikasi. Mengambil tindakan sementara untuk menonaktifkan pengesahan identiti hanya akan menghilangkan perlindungan, bukan menyelesaikan masalah kepercayaan.
Perkhidmatan sah juga mungkin perlu disesuaikan. Jika sijil mereka bergantung pada laluan yang kini ditolak oleh klien, pihak perkhidmatan mesti menyediakan alternatif yang boleh diterima, bukan mengharapkan pengguna memulihkan kepercayaan yang tidak selamat.
Ini juga menjelaskan mengapa satu insiden sijil boleh berterusan selama beberapa hari. Penemuan mungkin segera, tetapi perlindungan akan diperkenalkan secara bertahap melalui proses pelancaran dan pengekalan yang berbeza pada peramban, aplikasi yang dipaketkan, dan infrastruktur persendirian.
Bagi pengendali validator, keputusan utama ialah sama ada sambungan yang berkaitan telah menolak identiti yang tidak dipercayai. Pengumuman revokasi di tempat lain dalam ekosistem perisian tidak membuktikan bahawa proses nod telah mencapai keputusan ini.
Adakah hadiah dan pengikatan validator terdedah dengan cara yang sama?
Pengikatan, tanggungjawab tanda tangan, dan pembayaran caj validator saling berkaitan, tetapi mereka dikawal oleh mekanisme yang berbeza. Masalah yang mempengaruhi salah satu daripada ini tidak seharusnya secara automatik digambarkan sebagai pengawasan terhadap semua perkara ini.
Dokumen penjagaan Ethereum menyatakan bahawa validator menerima ganjaran dengan melaksanakan tugas mereka, dan akan dikenakan hukuman jika tidak aktif atau melakukan kelakuan salah yang boleh dibuktikan. Kuasa tanda tangan dan kuasa penarikan memainkan peranan yang berbeza dalam sistem.
Kunci sijil adalah sebahagian daripada sistem pengenalan yang digunakan untuk sambungan. Ia bukan kunci tanda tangan peribadi penverifikasi, dan tidak mengungkapkan kredensial pengurusan penarikan ETH yang telah diikat.
Namun, perkhidmatan yang disamar itu masih mungkin mempengaruhi tingkah laku penverifikasi. Kesannya bergantung pada jenis permintaan atau respons yang ditangani oleh perkhidmatan tersebut, serta pemeriksaan tambahan apa yang masih dikekalkan.
Pencadangan blok mengandungi penerima bayaran bagi bayaran yang berkaitan dengan pelaksanaan. Jika suatu laluan mampu mengubah cadangan atau konfigurasi, ia boleh mengakibatkan kesan tanpa perlu mengawal keseluruhan penjaminan.
Perkhidmatan tanda tangan juga mengangkat sekumpulan masalah lain kerana ia terlibat dalam pengesahan tingkah laku penverifikasi. Langkah-langkah perlindungannya sendiri, termasuk had terhadap permintaan dan jaminan untuk mencegah tanda tangan yang bertentangan, akan mempengaruhi sejauh mana penyerang boleh bertindak.
Kegagalan tugas akibat gangguan perkhidmatan juga merupakan kesan yang mungkin berlaku. Walaupun tiada pembayaran berjaya dipindahkan, penyerang masih boleh mengurangkan ganjaran dengan menghalang respons yang betul.
Kesan kewangan bagi keputusan-keputusan ini tidak sama. Kehilangan peluang mencadangkan blok, hukuman offline biasa, dan hukuman slashing tidak boleh dicampuradukkan.
Penerangan pengumuman pelanggan menggambarkan kesan yang mungkin berlaku di bawah konfigurasi yang terjejas, tetapi tidak membuktikan bahawa setiap pengendali mengalami kesan-kesan ini, atau bahawa jumlah ETH yang sepadan telah dicuri.
Bagi pemegang yang menggunakan perkhidmatan staking, yang benar-benar relevan ialah penghantaran sebenar oleh perkhidmatan tersebut. Jumlah ETH yang dikelola tidak menunjukkan perkhidmatan jauh atau perpustakaan sijil apa yang digunakan oleh pengurusnya.
Pengesah juga bergantung pada perisian di luar Ethereum
Peraturan rangkaian Ethereum hanyalah sebahagian daripada apa yang bergantung kepada pengendali. Peranti keras, masa berjalan, pengendalian, konfigurasi, dan perkhidmatan luaran semuanya mempengaruhi sama ada penentu boleh memenuhi tanggungjawabnya dengan betul.
Lembaga penerbit sijil berada di luar protokol Ethereum, tetapi kegagalan ia menjadi relevan apabila perisian pengesah bergantung kepadanya untuk mengenal pasti perkhidmatan. Hanya dengan ini sahaja, ia sudah cukup untuk membawa masalah keselamatan internet umum ke dalam infrastruktur penjagaan.
Keragaman klien masih bernilai kerana pelaksanaan yang berbeza boleh mengurangkan ketergantungan kepada satu kod sumber. Tetapi ini tidak bermakna setiap ketergantungan adalah bebas.
Dua klien boleh menggunakan masa runtime bahasa pengaturcaraan yang sama. Pemilik operasi yang berbeza juga mungkin menggunakan penyedia hos, perkhidmatan tanda tangan, atau infrastruktur pembinaan blok yang sama.
Komponen-komponen berkongsi ini akan membentuk permukaan serangan yang sama apabila perisian Ethereum berbeza. Oleh itu, untuk memahami situasi pelaksanaan, anda tidak boleh hanya melihat bilangan jenama klien.
Penghantaran luar juga membawa kompromi. Perkhidmatan tanda tangan khas mungkin meningkatkan cara perlindungan kunci, tetapi juga menjadikan sambungan pengesahan dengan perkhidmatan tersebut lebih penting.
Pengendalian tempatan juga memerlukan keperluan penyelenggaraan sendiri. Meletakkan komponen pada mesin yang sama boleh mengurangkan sebahagian paparan rangkaian, tetapi pengendali masih perlu mengurus kemas kini perisian dan akses ke mesin tersebut.
Kejadian ini tidak secara automatik memberikan satu arsitektur yang paling selamat dalam semua situasi. Ia menunjukkan bahawa perlu memahami dan memelihara tanggungjawab di sekitar setiap sambungan.
Perbezaan ini juga penting bagi pengguna ETH biasa. Pembaikan sijil dalam infrastruktur nod tidak bermakna setiap dompet perlu memindahkan dana, atau bahawa balance akaun Ethereum telah berubah.
Tindakan berkaitan adalah tanggungjawab pengendali perisian yang terkesan. Hanya mereka yang mampu mengenal pasti runtime, endpoint, dan tetapan kepercayaan yang terlibat, kemudian menerapkan panduan berkenaan daripada pemasok ke sistem yang sedang membina sambungan tersebut.
Pengendali perlu mengaplikasikan dan memeriksa kemas kini
Penerbitan ini memberikan cara kepada pengendali untuk menghapus laluan kepercayaan yang terjejas daripada imej Docker yang disokong. Pengguna arkib perlu menangani kerja runtime secara berasingan mengikut panduan pembekal Java masing-masing.
Pembaikan tersedia hanyalah langkah pertama. Lingkungan yang dikemas semula masih perlu dijalankan secara sebenar dan memastikan konfigurasi serta perkhidmatan berfungsi seperti yang diharapkan.
Bagi penyedia perkhidmatan, gangguan yang disebabkan oleh sijil yang baru ditolak mungkin memerlukan penukaran sijil pada endpoint. Semasa memulihkan perkhidmatan, pengesahan identiti harus dikekalkan, bukan dielakkan.
Pengungkapan lanjutan mungkin akan memperjelas kesan lebih lanjut. Pengendali mungkin akan mengenal pasti konfigurasi yang menerima rantai sijil yang terkesan, atau melaporkan insiden yang melibatkan perkhidmatan tertentu.
Sekarang ini, laporan notifikasi Teku tidak dimanfaatkan dan membezakan penggunaan jaringan utama lalai dengan sambungan luar yang terjejas. Ini merupakan asas paling jelas untuk menggambarkan permukaan serangan Ethereum semasa ini.
Pengendali yang terkesan mempunyai alasan untuk mengemas kini. Sebarang kerugian kewangan bergantung kepada perkhidmatan mana yang disamar oleh penyerang, sama ada trafik telah dihalang, dan apa yang dibenarkan oleh pengesah terhadap perkhidmatan tersebut.
Apa yang perlu diperhatikan
- Kemas kini klien: Perhatikan pembebasan Teku dan Besu, dan pastikan anda menjalankan versi yang telah diperbaiki.
- Sijil Java: Lihat panduan pemasok untuk runtime Java dan perpustakaan sijil yang digunakan oleh setiap pemasangan.
- Pautan luar: Semak pautan HTTPS yang menunjuk ke perkhidmatan tanda tangan jauh, data, dan pembinaan blok.
- Notis keselamatan: Waspadai pengesahan serangan atau penjelasan lanjut daripada pasukan klien dan pembekal Java.
Soalan Lazim
Apakah peristiwa eMudhra?
Peristiwa ini melibatkan kunci peribadi lemah yang berkaitan dengan sijil perantara eMudhra. Para penyelidik mendapati bahawa kunci-kunci ini boleh dipulihkan daripada maklumat awam, yang mungkin membolehkan pihak lain menghasilkan sijil domain yang tidak mereka kawal. Perisian yang mempercayai laluan sijil yang terjejas mungkin menerima identiti palsu ini. Penyerang masih memerlukan cara tertentu untuk mengintersep atau mengalihkan sambungan, supaya dapat menyamar sebagai perkhidmatan sasaran.
Adakah konsensus Ethereum gagal?
Tidak. Masalah dalam laporan berkaitan dengan bagaimana perisian memeriksa identiti perkhidmatan luar, bukan peraturan konsensus Ethereum di atas blockchain. Kemas kini klien mengubah kepercayaan sijil dalam persekitaran perisian yang terjejas. Beberapa penghuraian validator masih mungkin menghadapi risiko operasi jika perkhidmatan luar disamar. Kemungkinan ini bergantung pada sambungan dan peranan perkhidmatan, dan tidak bermakna peraturan konsensus Ethereum telah dilanggar.
Klien mana yang telah dikemas kini?
Teku 26.10.3 dan Besu 26.10.2 telah mengubah imej Docker mereka untuk menghapus kepercayaan sijil yang terjejas. Teku adalah klien konsensus, sedangkan Besu adalah klien pelaksanaan, kedua-duanya menggunakan Java. Cara pemasangan adalah penting kerana perubahan ini berkuat kuasa pada persekitaran yang disediakan dalam imej-imej ini. Pengendali yang memasang arkib klien dan menyediakan runtime Java sendiri perlu merujuk panduan untuk runtime tersebut secara berasingan.
Will all validators be affected?
Tidak. Pemberitahuan Teku menyatakan bahawa nod rangkaian utama lalai tidak terjejas. Risiko bergantung pada sama ada pelaksanaan tertentu telah menjalankan sambungan HTTPS luaran yang berkaitan, dan sama ada pemeriksaan sijilnya menerima laluan kepercayaan yang terjejas. Pengendali yang berbeza boleh menjalankan klien yang sama di perkhidmatan, versi Java, dan perpustakaan sijil yang berbeza. Oleh itu, nama klien atau jumlah ETH yang di-stake tidak boleh menunjukkan sama ada validator tertentu terjejas.
Can Docker updates cover all installation methods?
Tidak. Imej Docker yang telah dipatch akan memperbaharui persekitaran yang dibungkus di dalam imej tersebut, tetapi pemasangan arkib mungkin menggunakan Java yang disediakan oleh pengendali secara berasingan. Kontainer atau perkhidmatan lain mungkin juga mempunyai runtime sendiri. Pengendali perlu mengenal pasti kaedah pemasangan yang digunakan oleh proses yang sedang berjalan, dan mengikuti arahan pembekalnya. Fail yang telah dipatch di atas pelayan tidak boleh melindungi proses yang masih berjalan di persekitaran lama.
Telahkah penggunaan tersebut dikonfirmasi?
Pada titik masa yang dinyatakan dalam artikel ini, notifikasi Teku tidak melaporkan sebarang penyalahgunaan. Penerangan yang berkaitan menggambarkan satu kelemahan dan kesan potensialnya, bukan bukti bahawa penyerang telah menggunakannya untuk validator. Perbezaan ini penting apabila membincangkan kerugian. Kewujudan satu laluan yang mungkin untuk menyamar sebagai perkhidmatan tidak bermakna tanggungjawab tanda tangan telah dimanipulasi, pembayaran caj telah dipindahkan, atau ETH yang di-stake telah dicuri.
Will validator deposits be automatically exposed?
Tidak. Kunci tanda tangan sijil berbeza daripada kunci tanda tangan validator, dan juga berbeza daripada kredensial yang mengawal penarikan. Pemulihan kunci sijil yang terjejas tidak akan secara automatik mengungkap kunci yang diperlukan untuk menarik ETH yang di-stake. Perkhidmatan yang disamar itu masih mungkin mengganggu tanggungjawab atau mempengaruhi maklumat yang digunakan oleh validator, bergantung kepada cara penghantaran. Risiko yang mungkin berlaku perlu dinilai terhadap perkhidmatan tersebut, bukan dianggap sebagai akses automatik ke seluruh deposit.
Apa yang harus dilakukan oleh pengurus?
Pengendali harus mengikuti notis rilis Teku atau Besu yang berkaitan, serta panduan untuk versi Java mereka. Perlu mengenal pasti runtime dan stor sijil yang digunakan oleh setiap proses yang terjejas, termasuk bahagian yang disediakan dalam kontena. Selepas menerapkan kemas kini yang disarankan, pastikan perkhidmatan yang dikemas kini sedang berjalan dan sambungan yang diperlukan masih berfungsi dengan baik. Menonaktifkan pemeriksaan sijil untuk memulihkan sambungan yang gagal akan menghilangkan perlindungan yang seharusnya disediakan oleh pemeriksaan tersebut.