it-swarm-id.com

Apakah perangkat lunak bebas exploit mungkin?

Saya telah mendengar bahwa selalu ada kerentanan dalam kode, perangkat lunak. Namun, saya tidak mengerti mengapa tidak mungkin memiliki perangkat lunak bebas-eksploitasi. Jika perusahaan terus memperbarui perangkat lunak mereka, pada akhirnya tidak akan ada kerentanan, bukan?

139
Zheer

Perangkat lunak terlalu rumit

Sejauh ini, inilah faktor yang paling penting. Bahkan jika Anda hanya melihat sesuatu seperti aplikasi web, jumlah jam kerja yang dimasukkan ke dalam basis kode sangat besar. Kode ini bekerja dengan teknologi, yang standarnya adalah halaman lebih dari halaman, ditulis beberapa dekade yang lalu, dan yang menawarkan fitur yang belum pernah didengar sebagian besar pengembang.

Kombinasikan itu dengan fakta bahwa perangkat lunak modern dibangun di atas perpustakaan, yang dibangun di atas perpustakaan, yang memisahkan beberapa perpustakaan tingkat rendah berdasarkan pada beberapa fungsi OS, yang lagi-lagi hanyalah pembungkus untuk beberapa fungsi OS lain yang ditulis pada 1990-an.

Tumpukan teknologi modern terlalu besar untuk satu orang untuk sepenuhnya grok, bahkan jika Anda mengecualikan sisi OS hal-hal, yang mengarah ke titik berikutnya:

Pengetahuan hilang dari waktu ke waktu

Suntikan SQL sekarang berusia 20 tahun. Mereka masih ada. Bagaimana bisa? Salah satu faktor yang perlu dipertimbangkan adalah bahwa pengetahuan di dalam perusahaan hilang seiring waktu. Anda mungkin memiliki satu atau dua pengembang senior, yang tahu dan peduli tentang keamanan, yang memastikan bahwa kode mereka tidak rentan terhadap suntikan SQL, tetapi para senior itu pada akhirnya akan mengambil posisi yang berbeda, berganti perusahaan atau pensiun. Orang-orang baru akan menggantikan mereka, dan mereka mungkin juga sebagai pengembang yang baik, tetapi mereka tidak tahu atau peduli dengan keamanan. Akibatnya, mereka mungkin tidak tahu atau peduli tentang masalahnya, dan karenanya tidak mencari mereka.

Orang diajarkan dengan cara yang salah

Poin lain adalah bahwa keamanan bukanlah sesuatu yang dipedulikan sekolah. Saya ingat pelajaran pertama tentang menggunakan SQL di Jawa, dan guru saya menggunakan rangkaian string untuk menyisipkan parameter ke dalam kueri. Saya mengatakan kepadanya bahwa itu tidak aman, dan dimarahi karena mengganggu pelajaran. Semua siswa di kelas ini telah melihat bahwa rangkaian senar adalah cara yang harus dilakukan - setelah semua, itulah cara guru melakukannya, dan guru tidak akan pernah mengajarkan sesuatu yang salah, bukan?

Semua siswa sekarang akan masuk ke dunia pengembangan dan dengan senang hati menulis kode SQL yang mudah disuntikkan, hanya karena tidak ada yang peduli. Mengapa tidak ada yang peduli? Karena

Perusahaan tidak tertarik dengan "kode sempurna"

Itu pernyataan yang berani, tapi itu benar. Bagi perusahaan, mereka peduli dengan investasi dan pengembalian. Mereka "menginvestasikan" waktu pengembang mereka (yang biaya perusahaan sejumlah uang tertentu), dan mereka mengharapkan fitur sebagai imbalan, yang mereka dapat jual kepada pelanggan. Fitur yang dijual termasuk:

  • Perangkat lunak sekarang dapat bekerja dengan lebih banyak format file
  • Perangkat lunak sekarang termasuk pembelian dalam aplikasi
  • Perangkat lunak terlihat lebih baik
  • Perangkat lunak membuat Anda terlihat lebih baik
  • Perangkat lunak bekerja lebih cepat
  • Perangkat lunak diintegrasikan dengan mulus ke alur kerja Anda

Apa yang perusahaan tidak bisa jual kepada Anda adalah tidak adanya bug. "Perangkat lunak tidak rentan terhadap XSS" bukanlah sesuatu yang dapat Anda jual, dan karenanya bukan sesuatu yang ingin diinvestasikan perusahaan. Memperbaiki masalah keamanan sama seperti mencuci pakaian Anda - tidak ada yang membayar Anda untuk melakukannya, tidak ada yang memuji Anda untuk melakukannya, dan Anda mungkin tidak merasa ingin melakukannya, tetapi Anda masih harus melakukannya.

Dan satu lagi poin terakhir:

Anda tidak dapat menguji tidak adanya bug

Artinya, Anda tidak pernah dapat memastikan apakah kode Anda mengandung bug. Anda tidak dapat membuktikan bahwa beberapa perangkat lunak aman, karena Anda tidak dapat melihat berapa banyak bug yang tersisa. Biarkan saya menunjukkan ini:

function Compare(string a, string b)
{
    if (a.Length != b.Length)
    {
        // If the length is not equal, we know the strings will not be equal
        return -1;
    }
    else
    {
        for(int i = 0; i < a.Length; i++)
        {
            if(a[i] != b[i])
            {
                // If one character mismatches, the string is not equal
                return -1;
            }
        }

        // Since no characters mismatched, the strings are equal
        return 0;
    }
}

Apakah kode ini terlihat aman bagi Anda? Anda mungkin berpikir begitu. Ia mengembalikan 0 jika string sama dan -1 jika tidak. Jadi apa masalahnya? Masalahnya adalah bahwa jika rahasia konstan digunakan untuk satu bagian, dan input yang dikontrol penyerang untuk bagian lainnya, maka penyerang dapat mengukur waktu yang dibutuhkan untuk menyelesaikan fungsi. Jika 3 karakter pertama cocok, itu akan memakan waktu lebih lama daripada jika tidak ada karakter yang cocok.

