Dugaan macOS Sequoia 15 Melewati Enkripsi DNS, Ternyata Masalah Little Snitch 6.1

 (obdev.at)
1 poin oleh GN⁺ 2024-09-18 | 2 komentar | Bagikan ke WhatsApp
  • Little Snitch 6.1 dapat gagal melakukan enkripsi DNS dalam beberapa situasi, tetapi masalah ini telah dipersempit bukan sebagai masalah macOS secara umum, melainkan masalah pada versi tersebut, dan telah diperbaiki di 6.1.1
  • Agar berfungsi normal, permintaan DNS macOS harus diteruskan ke proxy DNS Little Snitch, lalu proxy tersebut melakukan kueri terenkripsi
  • Dalam investigasi, diamati bahwa sebagian permintaan melalui API lama tingkat rendah tidak mencapai proxy dan mengirim kueri UDP 53 yang tidak terenkripsi ke nameserver default sistem
  • Cara reproduksinya adalah mengaktifkan enkripsi DNS di Little Snitch, menjalankan Wireshark dengan filter port 53, lalu memanggil getaddrinfo("dnsproxytest.com") di Xcode playground
  • Kueri berbasis API tingkat tinggi seperti Safari dan Chrome awalnya tampak tidak terdampak, sementara Firefox tampak terdampak, tetapi cakupan akhirnya disimpulkan sebagai masalah pada proxy DNS Little Snitch 6.1

Kegagalan enkripsi DNS yang terjadi di Little Snitch 6.1

  • Fitur enkripsi DNS di Little Snitch 6 merutekan pencarian hostname ke Little Snitch agar diproses dalam bentuk terenkripsi
  • Untuk itu, Little Snitch mendaftarkan proxy DNS, dan macOS seharusnya mengirim semua permintaan DNS ke proxy tersebut
  • Ditemukan bahwa sebagian permintaan DNS, terutama permintaan melalui API lama tingkat rendah tertentu, tidak diterima oleh proxy
  • Permintaan tersebut dapat dikirim ke nameserver default sistem dalam bentuk tidak terenkripsi, dan di Wireshark dapat dikonfirmasi sebagai trafik UDP port 53
  • Trafik kueri tersebut tidak muncul di Little Snitch Network Monitor, karena kueri itu sepenuhnya melewati filter jaringan

Prosedur reproduksi dan perkembangan pembaruan

  • Prosedur reproduksi

    • Aktifkan DNS encryption di pengaturan Little Snitch
    • Jalankan Wireshark dengan filter tangkapan port 53
    • Jalankan kueri dnsproxytest.com dengan getaddrinfo di Xcode playground
    • Kueri dnsproxytest.com dapat terlihat di UDP 53 dalam bentuk tidak terenkripsi

  • Cakupan dampak awal

    • Kueri DNS melalui API tingkat tinggi tampak tidak terdampak
    • Penjelajahan web di Safari dan Chrome tampak tetap mendapatkan manfaat dari kueri terenkripsi
    • Firefox tampak terdampak

  • Riwayat pembaruan

    • 2024-09-17 19:10: Dikonfirmasi bahwa masalah ini mungkin sudah ada sejak macOS 14.5 Sonoma, dan sistem 14.x yang lebih lama tidak dapat diuji
    • 2024-09-18 12:05: Masalah ini disimpulkan bukan sebagai masalah proxy DNS umum di macOS, melainkan masalah yang hanya memengaruhi proxy DNS Little Snitch 6.1
    • 2024-09-18 15:52: Masalah telah diperbaiki di Little Snitch 6.1.1

Bacaan terkait

