Bagaimana meyakinkan Administrator saya bahwa Java ON A SERVER tidak aman?

13

Aplikasi

Kami memiliki aplikasi Java kecil yang menggunakan beberapa rute Camel untuk mengambil file yang diunggah dari server web, memprosesnya dan mengirimkan beberapa email dengan hasilnya.

Server tempat aplikasi ini dijalankan telah didekomisi ulang. Untuk saat ini kita harus menjalankannya pada perangkat yang kurang kuat, karena saya tidak dapat meyakinkan admin untuk menginstal JRE di server web (yang sebenarnya merupakan server multi-tujuan).

Ketakutan

Saya sendiri seorang Java Application Engineer, saya menulis kode JEE untuk mencari nafkah, menangani transaksi B2B senilai puluhan ribu € uro per minggu. Tetapi saya memiliki masalah menemukan sumber yang dapat dipercaya yang menyangkal mitos bahwa java tidak aman per se.

Dua argumen utama admin terhadap pemasangan JRE:

Aplikasi Java memakan semua RAM saya
Java penuh dengan kerentanan

Kebenaran?

Ketika datang ke aplikasi java memakan ram. Yah ... Saya akan mengatakan kita harus menetapkan nilai yang tepat untuk Xmx. Selesai

Sekarang ada banyak sumber berbicara tentang banyak kerentanan di Jawa. Sumber-sumber ini sebagian besar ditujukan untuk pengguna akhir yang menjalankan Sistem operasi tertentu dari sebuah perusahaan di Redmond / AS. AFAIK mungkin benar untuk versi Java Browser Plugin yang belum dituntaskan yang dikonfigurasi untuk menjalankan semua applet secara otomatis, bahwa ada peluang yang cukup besar untuk menjadi korban drive oleh infeksi. Seperti halnya ada risiko tertular penyakit menular seksual ketika berhubungan seks tanpa kondom dengan eveyone di kereta Anda saat berangkat kerja.

Tetapi saya tidak dapat menemukan siapa pun di dunia interwebz yang berbicara tentang aplikasi server atau JRE yang berjalan tanpa kepala. Itu semua hal lain.

Atau saya kehilangan sesuatu di sini?

[sunting 2014-08-28] klarifikasi: Saya hanya peduli tentang Java di server. Saya tidak peduli tentang masalah dengan Plugin Java dan / atau perangkat lunak spesifik yang dikembangkan di java.

— kecepatanette
sumber

7

Jika perangkat kerasnya aktif kurang bertenaga dan menyebabkan masalah, maka di samping kekhawatiran SA tentunya Anda memiliki kasus bisnis untuk mendapatkan perangkat keras baru.

— user9517

4

Yakinkan dia bahwa itu bukan kode perusahaan Anda yang baru saja dilihatnya di thedailywtf.com.

— Michael Hampton

9

Java mengalami tahun yang sulit di tahun 2013. Bahkan ada situs web yang melacak eksploitasi 0 hari karena mereka terus diluncurkan. Sejak pertengahan tahun lalu belum ada eksploitasi 0 hari, tetapi para peneliti masih menemukan 107 CVE Jawa tahun ini saja. Itu jauh dari "aman".

— Chris S

5

Bisakah saya memicu bug JVM dengan mengumpankan data berbahaya ke aplikasi Anda? Sebaiknya kau mempercayainya. Dan beberapa CVE tersebut berhubungan dengan menjalankan Java di server, bukan plugin browser desktop Windows biasa.

— Michael Hampton

3

@lajuette Saya memberikan tautan dengan nomor 107 karena suatu alasan - jika Anda mengkliknya semua Pertanyaan yang baru saja Anda tanyakan akan dijawab. Beberapa dari 107 itu terkait dengan implementasi non-Oracle, seperti Dalvak Android, tetapi sebagian besar terkait dengan implementasi Oracle. Java secara inheren tidak aman, tetapi Sun / Oracle JRE penuh dengan masalah. PHP, Perl, Ruby semua memiliki kerentanan juga - tidak ada yang sempurna. Saya tidak bisa mengatakan apakah Jawa lebih baik atau lebih buruk daripada yang ada saat ini, tetapi selama setahun terakhir ini jelas merupakan pencambuk industri keamanan.