Ini berarti bahwa seorang penyerang dapat mencoba berbagai input dan mengukur berapa lama waktu yang dibutuhkan untuk menyelesaikannya. Semakin lama, semakin banyak karakter yang berurutan identik. Dengan waktu yang cukup, penyerang pada akhirnya bisa mengetahui apa string rahasianya. Ini disebut serangan sisi-saluran .

Bisakah bug ini diperbaiki? Ya tentu saja. Bug apa pun dapat diperbaiki. Tetapi inti dari demonstrasi ini adalah untuk menunjukkan bahwa bug tidak harus terlihat jelas, dan memperbaikinya mengharuskan Anda menyadarinya, tahu cara memperbaikinya, dan memiliki insentif untuk melakukannya.

Singkatnya...

Saya tahu ini adalah posting yang panjang, jadi saya tidak menyalahkan Anda karena melewatkan sampai akhir. Versi cepatnya adalah, menulis kode bebas-eksploitasi benar-benar sangat sulit, dan menjadi semakin sulit secara eksponensial semakin rumit perangkat lunak Anda. Setiap teknologi yang digunakan oleh perangkat lunak Anda, baik itu web, XML, atau lainnya, memberikan ribuan basis kode eksploitasi tambahan pada basis kode Anda. Selain itu, majikan Anda mungkin bahkan tidak peduli untuk menghasilkan kode bebas eksploitasi - mereka peduli dengan fitur yang dapat mereka jual. Dan akhirnya, dapatkah Anda benar-benar yakin itu mengeksploitasi gratis? Atau Anda hanya menunggu eksploitasi besar berikutnya untuk memukul publik?

266
MechMK1

Jawaban yang ada, pada saat penulisan ini, berfokus pada kesulitan membuat kode bebas bug, dan mengapa itu tidak mungkin.

Tapi bayangkan kalau itu mungkin. Betapa rumitnya itu. Ada satu perangkat lunak di luar sana yang mendapat gelar "bebas bug:" L4 microkernel. Kita bisa menggunakannya untuk melihat seberapa jauh jarak lubang kelinci.

seL4 adalah microkernel. Ini unik karena, pada 2009, terbukti tidak memiliki bug. Yang dimaksud oleh itu adalah bahwa mereka menggunakan sistem bukti otomatis untuk membuktikan secara matematis bahwa jika kode tersebut dikompilasi oleh kompiler yang memenuhi standar, biner yang dihasilkan akan melakukan apa yang akan dilakukan oleh dokumentasi bahasa. Ini diperkuat kemudian untuk membuat pernyataan serupa dari biner ARM dari microkernel:

Kode biner dari versi ARM dari seL4 microkernel mengimplementasikan dengan benar perilaku yang dijelaskan dalam spesifikasi abstraknya dan tidak lebih. Selanjutnya, spesifikasi dan biner seL4 memenuhi sifat keamanan klasik yang disebut integritas dan kerahasiaan. .

Luar biasa! Kami memiliki perangkat lunak yang tidak sepele yaitu terbukti benar. Apa berikutnya?

Nah, orang seL4 tidak membohongi kita. Mereka kemudian dengan segera menunjukkan bahwa bukti ini memiliki batas, dan menyebutkan beberapa dari batasan itu

Majelis: kernel seL4, seperti semua kernel sistem operasi, berisi beberapa kode Majelis, sekitar 340 baris ARM Majelis dalam kasus kami. Untuk seL4, ini terutama menyangkut masuk dan keluar dari kernel, serta akses perangkat keras langsung. Sebagai buktinya, kami menganggap kode ini benar.
Perangkat Keras: kami menganggap perangkat keras berfungsi dengan benar. Dalam praktiknya, ini berarti perangkat keras diasumsikan tidak dirusak, dan berfungsi sesuai spesifikasi. Ini juga berarti, harus dijalankan dalam kondisi operasinya.
Manajemen perangkat keras: buktinya hanya membuat asumsi paling minimal pada perangkat keras yang mendasarinya. Ini abstrak dari konsistensi cache, pewarnaan cache dan manajemen TLB (terjemahan lookaside buffer). Buktinya mengasumsikan fungsi-fungsi ini diterapkan dengan benar di lapisan Majelis yang disebutkan di atas dan bahwa perangkat keras berfungsi seperti yang diiklankan. Buktinya juga mengasumsikan bahwa terutama ketiga fungsi manajemen perangkat keras ini tidak memiliki efek pada perilaku kernel. Ini benar jika mereka digunakan dengan benar.
Kode boot: buktinya saat ini adalah tentang operasi kernel setelah telah dimuat dengan benar ke dalam memori dan dibawa ke dalam yang konsisten, keadaan awal minimal. Ini menyisakan sekitar 1.200 baris basis kode yang biasanya dianggap oleh programmer programmer sebagai bagian dari kernel.
Memori virtual: di bawah standar proyek verifikasi formal 'normal', memori virtual tidak perlu dianggap sebagai asumsi dari bukti ini . Namun, tingkat jaminan lebih rendah daripada bagian lain dari bukti kami di mana kami beralasan dari prinsip pertama. Secara lebih rinci, memori virtual adalah mekanisme perangkat keras yang digunakan kernel untuk melindungi dirinya dari program pengguna dan program pengguna dari satu sama lain. Bagian ini sepenuhnya diverifikasi. Namun, kehabisan memori virtual menimbulkan komplikasi, karena itu dapat mempengaruhi bagaimana kernel itu sendiri mengakses memori. Model eksekusi kami mengasumsikan perilaku standar memori tertentu ketika kernel dijalankan, dan kami membenarkan asumsi ini dengan membuktikan kondisi yang diperlukan pada perilaku kernel. Masalahnya adalah: Anda harus memercayai kami bahwa kami mendapatkan semua persyaratan yang diperlukan dan kami melakukannya dengan benar. Bukti yang diperiksa dengan mesin kami tidak memaksa kami untuk menyelesaikan pada saat ini. Singkatnya, di bagian pembuktian ini, tidak seperti bagian lain, ada potensi kesalahan manusia.
...