2 komentar

 
GN⁺ 2024-09-18
Komentar Hacker News

  • Agak aneh rasanya bahwa getaddrinfo() diperlakukan sebagai “API lama tingkat rendah”
    Situasinya mungkin sangat berbeda di macOS, tetapi di Linux dan mungkin *BSD, ini adalah cara standar yang digunakan untuk resolusi nama
    Sebagian besar aplikasi macOS mungkin memakai framework semacam Foundation atau NetworkKit untuk kueri DNS, tetapi juga mengejutkan bahwa di dalamnya ternyata tidak berujung diproses lewat pemanggilan seperti getaddrinfo()
    Karena GAI bersifat blocking, mungkin ada pemanggilan asinkron tingkat rendah lain

    • Benar. CFNetwork bersifat open source sehingga implementasinya bisa diperiksa, dan seingat saya saat melihatnya dulu, ia memakai variasi seperti getaddrinfo_async
      Namun Apple tidak ingin pengguna akhir melakukan resolusi IP secara langsung lewat getaddrinfo atau variasi asinkron yang diekspos CF, lalu melakukan connect() ke IP tersebut
      Secara umum, mereka mendorong agar koneksi dilakukan berdasarkan hostname, supaya Apple dapat menangani implementasi happy eyeballs secara internal
      Mengapa Apple tidak menyukai model getaddrinfo() bisa dilihat di https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf. Ada juga catatan pembicara di bawah tiap slide
    • Saya tidak melihat getaddrinfo() dianggap legacy. Sepertinya tulisan blog itu keliru di bagian ini
      Apakah itu “tingkat rendah” atau tidak tergantung sudut pandang
    • getaddrinfo() bukan sesuatu yang terkait dengan Linux, melainkan sekadar fungsi glibc
      Orang-orang mengasumsikan glibc sebagai cara standar di userspace Linux, tetapi tidak harus selalu begitu
      Misalnya, systemd membuat mekanisme resolved sendiri, dan ternyata jauh lebih baik daripada sisi glibc
      Saya juga membuat perangkat lunak standalone yang menargetkan Linux, jadi kemungkinan besar suatu saat saya akan membuat sesuatu yang mirip sendiri
    • Di OpenBSD, setidaknya fungsi-fungsi DNS tradisional dan standar seperti getaddrinfo/gethostbyname semuanya adalah wrapper atas implementasi asr di libc OpenBSD yang ditulis oleh Eric Faurot
      https://man.openbsd.org/man3/asr_run.3
      https://github.com/openbsd/src/tree/master/lib/libc/asr
    • Saya tidak tahu apakah kasus ini persis demikian, tetapi bahkan fungsi sistem dengan nama yang sama pun implementasi internalnya bisa sangat berbeda antara *Linux/BSD/macOS
      Di antara varian *BSD sendiri juga ada perbedaan
      Pada satu sistem, sebuah pemanggilan fungsi bisa dipertahankan selama bertahun-tahun dan menjadi “cara baku”, sedangkan pada sistem lain bisa saja benar-benar usang dan tidak berguna

  • Masalah yang dibahas di sini ternyata bukan masalah macOS secara umum, melainkan hanya berlaku pada Little Snitch 6.1, dan akan diperbaiki lewat pembaruan Little Snitch nanti hari ini

    • Akan bagus kalau judulnya juga bisa diperbarui agar mencerminkan hal ini

  • Dari investigasi tambahan, bug ini sudah ada setidaknya sejak macOS 14.5 Sonoma
    Mungkin saja sudah ada sejak lebih lama, tetapi katanya saat ini tidak ada akses ke sistem 14.x yang lebih lama untuk diuji

    • Saya penasaran apakah mereka pernah menguji apakah ini benar-benar berfungsi pada getaddrinfo
      Atau apakah mereka hanya melihatnya berfungsi sekali di CFNetwork, lalu belakangan menulis blog bahwa itu rusak
    • Situasi di mana pengembang masih harus menyimpan versi OS lama secara terpisah untuk pengujian masih saja tidak masuk akal
      Hampir tidak ada alasan teknis yang membuat Apple tidak bisa mengizinkan downgrade
    • Mengingat mereka menjual produk dan OS baru baru saja keluar kemarin, ini juga cukup absurd

  • Sequoia, jika firewall macOS aktif dan sebuah aplikasi didaftarkan sebagai “blokir koneksi masuk”, merusak kemampuan aplikasi tersebut untuk memakai DNS, dan mungkin juga fungsi berbasis UDP secara umum
    https://waclaw.blog/macos-firewall-blocking-web-browsing-aft...

    • Saya tidak bisa mereproduksinya. Sebagian orang mengatakan ini terkait dengan ESET: https://www.reddit.com/r/MacOS/comments/1fievr5/updating_mad...
    • Sebelum Sequoia, meski memakai OpenDNS di VPN, iMessage dan aplikasi lain tetap berjalan saat terhubung ke VPN, tetapi setelah Sequoia, pesan iMessage dan sejenisnya tidak lagi berfungsi saat VPN terhubung
      Jika VPN diputus, semuanya bisa lewat
      Saya penasaran apakah ini terkait. Firewall macOS aktif, tetapi tidak memblokir semua koneksi masuk
    • Setelah upgrade ke Sequoia, saya tidak bisa browsing dengan Safari atau Mozilla
      Masuk ke pengaturan DNS pada koneksi Wi-Fi lalu menambahkan server DNS Google, 8.8.8.8 dan 8.8.4.4, menyelesaikan masalah, dan menggantikan server DNS yang sebelumnya terisi otomatis
    • Jujur saja, menurut saya perilaku seperti ini baik-baik saja. Aplikasi tidak boleh melakukan resolusi DNS sendiri di luar apa yang ditentukan di pengaturan
      Alasan aplikasi melakukan ini adalah agar pengguna tidak bisa memblokir hal-hal seperti telemetri
      Ini komputer saya, jadi saya harus punya keputusan akhir atas apa yang keluar darinya

  • Judulnya mengisyaratkan seolah-olah ini disengaja atau diberlakukan secara istimewa untuk Apple, tetapi sebenarnya tampaknya lebih dekat ke sekadar bug
    Kalau melaporkan hal seperti ini, akan lebih baik jika juga menyertakan nomor FB dan detail laporannya

    • Dari sudut pandang pembela setan, mereka bisa saja sengaja membuatnya seperti ini untuk menghindari penolakan dan membuatnya tampak seperti bug yang tidak diperbaiki
      Selama tujuannya tercapai, cara implementasinya bisa sangat fleksibel
    • Jika memang disengaja, kemungkinan itu berupa URL yang di-hardcode dan dienkripsi
      Beberapa perangkat sudah mulai memakai cara seperti itu untuk melewati pemblokiran iklan

  • Mungkin saya keliru, tetapi setiap kali ada rilis baru iOS atau Mac, rasanya seperti déjà vu: muncul masalah DNS yang berdampak pada hal-hal seperti Little Snitch dan Mullvad
    Jika benar, saya benar-benar bertanya-tanya apa yang dilakukan Apple selama berbulan-bulan pengujian developer dan beta

  • Penyebutan Little Snitch sempat membingungkan, tetapi setelah membaca lebih lanjut, ini tampaknya seperti bug LS yang hanya terjadi pada kasus tertentu
    Kalau ini blog LS, satu-satunya pertanyaan adalah mengapa ini digambarkan seperti bug macOS
    Bukan berarti mereka salah, dan itu memang ranah mereka, bukan ranah saya, tetapi dari isi artikelnya saja pembenarannya tampak kurang kuat

    • Jika OS mengizinkan pendaftaran proksi DNS lalu sebagian panggilan melewati proksi itu, maka itu jelas bug OS

  • Saya ingat Apple pernah menandai penggunaan API jaringan tertentu oleh developer pihak ketiga sebagai deprecated
    Namun aplikasi Apple sendiri, misalnya App Store, tidak terkena pembatasan yang sama
    Jadi ketika mencoba memfilter traffic jaringan melalui firewall aplikasi dengan API baru, itu gagal karena App Store memakai API lama
    Ini mungkin bagian dari bug lama yang saya kira sudah diperbaiki dulu

    • getaddrinfo() bukan API lama, melainkan API lintas platform standar untuk kueri DNS

  • Pengumuman seperti “Bug ditemukan di rilis OS baru! Koreksi: ternyata bug itu sudah ada cukup lama!” selalu menghibur

  • Saya memakai routedns [0] sebagai resolver stub lokal untuk memilih sendiri permintaan mana dikirim ke mana dan memakai metode transport apa
    Ia juga bisa menangani daftar blokir, penulisan ulang, cache, load balancing, dan permintaan alternatif, jadi kontrolnya besar
    Untuk permintaan lokal, saya memakai listener stub di localhost:53, dan sebagian besar permintaan diteruskan ke Cloudflare 1.1.1.1 lewat UDP QUIC dengan cache, yaitu TLS 0-RTT
    Cepat dan cukup aman
    [0] https://github.com/folbricht/routedns
 
nearfall 2024-09-18

Terima kasih atas informasi pentingnya.
Untuk saat ini, syukurlah Safari dan Chrome dikatakan aman.