— Chris S

18

Permukaan keamanan tambahan yang dimasukkan java ke lingkungan Anda kompleks, dan penting untuk tidak mengabaikannya atau mencoba menyederhanakannya.

Pertama, ada catatan mengerikan yang dimiliki JRE karena memiliki bug keamanan. Sulit untuk menunjukkan yang spesifik, dan ini adalah bagian yang menakutkan - bug sangat rentan tidak ditentukan dengan vektor yang tidak ditentukan.

Ketika saya, sebagai konsultan keamanan, membaca klausa seperti "memungkinkan penyerang jarak jauh" tanpa kualifikasi lebih lanjut tentang maknanya, saya melihat bahwa itu bisa sangat berarti bahwa parameter tertentu yang masuk ke fungsi tertentu dapat memicu kondisi rentan, bahkan jika Anda hanya menjalankan kode yang Anda tulis. Dan, karena tidak ditentukan, Anda tidak tahu apakah Anda terpengaruh.

Lebih baik lagi, JRE kanonik yang diterbitkan oleh Oracle memiliki siklus pembaruan triwulanan untuk pembaruan kritis, termasuk hampir semua pembaruan keamanan. Mereka telah menciptakan patch siklus sebanyak 11 kali dalam empat tahun terakhir. Ini berarti bahwa ada kemungkinan Anda mungkin rentan terhadap bug keamanan hingga tiga bulan setelah dilaporkan sebelum Anda memiliki cara untuk memperbaikinya.

Ada masalah lain dengan java yang tidak akan saya bahas di sini, tapi sungguh, sepertinya ada kekhawatiran yang dapat dibenarkan, terutama untuk server multi-tujuan. Jika Anda harus menjalankan hal-hal seperti itu, Anda setidaknya harus membuat VM tujuan tunggal dan mengisolasinya dari hal-hal lain.

Secara khusus, jika ada remote di JRE yang memungkinkan penyerang mendapatkan RCE, dan satu lagi di PHP yang melakukan hal yang sama, dan yang lain di Ruby yang melakukan hal yang sama lagi, Anda harus menambal ketiganya. Ketiganya tampaknya agak mungkin, karena hal-hal ini berjalan, dan penyerang harus memilih mana yang paling nyaman dan kemudian memiliki seluruh server. Itu sebabnya kita harus menggunakan VM untuk memisahkan perangkat lunak, terutama perangkat lunak seperti kerangka kerja bahasa yang dikelola, dan terutama yang menggabungkan patch keamanan hanya empat kali setahun dan merupakan hak milik vendor yang menegaskan dalam menghadapi semua bukti bahwa mereka adalah teladan dari keamanan.

Untuk memperbarui, berikut adalah beberapa CVE yang saya pilih dari pencarian CVE terkait ChrisS, dengan cara demonstrasi.

Dan favorit saya, sejak saya di sana:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1488

Ngomong-ngomong, itu hanya contoh kecil.

— Falcon Momot
sumber

6

Aplikasi Java memakan semua RAM saya

Alternatif untuk menggunakan RAM adalah membuang-buang RAM. Anda tidak dapat menyimpannya untuk nanti.

Java penuh dengan kerentanan

Itu tidak terlalu penting karena Anda tidak akan mengekspos JVM ke dunia. Saya kira Anda tidak akan menjalankan program yang bermusuhan, dan jika Anda melakukannya, Java lebih aman daripada kebanyakan bahasa lainnya. Yang penting adalah apakah aplikasi Anda memiliki kerentanan.

— David Schwartz
sumber

3

Oke, jadi alasan tidak berfungsi. Alat apa lagi yang ada di kotak alat persuasi Anda? Apakah Anda memiliki tang berkarat?

— David Schwartz

1

@ FalconMomot Ya, kernel dapat menggunakannya untuk men-cache file. Kernel dapat mengambil memori dari JVM jika penggunaannya lebih baik. Begitulah cara kerja setiap OS modern. Alternatif untuk menggunakan RAM adalah membuang-buang RAM. OS memiliki manajer memori khusus untuk memastikan RAM mencapai tujuan terbaik. Argumen seperti "Aplikasi Java menghabiskan semua RAM saya" hampir selalu menunjukkan admin yang tidak mengerti bagaimana sistem operasi modern menggunakan RAM.