Daftar berlanjut. Semua peringatan ini harus diperhitungkan dengan cermat ketika mengklaim bukti kebenaran.

Sekarang kita harus memberikan penghargaan tim seL4. Bukti seperti itu adalah pernyataan membangun kepercayaan diri yang luar biasa. Tapi itu menunjukkan ke mana perginya lubang kelinci ketika Anda mulai mendekati ide "bebas bug." Anda tidak pernah benar-benar mendapatkan "bug gratis." Anda baru saja mulai serius mempertimbangkan kelas bug yang lebih besar.

Akhirnya Anda akan mengalami masalah yang paling menarik dan manusiawi: apakah Anda menggunakan perangkat lunak yang tepat untuk pekerjaan itu? seL4 menawarkan beberapa jaminan besar. Apakah mereka yang sebenarnya Anda butuhkan? Jawaban MechMK1 menunjukkan serangan waktu pada beberapa kode. Bukti seL4 secara eksplisit tidak termasuk pertahanan terhadap mereka. Jika Anda khawatir tentang serangan waktu seperti itu, seL4 tidak menjamin apa pun tentang mereka. Anda menggunakan alat yang salah.

Dan, jika Anda melihat sejarah eksploitasi, penuh dengan tim yang menggunakan alat yang salah dan terbakar karenanya.

†. Menanggapi komentar: Jawabannya sebenarnya berbicara untuk mengeksploitasi kode gratis. Namun, saya berpendapat bukti bahwa kode bebas bug diperlukan untuk bukti bahwa itu bebas mengeksploitasi.

92
Cort Ammon

Anda dapat memiliki kode berkualitas tinggi, tetapi menjadi jauh lebih mahal untuk mengembangkannya. Perangkat lunak Space Shuttle adalah dikembangkan , dengan sangat hati-hati dan pengujian yang ketat, menghasilkan perangkat lunak yang sangat andal - tetapi jauh lebih mahal daripada skrip PHP.

Beberapa hal sehari-hari juga memiliki kode yang sangat baik. Sebagai contoh, Linux TCP/IP stack cukup solid dan memiliki beberapa masalah keamanan (walaupun sayangnya, satu baru-baru ini ) Perangkat lunak lain yang berisiko tinggi serangan termasuk OpenSSH, Remote Desktop, VPN titik akhir. Para pengembang biasanya menyadari pentingnya perangkat lunak mereka karena sering memberikan "batas keamanan" terutama dengan serangan pra-otentikasi, dan secara umum mereka melakukan lebih baik dan memiliki sedikit masalah keamanan.

Sayangnya, beberapa perangkat lunak utama tidak begitu berkembang dengan baik. Contoh penting adalah OpenSSL yang sangat banyak digunakan, namun memiliki internal yang berantakan di mana mudah untuk memperkenalkan kelemahan keamanan seperti Heart Bleed. Langkah-langkah telah diambil untuk mengatasi hal ini, mis. LibreSSL.

Efek serupa terjadi pada perangkat lunak CMS. Misalnya, inti Word Press umumnya dirancang dengan baik dan memiliki beberapa masalah. Tetapi plugin jauh lebih bervariasi, dan sering kali plugin yang sudah usang adalah bagaimana situs tersebut diretas.

Browser web adalah garis depan dalam hal ini. Miliaran pengguna desktop mengandalkan browser web mereka untuk aman, menjauhkan malware dari sistem mereka. Tetapi mereka juga harus cepat, mendukung semua fitur terbaru, dan masih menangani jutaan situs warisan. Jadi sementara kita semua benar-benar ingin browser web menjadi batas keamanan yang dapat dipercaya, mereka tidak seperti itu saat ini.

Ketika datang ke perangkat lunak dipesan lebih dahulu - yang sering aplikasi web - pengembang bekerja pada mereka biasanya kurang berpengalaman dan keamanan menyadari daripada pengembang infrastruktur inti. Dan rentang waktu komersial mencegah mereka mengambil pendekatan yang sangat rinci dan hati-hati. Tetapi ini dapat dibantu dengan arsitektur yang mengandung kode kritis keamanan di area kecil, yang secara hati-hati dikodekan dan diuji. Kode non-keamanan-kritis dapat dikembangkan lebih cepat.

Semua pengembangan dapat dibantu dengan alat keamanan dan pengujian, termasuk analisa statis, fuzzer dan tes pena. Beberapa dapat tertanam dalam pipa CI otomatis, dan departemen keamanan yang lebih matang sudah melakukannya.

Jadi kita masih harus menempuh jalan panjang, dengan harapan di masa depan akan ada lebih sedikit bug keamanan. Dan banyak peluang untuk teknologi inovatif yang membawa kita ke sana.

24
paj28

Iya...

Seperti yang telah ditunjukkan orang lain, mungkin untuk membuktikan kode Anda, dan dengan cara itu menunjukkan bahwa kode Anda akan berfungsi persis seperti yang dimaksudkan. Kesulitan dengan waktu pembuktian dan model non-deterministik (seperti interaksi jaringan) adalah salah satu kesulitan, bukan ketidakmungkinan. Patch ke Meltdown dan Specter menunjukkan bahwa serangan timing-channel bahkan dapat dipertanggungjawabkan dan diatasi.

Pendekatan utama untuk membangun kode seperti ini adalah memperlakukan kode sebagai matematika. Jika Anda tidak dapat membuktikan kode Anda, jangan memperlakukannya sebagai bebas bug. Jika Anda bisa, maka Anda hanya memiliki ... kesempatan bebas bug.

... tapi ...

