Insiden Keamanan curl Apple 12604

 (daniel.haxx.se)
1 poin oleh GN⁺ 2024-03-10 | 1 komentar | Bagikan ke WhatsApp
  • curl yang dibundel Apple di macOS menangani opsi --cacert secara berbeda dari build open source, sehingga mematahkan ekspektasi verifikasi TLS bahwa hanya CA yang ditentukan pengguna yang dipercaya
  • --cacert adalah opsi yang membuat sertifikat server diverifikasi hanya dengan kumpulan sertifikat CA yang ditentukan; jika verifikasi gagal, curl seharusnya mengembalikan error
  • curl yang disediakan Apple tampaknya tetap memeriksa penyimpanan CA sistem sebagai tambahan meskipun verifikasi CA yang ditentukan gagal; perilaku ini tidak diminta dan tidak didokumentasikan
  • Apple Product Security menjawab bahwa LibreSSL, OpenSSL versi Apple, memang secara sengaja menggunakan penyimpanan kepercayaan sistem bawaan sebagai sumber kepercayaan default, sehingga bukan target perbaikan
  • Karena ini bukan kerentanan pada distribusi proyek curl, CVE tidak diterbitkan, tetapi hasil verifikasi CA pada curl bundel macOS dapat berbeda dari dokumentasinya

Awal isu 12604

  • Pada 28 Desember 2023, bugreport 12604 didaftarkan di issue tracker curl
  • Judul isunya adalah “flag --cacert behavior isn’t consistent between macOS and Linux”, dan dilaporkan oleh Yuedong Wu
  • Bahkan ketika menjalankan versi curl yang sama di mesin macOS yang sama, perilaku curl bundel Apple berbeda dari binary curl yang dibangun dari open source

Jaminan yang diharapkan dari --cacert

  • Opsi command line curl --cacert adalah cara untuk membuat curl, pada transfer berikutnya, hanya mempercayai persis kumpulan sertifikat CA yang ditentukan
  • Jika server TLS tidak dapat menyediakan sertifikat yang bisa diverifikasi dengan kumpulan sertifikat tersebut, curl harus gagal dan mengembalikan error
  • Opsi ini ditambahkan ke curl pada Desember 2000, sebagai fitur untuk memastikan pengguna berkomunikasi dengan server yang mereka kenal dan percayai
  • Pada akhirnya, ini bersinggungan langsung dengan peran dasar yang seharusnya disediakan TLS

Perilaku pengecualian curl bundel macOS

  • curl untuk macOS yang disediakan Apple, saat --cacert digunakan, tampaknya memeriksa penyimpanan CA sistem sebagai tambahan jika verifikasi dengan kumpulan sertifikat CA yang ditentukan gagal
  • Pemeriksaan tambahan ini bukan perilaku yang diminta pengguna, dan juga tidak ada dalam dokumentasi, sehingga sulit diprediksi
  • Meski pengguna mencoba melakukan verifikasi dengan file sertifikat CA khusus yang dipersempit, verifikasi tidak akan gagal jika di penyimpanan CA sistem terdapat sertifikat yang dapat memverifikasi server
  • Akibatnya, verifikasi sertifikat yang seharusnya tidak lolos bisa saja lolos, sehingga dianggap sebagai masalah keamanan

Jawaban Apple Product Security

  • Pada 29 Desember 2023 pukul 08:30 UTC, email laporan masalah keamanan diteruskan ke Apple Product Security
  • Apple Product Security menjawab pada 8 Maret 2024
  • Jawaban Apple dapat dirangkum dalam dua poin
    • LibreSSL, OpenSSL versi Apple, secara sengaja menggunakan penyimpanan kepercayaan sistem bawaan sebagai sumber kepercayaan default
    • Karena sertifikat server dapat berhasil diverifikasi dengan penyimpanan kepercayaan sistem bawaan, Apple tidak menganggapnya sebagai masalah yang perlu ditangani di platform Apple
  • Apple menutup kasus ini

Penilaian proyek curl dan dampaknya bagi pengguna

  • Fitur yang tidak didokumentasikan di macOS ini membuat verifikasi sertifikat CA curl tidak konsisten dengan dokumentasi
  • Pengguna mengharapkan hanya kumpulan sertifikat CA yang ditentukan lewat --cacert yang digunakan, tetapi curl yang disediakan Apple berperilaku berbeda dari ekspektasi tersebut
  • Masalah ini bukan kerentanan keamanan pada versi curl yang didistribusikan oleh proyek curl
    • Proyek curl tidak menerbitkan CVE untuk masalah ini
    • Masalahnya bukan pada kode curl itu sendiri, melainkan berasal dari versi LibreSSL yang disediakan Apple di platformnya dan digunakan untuk build curl
  • Saat menggunakan curl yang disediakan Apple di macOS, hasil verifikasi berbasis --cacert dapat berbeda dari curl build open source

