macOS Sequoia 15’in DNS şifrelemesini atladığından şüphelenildi; aslında sorun Little Snitch 6.1’deymiş

 (obdev.at)
1 puan yazan GN⁺ 2024-09-18 | 2 yorum | WhatsApp'ta paylaş
  • Little Snitch 6.1’de DNS şifrelemesi bazı durumlarda başarısız olabiliyordu; ancak bunun macOS genelinde bir sorun değil, ilgili sürüme özgü bir sorun olduğu netleşti ve 6.1.1’de düzeltildi
  • Doğru çalışması için macOS’in DNS isteklerinin Little Snitch’in DNS proxy’sine iletilmesi, proxy’nin de şifreli sorguyu gerçekleştirmesi gerekiyor
  • İnceleme sırasında bazı düşük seviyeli eski API isteklerinin proxy’ye ulaşmadan sistemin varsayılan ad sunucusuna şifrelenmemiş UDP 53 sorguları gönderdiği gözlemlendi
  • Yeniden üretme yöntemi: Little Snitch’te DNS şifrelemesini açıp Wireshark’ı port 53 filtresiyle çalıştırdıktan sonra Xcode playground’da getaddrinfo("dnsproxytest.com") çağırmak
  • Safari ve Chrome gibi yüksek seviyeli API tabanlı sorgular başlangıçta etkilenmemiş gibi görünüyordu; Firefox’un etkilendiği düşünülüyordu, ancak nihai kapsam Little Snitch 6.1’in DNS proxy’si olarak belirlendi

Little Snitch 6.1’de yaşanan DNS şifreleme başarısızlığı

  • Little Snitch 6’nın DNS şifreleme özelliği, ana makine adı sorgularını Little Snitch’e yönlendirerek bunları şifreli biçimde işler
  • Bunun için Little Snitch bir DNS proxy kaydeder ve macOS’in tüm DNS isteklerini bu proxy’ye göndermesi gerekir
  • Bazı DNS isteklerinin, özellikle belirli düşük seviyeli eski API’ler üzerinden yapılanların proxy’ye ulaşmadığı keşfedildi
  • Bu istekler sistemin varsayılan ad sunucusuna şifrelenmemiş biçimde gönderilebiliyordu ve Wireshark’ta UDP port 53 trafiği olarak görülebiliyordu
  • Little Snitch Network Monitor’da bu sorgu trafiği görünmüyordu; çünkü sorgu ağ filtresini tamamen atlıyordu

Yeniden üretme adımları ve güncellemelerin seyri

  • Yeniden üretme adımları

    • Little Snitch ayarlarında DNS encryption etkinleştirilir
    • Wireshark port 53 yakalama filtresiyle çalıştırılır
    • Xcode playground’da getaddrinfo ile dnsproxytest.com sorgusu çalıştırılır
    • dnsproxytest.com sorgusu UDP 53 üzerinde şifrelenmemiş biçimde görünebilir

  • İlk etki kapsamı

    • Yüksek seviyeli API üzerinden yapılan DNS sorgularının etkilenmediği görülüyordu
    • Safari ve Chrome’da web gezintisinin şifreli sorguların avantajını koruduğu görülüyordu
    • Firefox’un etkilendiği görülüyordu

  • Güncelleme geçmişi

    • 2024-09-17 19:10: Bu sorunun macOS 14.5 Sonoma’dan beri mevcut olabileceği doğrulandı; daha eski 14.x sistemler test edilemedi
    • 2024-09-18 12:05: Sorunun macOS’in genel DNS proxy sorunu olmadığı, yalnızca Little Snitch 6.1’in DNS proxy’sini etkilediği netleşti
    • 2024-09-18 15:52: Sorun Little Snitch 6.1.1’de düzeltildi

İlgili okumalar