Bahkan jika Anda dapat membuktikan bahwa kode Anda asli, tidak dapat merilis data kecuali seperti yang dimaksudkan, tidak dapat dimasukkan ke dalam kondisi yang salah atau menyimpang, dll, ingatlah bahwa kode itu sendiri tidak berharga. Jika pengembang menulis kode yang memiliki bukti seperti itu, tetapi menjalankan kode itu pada perangkat keras yang sendiri mengandung kerentanan perangkat keras, keamanan perangkat lunak menjadi diperdebatkan.

Pertimbangkan fungsi sederhana untuk mengambil beberapa data terenkripsi dari memori, menyimpannya dalam register CPU, melakukan transformasi yang sesuai pada register tersebut untuk mendekripsi, memproses, dan mengenkripsi ulang data. Perhatikan bahwa pada titik tertentu, data yang tidak dienkripsi ada dalam register. Jika opcodes yang tersedia untuk perangkat keras CPU tersebut membeli kemungkinan program yang tidak melanggar register CPU, berjalan paralel dengan kode Anda yang telah terbukti, maka ada serangan berbasis perangkat keras.

Apa artinya ini, pada akhirnya, bahwa untuk memiliki perangkat lunak bebas eksploitasi, Anda perlu membuktikan terlebih dahulu bahwa Anda memiliki perangkat keras bebas-eksploitasi. Seperti Meltdown dan Specter (di antara banyak lainnya) telah menunjukkan, perangkat keras yang tersedia secara umum tidak melewati tanda itu.

Bahkan perangkat keras spek militer dan spek ruang gagal pada metrik ini. Lini prosesor LEON , yang digunakan dalam penyebaran militer dan luar angkasa, hanya diperkeras terhadap Gangguan Acara Tunggal (SEU) dan Transien Peristiwa Tunggal (SET) . Ini bagus, tetapi itu berarti selalu ada kemungkinan penyerang menempatkan sistem di lingkungan dengan radiasi yang cukup untuk menginduksi gangguan dan transien yang cukup untuk menempatkan perangkat keras dalam keadaan menyimpang.

... dan lebih banyak tetapi ...

Jadi membuktikan perangkat lunak dan perangkat keras tidak cukup. Kita harus mempertimbangkan bahkan dampak lingkungan dalam memeriksa perangkat keras kita. Jika kita mengekspos LEON4 ke radiasi yang cukup untuk membanjiri casing OR menyebabkan radiasi yang cukup di dalam casing untuk membanjiri prosesor, kita masih dapat menyebabkan aberasi. Pada titik ini, jumlah total sistem ( perangkat lunak, perangkat keras, lingkungan) akan sangat rumit untuk mendefinisikan sepenuhnya dan benar untuk mencoba bukti tersebut.

... jadi tidak, tidak juga ...

Anggaplah kita telah membuat RDBMS bahwa kita telah membuktikan kode, kita telah membuktikan perangkat keras, dan kita telah membuktikan lingkungan. Pada titik tertentu, kami akhirnya mencapai titik lemah dalam rantai keamanan apa pun:

Idi ... eh, Pengguna.

Basis data kami yang mulia dan terkenal kami PFY membuat sistem yang tidak aman. PFY - mari kita menjadi lebih dermawan dan memberi mereka gelar 'JrOp' ... JrOp mengakses database dan hanya diberikan data yang perlu diketahui oleh JrOp dan tidak lebih, tidak kurang. Dalam momen cemerlang hanya JrOps yang bisa dikerahkan, JrOp kami condong ke rekan kerja dan bergumam, "Apakah Anda melihat apa yang User12358W baru unggah? Lihat ini!"

Begitu banyak untuk keamanan kita ...

... satu harapan terakhir (dan mengalahkannya dengan absurditas) ...

Mari kita katakan, bagaimanapun, kita membayangkan masa depan hipotetis di mana kita akhirnya menemukan kesadaran manusia . Kemanusiaan akhirnya mencapai akuntansi ilmiah dan teknologi dari semua fungsi mental manusia. Lebih jauh katakan ini memungkinkan kami untuk membuktikan sistem kami terhadap bahkan pengguna kami - sistem umpan balik yang sesuai dibangun ke dalam sistem untuk memastikan JrOp kami bahkan tidak BERPIKIR mengungkapkan apa yang diungkapkan kepada JrOp. Kita dapat meninggalkan pertanyaan tentang meta-Etika dan manipulasi kepada para filsuf - berbicara tentang para filsuf ...

Perhatikan bahwa pada setiap langkah, kami telah menggunakan bukti.

"Ah-hah," seru skeptis Pyrrhonic dengan gembira. "Anda berasumsi bahwa beberapa sistem formal, seperti ZF/ZFC, Peano, teori Set non-naif, logika proposisional klasik, masuk akal. Mengapa?"

Apa jawaban yang bisa diberikan? Antara Godel dan Tarski, kita bahkan tidak dapat secara formal mendefinisikan kebenaran (lihat Teorum Ketidaklengkapan Godel dan Teorum Undefinability Tarski ), jadi bahkan pernyataan, "baiklah, kita mengambilnya karena tampaknya bagus untuk menggunakan suatu sistem yang sejalan dengan kenyataan, "pada intinya hanyalah asumsi yang tidak berdasar - yang berarti bukti apa pun yang tidak dieksploitasi oleh sistem kami pada akhirnya adalah asumsi itu sendiri.

... jadi tidak, tidak.

Meskipun dimungkinkan untuk menulis kode bebas bug, dengan menuliskannya sebagai bukti matematis, dan dengan demikian secara teknis mencapai tujuan tingkat atas dari 'kode bebas-eksploitasi', ini memerlukan melihat kode dalam ruang hampa. Ada beberapa nilai dalam hal ini - ini adalah tujuan yang berharga ("Tapi itu mengasumsikan wor--" "Kebanyakan orang melakukannya, atasi dengan itu Pyrrho"). Namun, jangan pernah membiarkan diri Anda merasa nyaman berpikir bahwa Anda pernah berhasil pada tujuan itu - dan jika Anda melakukannya, miliki kerendahan hati untuk memberi judul kode Anda "HMS Titanic".