Bacaan terkait

1 komentar

 
GN⁺ 2024-03-10
Komentar Hacker News

  • Perilaku itu benar-benar bodoh. Jika saya secara eksplisit menunjuk CA, alasannya biasanya salah satu dari dua ini: CA saya tidak ada di bundel sistem operasi, atau saya ingin memverifikasi hanya terhadap CA tertentu
    Jadi “fitur” Apple ini entah menambah komputasi yang tidak perlu, atau merusak model verifikasi yang diharapkan. Keduanya bukan hasil yang pantas diharapkan

    • Koreksi kecil: fallback ke penyimpanan CA Apple terjadi saat pemeriksaan awal gagal. Jadi kemungkinan tidak akan menambah komputasi yang tidak perlu
      Tetap saja, saya setuju ini perilaku buruk karena hasilnya tidak sesuai harapan. Mengingat Apple biasanya cenderung membuat perubahan yang merusak kompatibilitas ke belakang, dan fitur ini ditambahkan ke curl, rasanya ada keadaan lain yang tidak diungkap Apple. Mungkin ini dipakai untuk alat diagnostik pengembang atau verifikasi AppStore
    • Ada pepatah jangan mengaitkan niat jahat pada sesuatu yang bisa dijelaskan oleh kebodohan, tetapi jika pelaku jahat memakai Pisau Cukur Hanlon sebagai pembelaan, kita harus ekstra waspada

  • Sayangnya, perilaku seperti ini—di mana apa pun yang ingin dilakukan “pemilik” perangkat Apple selalu kalah oleh kebijakan Apple—tidak mengejutkan, dan memang selalu harus diantisipasi dari Apple

    • Itulah kenapa saya tidak memakai Apple. Perangkatnya memang tampak dibuat dengan sangat baik dan sistem operasinya juga rapi, tetapi cara mereka mengurung pengguna dalam pendekatan dan ekosistem mereka sendiri, serta bahkan menghalangi akses ke perangkat keras milik sendiri, tidak cocok dengan hidup sebagai hacker dalam pengertian HN
      Setidaknya tidak cocok untuk bagian kehidupan digital itu, dan mengingat harganya, sulit juga membeli satu hanya sebagai perangkat pendamping. Saya terus mempertimbangkan untuk mencoba produk Apple, terakhir headset AR juga begitu, tetapi sejauh ini mereka terlihat terlalu memusuhi pengembang atau tukang oprek
    • Menjalankan curl open-source akan memberi Anda perilaku yang diinginkan
    • Sayangnya, selalu ada orang yang membaca terlalu jauh keputusan teknis tingkat rendah untuk “membuktikan” prasangka mereka sendiri
      Menganggap perusahaan sebesar Apple membuat keputusan seperti ini demi visi yang lebih besar bahwa mereka “memiliki” perangkat pengguna berarti memberikan Apple kemampuan organisasi dan koordinasi yang luar biasa besar. Bahkan di organisasi yang ukurannya sepersepuluh Apple pun saya belum pernah melihat tingkat seperti itu. Tapi karena ini Apple, tentu saja begitu, kan!?
    • Pemiliknya adalah Apple, Anda hanya pengguna ;)

  • Mungkin Apple yang mengatur ini?[0] penekanan dari saya
    CURLSSLOPT_NATIVE_CA
    Memberi tahu libcurl untuk memakai penyimpanan CA bawaan sistem operasi untuk verifikasi sertifikat. Jika opsi ini disetel dan file sertifikat CA atau direktori juga disetel, sertifikat tersebut juga akan dicari bersama penyimpanan CA bawaan saat verifikasi
    Jika --cacert digabungkan dengan opsi ini, tampaknya libcurl berusaha menghormati keduanya. Bukankah keduanya seharusnya saling eksklusif?

    • Tidak, bukan begitu kasusnya. Biner curl tahu bagaimana memanggil library libcurl

  • Ini adalah backdoor
    Saya tidak bilang ini disengaja atau jahat. Tapi secara efektif ini memang backdoor. Kalau Anda mulai menambahkan kunci ke sistem kepercayaan pengguna, berarti Anda telah menambahkan backdoor

    • Ini terlihat persis seperti jenis hal yang mungkin ditekan NSA kepada perusahaan teknologi besar AS untuk dilakukan

  • Perilaku default-nya memang mencurigakan, tetapi saya tidak sepenuhnya setuju dengan penilaian ini. Sebenarnya ini masalah dokumentasi curl
    curl adalah library multi-protokol, jadi tidak mengimplementasikan semua protokol sendiri, dan dalam banyak kasus bergantung pada “backend” sebagai dependensi transitif yang menyerahkan parsing bit tingkat rendah ke pihak luar. Beberapa protokol memang punya dukungan untuk beberapa library alternatif karena alasan yang masuk akal
    Kelemahan pendekatan ini adalah sulit atau mustahil menjamin perilaku yang konsisten di antara backend-backend yang independen. Mereka mungkin tidak semua menyediakan fitur yang sama, API-nya mungkin tidak lengkap, atau seperti kali ini, mungkin tidak menyediakan cara untuk menambal sebagian perilaku default. LibreSSL bukan implementasi ulang OpenSSL secara bit demi bit, dan juga tidak wajib meniru seluruh API-nya
    Dalam kasus seperti ini, jika upstream enggan memperbaikinya, curl hanya punya dua pilihan: menghentikan dukungan untuk library tersebut, atau mendokumentasikan perilaku khusus itu. Yang pertama bisa merusak kode pengguna, jadi setidaknya yang kedua harus dilakukan
    Meski begitu, saya setuju dengan garis besar bahwa ini adalah cacat dari sudut pandang keamanan LibreSSL, dan mungkin memang ada alasan untuk membuka CVE. Hanya saja targetnya seharusnya LibreSSL

    • Jika akar masalahnya ada di library SSL sistem, saya kurang paham bagaimana membangun curl dari source bisa menghindari masalah ini

  • Ini mengingatkan saya pada insiden F_BARRIERFSYNC di SQLite
    Mereka memang tidak peduli
    https://bonsaidb.io/blog/acid-on-apple/

    • Ini mengingatkan saya pada kejadian lama ketika Apple benar-benar merusak salah satu alat Unix lawas yang mereka distribusikan sendiri dengan menyelipkan suatu opsi secara sembarangan
      Sikap pemeliharaan mereka kira-kira dua tingkat lebih buruk daripada orang Debian yang pernah merusak OpenSSL

  • Kalau Daniel bilang curl kalian rusak, ya perbaiki saja, Apple. Sesederhana itu

    • Daniel juga bisa salah. Bahkan soal curl pun dia bisa salah
      Dari yang saya cek selama dua menit di sini, sepertinya kali ini dia mungkin benar, tetapi “karena Daniel maka benar” adalah logika terburuk
      Ini mengingatkan saya pada percakapan lama tentang sejarah C, khususnya seputar “kontribusi” Eric S. Raymond: https://scienceblogs.com/deltoid/2011/10/14/dennis-ritchie-h...

  • Terima kasih atas peringatannya. Sebagai catatan, saya memakai MacPorts untuk mengganti cukup banyak alat bawaan macOS, dan curl adalah salah satunya
    Alat bawaan itu umumnya sudah tua atau rusak dengan cara lain. Saya sudah lama kehilangan kepercayaan pada software bundelan Apple

  • Saya penasaran apakah Apple bergantung pada perilaku ini untuk sesuatu yang penting

    • Tidak tahu ini sarkasme atau bukan, tapi ini jelas sangat penting
      Sangat masuk akal jika seseorang membuat skrip yang hanya memakai CA privat internal. Saat menjalankan perintah ini, Anda tahu bahwa ia hanya berkomunikasi dengan sumber daya internal perusahaan karena itu adalah CA internal perusahaan
      Namun Apple menambahkan backdoor sebesar verifikasi domain ke dalamnya
      Lebih jauh lagi, juga cukup masuk akal memakai nama dummy dan memastikan Anda sedang terhubung ke server perusahaan hanya berdasarkan fakta bahwa sertifikatnya ditandatangani oleh CA perusahaan. Tapi Apple merusak asumsi yang sangat masuk akal ini dan menciptakan kerentanan keamanan. Ini buruk
    • Mungkin untuk mempermudah penyadapan TLS oleh perusahaan atau pemerintah
    • Ini entah tindakan yang amat bodoh, atau tindakan yang jahat

  • Jadi segini rupanya kadar kepedulian Apple terhadap keamanan pengguna