— David Schwartz

1

Jika JVM tidak membebaskan memori, ia harus menukar ke ruang swap (jika ada) untuk melakukan ini, yang lambat. Kernel tidak dapat memanggil pengumpul sampah. Juga, file caching biasanya prioritas lebih rendah daripada alokasi userspace bahkan jika mereka jarang digunakan (sebanyak kernel dapat mengatakan bahwa mereka jarang digunakan, yang tidak terlalu baik).

— Falcon Momot

3

Saya ingin tahu lebih banyak tentang bagaimana Linux dapat secara bersamaan menggunakan blok RAM untuk cache sementara proses masih berpikir itu adalah miliknya. Saya belum pernah mendengar ini sebelumnya.

— Michael Hampton

1

@ FalconMomot Kernel tidak perlu tahu bahwa RAM itu "bebas". Kernel selalu memiliki kendali atas penggunaan RAM kecuali aplikasi mengunci halaman. Itu hanya harus membuat halaman yang dipetakan dibuang untuk mendapatkan RAM kembali. Jika data tidak dimodifikasi dan tidak digunakan untuk jangka waktu tertentu, dan bandwidth I / O tidak jenuh, ia dapat secara oportunis menuliskannya untuk ditukar, membuat halaman dapat dibuang, memungkinkannya untuk mendapatkan kembali RAM segera setelah penggunaannya lebih baik untuk itu. (Ruang ini tidak cukup besar untuk menjelaskan cara kerja manajemen memori modern, tetapi sepertinya Anda memiliki beberapa kesalahpahaman yang sangat umum.)

— David Schwartz

2

Pekerjakan perusahaan untuk melakukan analisis statis pada program Anda. Veracode, misalnya, adalah perusahaan yang saya gunakan di masa lalu untuk mengaudit keamanan kode program Java, khususnya.

Tagihkan kode biaya tim admin Anda, tentu saja.

— mfinni
sumber

1

Jelaskan bahwa semua bahasa lain (atau mesin virtual) dapat dibuat tidak aman oleh kode yang digunakan untuk mereka, seperti halnya dengan Java. Jika menurutnya platform lain secara inheren aman (atau lebih aman daripada Java) tanpa menangani keamanan dengan benar, maka ia adalah delusi.

Perusahaan Anda jelas berinvestasi untuk mempekerjakan pengembang Java, mengapa sysadmin menolak untuk mendukung teknologi yang perusahaan memutuskan untuk gunakan?

Saya akan membalik pertanyaan dan bertanya kepadanya apa alternatif yang ia usulkan dan bagaimana mereka lebih aman daripada Server JRE terbaru yang tersedia, dalam istilah yang sangat spesifik. Sementara itu, berusahalah untuk menunjukkan Anda memahami teknologi Anda, permukaan serangan yang mungkin dan bahwa Anda telah bekerja untuk menguranginya (mis. Kerangka kerja yang tidak perlu, kode pihak ketiga, dll). Sudahkah kode Anda diverifikasi, cari kerentanan yang dipublikasikan untuk kerangka kerja yang Anda andalkan dalam X tahun terakhir, bandingkan dengan bahasa / kerangka kerja lain (pastikan untuk menyertakan pangsa pasar juga, kerangka kerja yang tidak jelas tanpa kerentanan yang dipublikasikan tidak berarti apa-apa).

Kami tidak mungkin tahu bagaimana keseluruhan konversi antara kalian berdua terjadi tetapi jika itu adalah dua argumennya, saya yakin Anda berurusan dengan administrator sistem junior. Apakah dia memiliki pengalaman dengan server aplikasi Java? Mungkin dia tidak nyaman dengan teknologi dan takut untuk memasukkan sesuatu ke dalam produksi tanpa benar-benar memahaminya (sikap sysadmin yang baik kemudian).

— Giovanni Tirloni
sumber

Terima kasih. Kami tidak berbicara tentang perusahaan. Bukan asosiasi nirlaba. Out sysadmin memiliki seorang dokter di bidang IT & pemasaran, tetapi bukan sysadmin yang "nyata". Dan ya: saya percaya dia takut pada Jawa, yang dia tidak mengerti sepenuhnya.

— lajuette