11
LRWerewolf

Saya ingin menjawab pertanyaan-pertanyaan sebelumnya. Saya tidak percaya bahwa perangkat lunak bebas bug secara teori tidak mungkin atau perangkat lunak itu terlalu kompleks. Kami memiliki sistem kompleks lainnya dengan tingkat kesalahan jauh lebih rendah.

Ada dua alasan mengapa kode bebas-eksploitasi tidak akan terjadi dalam waktu dekat:

Kinerja dan Optimalisasi lainnya

Banyak masalah, termasuk yang dapat dieksploitasi, bukan kasus di mana kita tidak tahu bagaimana menulis kode dengan benar, hanya saja kode yang benar akan lebih lambat. Atau gunakan lebih banyak memori. Atau lebih mahal untuk menulis. Banyak jalan pintas diambil dalam perangkat lunak untuk mempercepat kecepatan atau untuk beberapa keuntungan lainnya. Beberapa jalan pintas ini adalah sumber dari eksploitasi

Masalah mendasar

Sistem yang kami gunakan untuk membuat perangkat lunak saat ini memiliki kelemahan mendasar yang mengarah pada eksploitasi, tetapi pada prinsipnya tidak dapat dihindari. Kompiler kami tidak terbukti aman. Sistem perpustakaan, terutama ekosistem Node (sekarang disalin oleh komposer, kargo, dan lainnya) yang secara dinamis mengintegrasikan ratusan atau ribuan paket kecil melalui dependensi otomatis adalah --- besar keamanan mimpi buruk. Saya harus menggunakan font 72pt untuk menunjukkan seberapa besar. Hampir semua bahasa kami mengandung konstruksi yang tidak aman secara mendasar (behing berpikir Rust menggambarkan beberapa di antaranya). Sistem operasi kami dibangun pada sistem yang lebih lama bahkan dengan lebih banyak kekurangan.

Singkatnya: Pada saat ini, yang terbaik yang dapat kita lakukan pada dasarnya adalah "cobalah untuk tidak mengacaukan" dan itu tidak cukup untuk sistem yang kompleks.

Kesimpulan

Jadi ringkasnya, dengan dunia perangkat lunak seperti sekarang ini, tidak. Kode bebas-eksploitasi tidak mungkin dengan alat-alat dan pola pikir dan lingkungan dev kecuali kita berbicara tentang kode sepele atau sangat mandiri (kernel L4 yang telah disebutkan).

Secara teoritis, bagaimanapun, tidak ada yang menghentikan kita dari membangun perangkat lunak dari modul-modul kecil, yang masing-masing dapat secara resmi terbukti benar. Tidak ada yang menghentikan kita untuk memodelkan hubungan, interaksi, dan antarmuka model-model itu dan secara formal membuktikan kebenarannya.

Sebenarnya, kita bisa melakukannya hari ini, tetapi tanpa kemajuan mendasar dalam desain perangkat lunak, kode itu akan merangkak, tidak berjalan.

8
Tom

Apa itu mungkin? Iya. Tetapi tidak untuk perangkat lunak yang Anda cari.

"Bug/Exploit Free" pada dasarnya berarti bahwa suatu program akan memiliki respons yang masuk akal dan aman terhadap input apa pun. Ini bisa termasuk mengabaikan input itu.

Satu-satunya perangkat lunak di mana ini dapat dicapai adalah program kecil, sepele tepat di luar Hello World. Tidak ada eksploitasi dalam hal ini:

print("Hello World")

Karena kode ini mengabaikan semua input, dan hanya menghasilkan string hardcoded.

Namun, kode ini juga menyelesaikan 0 pekerjaan yang bermanfaat untuk Anda.

Segera setelah Anda ingin, misalnya, terhubung ke internet dan mengunduh sesuatu, Anda akan mengunduh data yang tidak dapat Anda kendalikan dan mungkin berbahaya. Tentu saja, ada banyak batasan yang kami unduh dari perangkat lunak pengunduhan terhadap data tersebut untuk membela Anda, tetapi tidak mungkin untuk mempertahankannya dari sudut ancaman yang tidak Anda sadari.

7
Gloweye

Ya, jika keamanan sistem terbukti secara matematis. Ini bukan ide baru, Kriteria Evaluasi Sistem Komputer Tepercaya , singkatnya "Buku Jeruk" berasal dari tahun 1985.

enter image description here

Di dalamnya, tingkat keamanan tertinggi, bernama A1, adalah ketika kami memiliki desain yang diverifikasi . Ini berarti bahwa secara matematis terbukti bahwa tidak ada cara untuk merusak sistem.

Dalam praktiknya, membuktikan kebenaran matematis (termasuk keamanan) dari setiap perangkat lunak sangat sulit, dan merupakan pekerjaan yang sangat menarik. Sejauh yang saya tahu, tidak ada sistem komputer lengkap yang memiliki bukti seperti itu, tetapi beberapa sistem (setidaknya VM/ESA kernel) sebagian terbukti.

Perhatikan juga, IT Security secara inheren menangani kemungkinan serangan yang tidak kita ketahui, dari mana mereka berasal. Misalnya, model matematika seperti itu akan baik-baik saja dan berfungsi untuk sistem yang - secara langsung atau tidak langsung - mengasumsikan bahwa tidak ada cara untuk menguping komunikasi internal TCP. Dengan demikian, akan memenuhi syarat untuk dapatkan sertifikat A1. Saat dalam praktik, sistem seperti itu dapat dengan mudah diputus pada router yang dikompromikan.

Secara umum, pengujian kebenaran program secara otomatis (atau sebagian terotomatisasi), termasuk. pengujian keamanan mereka, adalah bidang ilmu komputer yang berjalan sejak beberapa dekade lalu. Itu menghasilkan banyak publikasi dan gelar Phd. Tetapi masih jauh dari penggunaan praktis yang luas, seperti 25 tahun yang lalu.