2 yorum

 
GN⁺ 2024-09-18
Hacker News yorumları

  • getaddrinfo()’nun “düşük seviyeli eski API” olarak ele alınması biraz tuhaf geliyor
    macOS’te durum çok farklı olabilir, ama Linux ve muhtemelen *BSD’de ad çözümleme için kullanılan standart yöntem bu
    macOS uygulamalarının çoğu DNS sorguları için Foundation ya da NetworkKit türü framework’leri kullanıyordur, ama bunların içinin sonunda getaddrinfo() gibi çağrılara inip işlemediği de şaşırtıcı
    GAI bloklayıcı olduğu için muhtemelen başka bir düşük seviyeli asenkron çağrı vardır

    • Doğru. CFNetwork açık kaynak olduğu için uygulamasına bakılabiliyor; geçmişte baktığımda getaddrinfo_async gibi bir varyant kullandığını hatırlıyorum
      Ancak Apple, son kullanıcıların IP’yi getaddrinfo ya da CF’nin sunduğu asenkron varyantlarla doğrudan çözüp sonra o IP’ye connect() yapmasını istemiyor
      Genel olarak ana makine adıyla bağlanmaya yönlendiriliyorsunuz; böylece Apple içeride happy-eyeballs uygulamasını halledebiliyor
      Apple’ın getaddrinfo() modelini neden tercih etmediğini https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf adresinde görebilirsiniz. Her slaydın altında konuşmacı notları da var
    • getaddrinfo()’nun eski kabul edildiğini sanmıyorum. Bence o blog yazısı bu kısmı yanlış yazmış
      “Düşük seviyeli” olup olmadığı bakış açısına göre değişir
    • getaddrinfo() Linux ile ilgili bir şey değil, sadece bir glibc fonksiyonu
      İnsanlar glibc’nin Linux kullanıcı alanında standart yöntem olduğunu varsayıyor, ama böyle olmak zorunda değil
      Örneğin systemd kendi resolved mekanizmasını yaptı ve glibc tarafındakinden çok daha iyi olduğu ortaya çıktı
      Ben de Linux’u hedefleyen bağımsız yazılımlar geliştirdiğim için bir gün benzer bir şeyi kendim yapmam oldukça olası
    • OpenBSD’de en azından getaddrinfo/gethostbyname gibi geleneksel, standart DNS fonksiyonlarının hepsi Eric Faurot’nun yazdığı OpenBSD libc asr uygulaması için sarmalayıcıdır
      https://man.openbsd.org/man3/asr_run.3
      https://github.com/openbsd/src/tree/master/lib/libc/asr
    • Bu durumun tam olarak böyle olup olmadığını bilmiyorum, ama aynı isimli sistem fonksiyonlarının bile *Linux/BSD/macOS arasında iç uygulamaları ciddi biçimde farklı olabilir
      *BSD’ler arasında da farklar var
      Bazı sistemlerde bir fonksiyon çağrısı yıllarca korunup “doğru yol” olabilirken, başka sistemlerde gerçekten eskimiş ve kullanışsız olabilir

  • Burada ele alınan sorunun macOS genelinde bir sorun değil, yalnızca Little Snitch 6.1 için geçerli olduğu ortaya çıktı ve bugün ilerleyen saatlerde bir Little Snitch güncellemesiyle düzeltilmesi bekleniyor

    • Başlık da bunu yansıtacak şekilde güncellenebilirse iyi olur

  • Ek inceleme sonucunda bu hatanın en az macOS 14.5 Sonoma’dan beri zaten var olduğu anlaşıldı
    Belki daha da eskiden beri vardı, ama şu anda test edilebilecek daha eski bir 14.x sisteme erişimleri olmadığı söyleniyor

    • getaddrinfo’da gerçekten çalışıp çalışmadığını hiç test etmişler mi merak ediyorum
      Yoksa CFNetwork’te bir kez çalıştığını görüp bırakmışlar, sonra da bozuldu diye blog yazısı mı yayımlamışlar, emin değilim
    • Geliştiricilerin test için eski OS sürümlerini ayrıca saklamak zorunda kalması hâlâ mantıklı değil
      Apple’ın downgrade’e izin verememesinin teknik bir nedeni neredeyse yok
    • Ürünün satışta olduğu ve yeni OS’nin dün çıktığı düşünülürse, bu da epey tuhaf

  • Sequoia, macOS güvenlik duvarı açıkken ve bir uygulama “gelen bağlantıları engelle” olarak kayıtlıysa, o uygulamanın DNS kullanma yeteneğini, muhtemelen UDP tabanlı işlevlerin genelini de bozuyor
    https://waclaw.blog/macos-firewall-blocking-web-browsing-aft...

    • Yeniden üretemiyorum. Bazıları bunun ESET ile ilgili olduğunu söylüyor: https://www.reddit.com/r/MacOS/comments/1fievr5/updating_mad...
    • Sequoia’dan önce VPN’de OpenDNS kullansam bile VPN’e bağlıyken iMessage ve diğer uygulamalar çalışmaya devam ediyordu; Sequoia’dan sonra ise VPN bağlıyken iMessage mesajları vb. artık çalışmıyor
      VPN’i kapatınca hepsi geçiyor
      Bununla ilgili mi merak ediyorum. macOS güvenlik duvarı açık, ama tüm gelen bağlantılar engelli değil
    • Sequoia’ya yükselttikten sonra Safari ya da Mozilla ile gezinemiyordum
      Wi‑Fi bağlantısının DNS ayarlarına girip Google DNS sunucuları olan 8.8.8.8 ve 8.8.4.4’ü ekleyince düzeldi; daha önce otomatik girilmiş DNS sunucularının yerini aldı
    • Açıkçası bu davranışı makul buluyorum. Bir uygulama, ayarlarda belirtilenin dışında kendi başına DNS çözümlememeli
      Uygulamaların bunu yapmasının nedeni, kullanıcıların telemetri gibi şeyleri engelleyememesini sağlamak
      Bu benim bilgisayarım; dışarı neyin çıkacağı konusunda son karar bende olmalı

  • Başlık bunun kasıtlı olduğu ya da Apple’a ayrıcalıklı biçimde uygulandığı izlenimini veriyor, ama gerçekte daha çok sıradan bir hata gibi görünüyor
    Böyle bir şeyi bildirdiklerini söylerken FB numarasını ve bildirim ayrıntılarını da paylaşmaları iyi olurdu

    • Şeytanın avukatı açısından bakınca, tepki çekmemek için bunu bilerek böyle yapıp düzeltilmeyen bir hata gibi göstermiş de olabilirler
      Hedefe ulaşıldığı sürece uygulama yöntemi son derece esnek olabilir
    • Kasıtlı olsaydı muhtemelen hardcode edilmiş ve şifrelenmiş bir URL olurdu
      Bazı cihazlar reklam engellemeyi aşmak için zaten bu yöntemi kullanmaya başladı

  • Yanılıyor olabilirim ama iOS ya da Mac’in her yeni sürümünde DNS sorunları çıkıp Little Snitch, Mullvad gibi şeyleri etkiliyormuş gibi bir déjà vu var
    Doğruysa Apple’ın aylar süren geliştirici ve beta testleri boyunca ne yaptığını gerçekten merak ediyorum

  • Little Snitch’ten söz edilmesi kafamı karıştırmıştı; biraz daha okuyunca bunun yalnızca belirli durumlarda çalışan bir LS hatası gibi göründüğünü fark ettim
    Bu LS bloguysa, tek sorum bunun neden macOS hatası gibi anlatıldığı
    Yanlış olduklarını söylemiyorum; bu onların alanı, benim değil, ama metin tek başına bunu pek haklı çıkarmıyor gibi

    • OS DNS proxy kaydına izin verip bazı çağrılar o proxy’yi atlıyorsa, bu açıkça bir OS hatasıdır

  • Apple’ın üçüncü taraf geliştiriciler için belirli bir ağ APIsinin kullanımını kullanımdan kaldırdığını hatırlıyorum
    Ama Apple’ın kendi uygulamaları, örneğin App Store, aynı sınırlamaya tabi değil
    Bu yüzden yeni API ile bir uygulama güvenlik duvarı üzerinden ağ trafiğini filtrelemeye çalışınca, App Store eski API’yi kullandığı için başarısız oluyordu
    Bu, eskiden düzeltildiğini sandığım eski bir hatanın parçası olabilir

    • getaddrinfo() eski bir API değil; DNS sorguları için standart, çapraz platform APIdir

  • “Yeni OS sürümünde hata bulundu! Düzeltme: Aslında epey uzun süredir var olan bir hataymış!” türü duyurular her zaman eğlenceli oluyor

  • Yerel stub çözümleyici olarak routedns [0] kullanıp hangi isteklerin nereye gönderileceğini ve hangi aktarım yönteminin kullanılacağını kendim seçiyorum
    Engelleme listeleri, yeniden yazma, önbellek, yük dengeleme ve alternatif istek işleme de mümkün olduğundan epey kontrol sağlıyor
    Yerel istekler için localhost:53 üzerindeki stub listener’ı kullanıyorum; isteklerin çoğunu da önbellekle birlikte UDP QUIC, yani TLS 0-RTT üzerinden Cloudflare 1.1.1.1’e iletiyorum
    Hızlı ve oldukça güvenli
    [0] https://github.com/folbricht/routedns
 
nearfall 2024-09-18

Önemli bilgi için teşekkürler.
En azından Safari ve Chrome’un güvende olabileceği söyleniyor, bu da sevindirici.