Iya

Saya terkejut tidak ada yang menyebutkan verifikasi formal dengan namanya (meskipun jawaban Cort menyebutkan mikrokernel L4, yang telah diverifikasi secara resmi).

Secara pribadi saya tidak terlalu mengenal verifikasi formal, jadi saya akan menunjuk ke beberapa bit yang relevan dari halaman Wikipedia tentang topik tersebut; silakan merujuknya untuk informasi lebih lanjut.

Dalam konteks sistem perangkat keras dan perangkat lunak, verifikasi formal adalah tindakan membuktikan atau menyangkal kebenaran dari algoritma yang dimaksud yang mendasari sistem sehubungan dengan spesifikasi atau properti formal tertentu, menggunakan metode matematika formal. [1]

Verifikasi formal program perangkat lunak melibatkan pembuktian bahwa suatu program memenuhi spesifikasi formal perilakunya. [...]

Pertumbuhan dalam kompleksitas desain meningkatkan pentingnya teknik verifikasi formal dalam industri perangkat keras. [6] [7] Saat ini, verifikasi formal digunakan oleh sebagian besar atau semua perusahaan perangkat keras terkemuka , [8] tetapi penggunaannya dalam industri perangkat lunak masih merana.[rujukan?] Ini dapat dikaitkan dengan kebutuhan yang lebih besar di industri perangkat keras, di mana kesalahan memiliki signifikansi komersial yang lebih besar.[rujukan?] [...]

Pada 2011 , beberapa sistem operasi telah diverifikasi secara formal: mikrokernel L4 Secure Embedded NICTA, dijual secara komersial sebagai seL4 oleh OK Labs; [10] OSEK/VDX berbasis sistem operasi real-time ORIENTAIS oleh East China Normal University;[rujukan?] Sistem operasi Integritas Green Hills Software;[rujukan?] dan PikeOS SYSGO. [11] [12]

Pada 2016, profesor Yale dan Columbia, Zhong Shao dan Ronghui Gu mengembangkan protokol verifikasi formal untuk blockchain yang disebut CertiKOS. [13] Program ini adalah contoh pertama verifikasi formal di dunia blockchain, dan contoh verifikasi formal yang digunakan secara eksplisit sebagai program keamanan. [14]

Pada 2017, verifikasi formal telah diterapkan pada desain jaringan komputer besar [15] melalui model matematika jaringan, [16] dan sebagai bagian dari kategori teknologi jaringan baru, jaringan berbasis maksud. [17] Vendor perangkat lunak jaringan yang menawarkan solusi verifikasi formal termasuk Cisco [18], Forward Networks [19] [20] dan Veriflow Systems. [21]

Compiler CompCert C adalah kompiler C yang diverifikasi secara formal yang mengimplementasikan mayoritas ISO C.

6
Dan Dascalescu

Dalam keamanan, kami ingin percaya bahwa tidak ada yang dapat diamankan, hanya diperkeras.

Ini karena tidak peduli berapa banyak Anda mencoba untuk memperbarui perangkat lunak dan aplikasi Anda, Zero Day ada. Terutama jika perangkat lunak Anda layak untuk diretas. Ini berarti meskipun tim insinyur keamanan Anda mungkin dapat menambal masalah, perangkat lunak dapat dieksploitasi sebelum kerentanan dipublikasikan.

Dan semakin banyak aplikasi yang Anda buat di perangkat lunak Anda, semakin tinggi peluang Zero days.

5
s h a a n

Itu mungkin, tetapi tidak ekonomis tanpa peraturan yang saat ini tidak ada.

Jawaban tentang kernel seL4 terbukti benar sangat baik dalam memberikan contoh kode bebas bug dalam arti bahwa itu akan melakukan persis seperti yang dijelaskan - dan jika mereka deskripsi salah, well, itu bisa disebut exploit. Tetapi bug dalam deskripsi/spesifikasi sangat jarang dan dapat diperdebatkan jika mereka benar-benar bug.

Batasan yang juga dikutip dalam jawaban lain semuanya bermuara pada "kami membatasi diri pada kernel, karena kami memiliki sumber daya yang terbatas". Semuanya dapat diselesaikan dengan mengembangkan perangkat keras dan perangkat lunak di sekitarnya serta perangkat lunak klien dengan cara yang sama seperti kernel seL4.

Jika semua orang melakukan ini, maka menulis, katakanlah, situs web yang terbukti benar akan menjadi sepele, karena semua alat yang akan Anda gunakan akan terbukti benar dan Anda hanya akan menulis sedikit kode lem. Jadi jumlah kode yang perlu dibuktikan benar untuk proyek kecil akan kecil. Saat ini, jumlah kode yang perlu dibuktikan benar jika Anda ingin menulis sebuah program kecil yang benar terbukti sangat besar karena pada dasarnya Anda harus memulai dari awal tanpa memiliki alat yang tersedia yang dikembangkan sejak awal komputer .

Beberapa orang saat ini menyerukan alat-alat yang menindas seperti seperti pengawasan dan sensor dan blokade perdagangan dan serangan balik dalam menanggapi digitalisasi. Jika mereka beralih ke insentif perangkat lunak yang aman, misalnya dengan meminta sejumlah kewajiban (juga disebut tanggung jawab) dari produsen perangkat lunak dan perangkat keras, maka kami akan segera memiliki perangkat lunak yang aman. Butuh waktu lebih sedikit untuk membangun kembali ekosistem perangkat lunak kami dengan cara yang benar-benar aman daripada yang diperlukan untuk membuatnya pada awalnya.

5
Nobody

Saat ini, sangat mahal untuk menulis kode bebas bug yang cukup rumit. Bahkan lebih mahal untuk memverifikasi bahwa itu sebenarnya bebas bug, atau program verifikasi bebas bug, ad infinitum. Saya tidak berpikir ada orang yang sudah memiliki solusi untuk skala sebagian besar perangkat lunak komersial.

Tapi saya berpendapat bahwa beberapa program, yang mungkin memiliki bug, akan setidaknya bebas dari kerentanan. Sebagai contoh, sebuah program yang seharusnya berjalan di kotak pasir yang sempurna seperti browser, dan tidak berusaha untuk berinteraksi dengan apa pun kecuali pengguna, atau setidaknya tidak memiliki janji yang terdokumentasi yang diyakini oleh program lain. Jika ada sesuatu yang salah, itu adalah kerentanan kotak pasir, dan bukan program itu sendiri.

Kami memiliki cara untuk merancang sistem yang menerima hasil hanya jika beberapa versi program yang dirancang berbeda setuju. Dan kami memiliki cara untuk membuat bagian-bagian dari sebuah program tanpa kewarganegaraan. Kita bisa menciptakan kembali janji dengan menggunakan metode ini. Sebagai program sandboxing akan memiliki kompleksitas terbatas, saya berpendapat bahwa, di masa depan yang jauh, ada beberapa harapan untuk membuatnya pada akhirnya mungkin untuk menulis kode bebas exploit selama semua algoritma yang digunakan terbukti. Saya tidak tahu apakah itu akan menjadi layak secara ekonomi.

3
user23013

Sebagian besar jawaban berfokus pada bug yang memungkinkan eksploitasi. Ini sangat benar. Namun ada jalan yang lebih mendasar untuk eksploitasi.

Jika bisa diprogram, bisa diretas.

Setiap sistem yang dapat diprogram dapat dikatakan melakukan hal-hal bodoh, bahkan hal-hal jahat.
Programabilitas dapat memiliki banyak bentuk, beberapa di antaranya tidak terlalu jelas. Misalnya adalah pengolah kata atau spreadsheet yang memiliki fitur makro. Fitur ini memberikan urutan kepada pengguna. Jika di samping itu, ada fitur menyediakan pilihan dan pengulangan, tiba-tiba itu sangat diprogram.

Jika tidak dapat diprogram, pengguna akan menuntut lebih banyak fleksibilitas.

Hampir semua paket aplikasi kompleks pada akhirnya akan menciptakan lingkungan di mana pengguna ingin mengotomatiskan perilaku rutin mereka. Otomatisasi ini kadang-kadang mengambil bentuk skrip, seperti Powershell atau Python, tetapi kadang-kadang muncul melalui sesuatu seperti fitur makro dengan beberapa lonceng dan peluit tambahan untuk otomatisasi. Ketika pembangun mengakomodasi pengguna, tiba-tiba itu adalah sistem yang dapat diprogram.

2
Walter Mitty

Pikirkan saja dalam hal 'mengembangkan' sebuah bangunan yang tidak dapat ditembus ... dan pikirkan beberapa skenario dan asumsi yang mungkin:

  • apakah anggaran terbatas? Selalu begitu! Aktor jahat dengan anggaran yang lebih besar dapat membeli sarana untuk masuk (seperti membeli alat, menyuap tukang bangunan, ...)
  • selalu ada skala lingkungan di luar yang tidak dapat Anda kendalikan: suatu wilayah yang mengalami kehancuran, sebuah meteor yang menyerang infrastruktur keselamatan penting, kemajuan teknologi lebih lanjut di garis yang Anda tidak punya cara untuk merencanakan, ...

Anda dapat membiarkan imajinasi Anda menjadi liar dengan contoh ini.

Dan sekarang menerima kenyataan bahwa bangunan sering kali lebih mudah untuk dipertahankan sebagai objek fisik, kemungkinan besar lebih sederhana dan jarang dibangun dari komponen dengan rantai ketergantungan yang lama atau sulit untuk membuktikan sumbernya seperti perpustakaan perangkat lunak pihak ke-3.

2
diginoise

Secara teoritis, ya.

Meskipun perangkat lunak bebas exploit adalah mungkin, sangat sulit untuk dicapai, jika Anda dapat memprogram perangkat lunak untuk memprogram untuk Anda, secara teknis, ini dimungkinkan. Saya pernah mendengar ada orang yang mencoba membuat sesuatu seperti ini, meskipun lebih sulit daripada kelihatannya, membuat bot yang bisa diprogram untuk Anda, lebih sulit daripada kelihatannya. Cara lain sebuah program dapat dieksploitasi secara gratis adalah jika perangkat lunaknya terbukti secara matematis. Walaupun, kode buatan manusia tidak dapat mencapai sesuatu seperti ini, tipe lain pemrograman dapat dieksploitasi gratis jika tidak memerlukan input manusia.

1
yosh

Menulis kode sempurna seperti membangun mobil yang sempurna. Kita mungkin dapat membangun mobil yang sempurna tetapi hanya untuk usia kita saat ini. Seiring dengan perkembangan teknologi, ide-ide dibagikan dan lebih banyak otak berkumpul untuk menyelesaikan masalah maka Anda mungkin memiliki sesuatu yang jauh lebih baik.

Anda benar mengatakan bahwa jika suatu perusahaan terus mengerjakan perangkat lunak, maka pada suatu waktu mereka akan bebas bug. Itu benar, tetapi seiring waktu teknologi yang berbeda berevolusi dan Anda membuat pilihan untuk tetap up to date dengan teknologi atau hanya mengikuti basis kode lama yang sama.

Mari kita ambil contoh facebook karena mereka adalah kelompok besar dan fokus pada satu produk. Facebook digunakan untuk menggunakan perpustakaan jquery untuk semua hal yang dinamis beberapa tahun yang lalu. Itu adalah teknologi canggih dan semuanya berjalan dengan baik dan tidak pernah berpikir untuk menggantinya. Tetapi untuk membuat pengguna tetap terlibat, mereka harus menjadi lebih dinamis. Jadi ketika facebook tumbuh dan membutuhkan fungsionalitas yang semakin dinamis dan menyadari bahwa jquery tidak memenuhi kebutuhan mereka.

Karena tidak ada situs web lain yang memiliki banyak pengguna, tidak ada orang yang benar-benar memahami perlunya perpustakaan yang lebih baru. Jadi mereka mulai bekerja di perpustakaan mereka sendiri yang disebut React. Seiring berjalannya waktu, semakin banyak orang mulai menggunakan internet karena facebook dan jelas mereka diperkenalkan ke situs lain juga. Sekarang situs web lain juga mulai memiliki masalah yang dihadapi facebook, tetapi untungnya sekarang mereka memiliki React Perpustakaan untuk memenuhi kebutuhan mereka alih-alih membangun yang baru.

Google memiliki masalah yang sama dan alih-alih menggunakan facebook React mereka berpikir untuk membangun sendiri untuk memenuhi kebutuhan spesifik mereka. Ini akan terus berjalan dan tidak akan pernah ada basis kode tunggal yang sempurna.

Ini adalah hukum alam setiap kali sesuatu yang lebih besar tiba yang mendorong lebih banyak orang untuk berpikir lebih besar dan melakukan lebih baik dari itu, Mirip dengan bagaimana semakin banyak karakter yang kuat terus datang dalam Avengers.

Karena waktu adalah satu-satunya entitas yang unik dan tidak pernah ada jumlah waktu yang tidak terbatas. Pemilik bisnis dan pengembang membuat triad off. Triad off dalam kode dapat berupa sesuatu seperti:

  • Untuk lebih dioptimalkan/lebih cepat atau lebih mudah dikelola?
  • Untuk lebih fokus pada keamanan atau untuk memiliki pengalaman pengguna yang lebih baik?
  • Haruskah fitur baru diuji lebih lanjut atau untuk mengirim fitur baru tepat waktu?

Kami membuat triad ini off setiap hari ...

1
omer Farooq

Untuk kasus (program) tertentu, hampir . Secara umum, TIDAK

  1. Untuk kasus tertentu:

Anda dapat berulang kali memperbaiki program yang diberikan sampai sebagian besar atau semua bentuk kerentanan yang diketahui (mis. Buffer overflows) hilang, tetapi banyak bentuk kerentanan terjadi di luar kode sumber. Misalnya, Anda mengkompilasi sedemikian rupa sehingga program hampir atau sempurna. Ini menghasilkan objek atau program yang dapat dieksekusi yang Anda distribusikan. Di komputer target itu terkena malware yang dapat memodifikasi sedemikian rupa sehingga kode biner mis. Memasukkan lompatan ke kode berbahaya yang tentu saja, tidak ada dalam program asli.

  1. Secara umum

Apakah mungkin untuk memiliki program, sekarang atau di masa depan, dapat memvalidasi kode sumber any program untuk kerentanan?

Sedikit teori. Menjadi program yang bebas kerentanan adalah properti semantic dari program, bukan yang sintaksis. Properti sintaksis dapat diformalkan (dan karenanya, dapat dideteksi dengan metode formal), tetapi properti semantik tidak dapat:

Properti semantik adalah properti yang bukan properti semantik yang sepele. properti semantik yang sepele adalah properti yang selalu ada atau selalu tidak ada dalam semua dan setiap program. Properti semantik yang terkenal dari program adalah " Program ini akan berjalan selamanya" (Turing yang terkenal menghentikan masalah ) karena beberapa program akan berjalan selamanya, sementara yang lain menang ' t. Turin terbukti bahwa masalah penghentian adalah tidak dapat dipastikan , jadi metode formal untuk menguji sifat penghentian setiap program tidak dapat ada.

The teorema Rice menyatakan bahwa semua properti non-sepele, semantik program juga tidak dapat diputuskan. Faktanya, buktinya didasarkan pada fakta bahwa jika properti semantik non-sepele dari program dapat ditentukan, itu dapat digunakan untuk menyelesaikan program penghentian, yang tidak mungkin.

Sebagai contoh properti semantik lainnya, pertimbangkan properti " Program ini berbahaya". Tentu saja ini adalah properti semantik dan karenanya, sebagai konsekuensi dari teorema Rice, program deteksi malware formal dan deterministik tidak dapat dibangun; kebanyakan dari mereka menggunakan heuristik untuk prosedur deteksi mereka.

Tentu saja, seperti yang digunakan dalam deteksi malware, Anda dapat menggunakan heuristik, kecerdasan buatan, pembelajaran mesin, dll. Untuk mendekati metode pencarian kerentanan dalam kode, tetapi yang formal, sempurna, dan deterministik tidak bisa ada.

1

Aturan pertama pengujian perangkat lunak (QA):

'Tidak dapat dikonfirmasi bahwa bug terakhir telah ditemukan'.

Saya telah berkode sejak 1980 (juga seorang insinyur elektronik) dan tidak ada perangkat lunak saya telah dieksploitasi, itu tidak berarti tidak mungkin, hanya saja tidak ada yang melakukannya. Sistem perbankan (dan sistem 'seperti Snowden') memiliki peringatan/audit pemicu otomatis untuk mencatat akses yang tidak sah (Saya telah bekerja pada sistem yang serupa).

Jadi, ya, mengeksploitasi perangkat lunak bebas adalah mungkin, tetapi bagaimana Anda menghitung/memverifikasinya?

Akhirnya, cari aturan FCC (USA):

Bagian 15 dari aturan FCC, yang mengatur perangkat yang tidak berlisensi, menggabungkan prinsip fundamental kebijakan spektrum A.S.: perangkat yang tidak berlisensi harus menerima gangguan dari sumber apa pun, dan tidak boleh menyebabkan interferensi berbahaya ke layanan berlisensi apa pun

Yang berarti sinyal Wi-Fi Anda 'dapat dieksploitasi' yang pada gilirannya berarti perangkat lunak di dalamnya 'dapat dieksploitasi'.

0
Mr. de Silva