macOS 14 Sonoma hatası Mullvad VPN uygulamasının çalışmasını engelliyor

 (mullvad.net)
1 puan yazan GN⁺ 2023-09-14 | 1 yorum | WhatsApp'ta paylaş
  • macOS 14 Sonoma beta ve sürüm adayı sürümlerinde PF güvenlik duvarı trafiği doğru şekilde filtreleyemediği için Mullvad VPN uygulaması normal çalışmıyor
  • Yerel ağ paylaşımı gibi bazı ayarlar açık olduğunda bu durum trafik sızıntısına yol açabilir; bu nedenle Mullvad, macOS 14’te işlevselliği ve güvenliği garanti etmenin zor olduğunu düşünüyor
  • Mullvad, 6. betadan sonra sorunu araştırıp Apple’a bildirdi ancak hata sonraki beta sürümlerde ve sürüm adayında da devam ediyor
  • Uygulama içinde bir yamayla bunun etrafından dolaşmanın mümkün olup olmadığını değerlendirdi ancak güvenli bir çözüm bulamadı; temelde Apple’ın güvenlik duvarını düzeltmesi gerekiyor
  • PF filtrelemeye bağımlı kullanıcılar veya ilgili uygulamalar macOS 14 yükseltmesi konusunda dikkatli olmalı; hata devam ediyorsa macOS 13 Ventura’da kalmak daha güvenli

macOS 14 Sonoma’daki PF güvenlik duvarı sorunu

  • macOS 14 Sonoma beta sürecinde Apple, macOS güvenlik duvarı olan packet filter(PF) içine bir hata ekledi
  • Bu hata nedeniyle Mullvad VPN uygulaması çalışmıyor; belirli ayarlar açık olduğunda trafik sızıntısı yaşanabilir
    • Örnek ayar olarak yerel ağ paylaşımı belirtiliyor
  • Mullvad, 6. macOS 14 betası yayımlandıktan sonra sorunu araştırdı ve Apple’a hata bildirimi yaptı
  • Sonraki macOS 14 betalarında ve sürüm adayında aynı sorun devam ediyor
  • Yalnızca VPN uygulamasını yamalayarak macOS 14’te hem çalışmayı hem de güvenliği korumanın yollarını değerlendirdi ancak şu an için iyi bir çözüm olmadığı sonucuna vardı
  • Etki alanı yalnızca Mullvad VPN uygulamasıyla sınırlı değil
    • Güvenlik duvarı kuralları ağ trafiğine düzgün uygulanmıyor
    • İzin verilmemesi gereken trafik geçebilir
    • PF filtrelemeye bağımlı kullanıcılar veya bunu arka planda kullanan uygulamalar macOS 14 yükseltmesi konusunda dikkatli olmalı
  • macOS 14 Sonoma’nın 26 Eylül’de yayımlanması planlanıyor; hata devam ederse Mullvad kullanıcılarının düzeltme gelene kadar macOS 13 Ventura’da kalması öneriliyor

Yeniden üretme adımları ve gerçek sonuç

  • Sorun macOS 14’te yeniden üretilebilir; bu deney PF’ye yüklenmiş güvenlik duvarı kurallarını siler
  • Terminalde sanal bir günlükleme arayüzü oluşturun ve daha sonra eklenecek kuralla eşleşen trafiği izleyin
sudo ifconfig pflog1 create
sudo tcpdump -nnn -e -ttt -i pflog1
  • pfrules dosyasına aşağıdaki güvenlik duvarı kurallarını yazın
pass quick log (all, to pflog1) inet from any to 127.0.0.1
block drop quick log (all, to pflog1)
  • Başka bir terminalde PF’yi etkinleştirin ve kuralları yükleyin
sudo pfctl -e
sudo pfctl -f pfrules

ping 45.83.223.209
  • Beklenen sonuç, ping’in tek pass kuralının koşuluyla eşleşmediği için engellenmesi ve trafiğin pflog1 içinde block kuralıyla eşleşmiş olarak kaydedilmesidir
  • Gerçekte ise ping internete çıkar ve yanıt geri gelir; pflog1 içinde trafik kaydedilmez
  • Deneyden sonra güvenlik duvarını devre dışı bırakın ve tüm kuralları silin
sudo pfctl -d
sudo pfctl -f /etc/pf.conf

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-14
Hacker News yorumları

  • Aynı PF hatası, OrbStack’in ağ özelliklerinden birini de bozuyor
    Nedeni buraya kadar daralttığımda inanması güçtü, ama görünüşe göre bunu yaşayan yalnızca ben değilim. Kararlı sürüm çıkmadan önce mutlaka düzeltilmesini umuyorum
    Apple’a ancak dün bildirebildim; oldukça yakın tarihli bir regresyon gibi görünüyor ve muhtemelen beta 6 civarında ortaya çıkmış
    PF normalde son eşleşen kuralın uygulandığı bir güvenlik duvarı olmalı, ama macOS neredeyse ilk eşleşen kural gibi davranıyor. Baştaki block kuralı, quick olmadan bile başka bir anchor’daki pass kuralını geçersiz kılıyor; bu da doğal olarak sorun yaratıyor

    • “Gerçekten umuyorum” demek yetmez. Bu, yayınlanmadan önce mutlaka düzeltilmeli
      Kararlı sürüm bu hâliyle çıkarsa kabul edilemez ve benim için kişisel olarak Mac OS’ten vazgeçme nedeni olur. Ciddi işlerde kullanılmasını istiyorlarsa böyle regresyonları olan bir ürün çıkarmamalılar

  • Yazı çok özlü ve bilgilendirici; hatayı yeniden üretme adımları da basitçe yer aldığı için hoşuma gitti
    Mullvad’ı seviyorum
    Yan konu ama macOS’te son birkaç sürümdür genel olarak garip güvenlik duvarı hataları çoktu; güvenlik duvarı tarafını neden baştan yazıp yeniden yapmak zorunda kaldıklarını merak ediyorum

    • Yeniden yazımda, Catalina’dan Big Sur’a geçerken çekirdek uzantılarından kullanıcı alanındaki System Extensions’a, özellikle de NetworkExtension’a zorunlu geçişin kesinlikle etkisi olmuş olmalı: https://developer.apple.com/documentation/networkextension
    • Yerel işletim sistemi platformundaki bu tür hatalar sizi endişelendiriyorsa, yerel erişim noktasını uzak tarayıcı ile soyutlamayı da düşünebilirsiniz
      Yerel makineniz ve işletim sisteminiz ne olursa olsun, gezintiyi özel bir sunucu üzerinden yönlendirebilirsiniz. Bu tüm ağ bağlantısını kapsamaz, yalnızca web gezintisi için geçerlidir; ancak bu kapsamda IP adresini değiştirir, konumu gizler ve tarayıcı zero-day’lerine karşı ek koruma sağlar
      BrowserBox’a gizliliğe saygı duyan, onu koruyan ve genel deneyimi iyileştiren özellikler eklemeye devam ediyoruz. Açık kaynak olduğu için istediğiniz gibi değiştirebilirsiniz. AGPL-3.0 hoşunuza gitmezse ticari lisans da mümkün: https://github.com/dosyago/BrowserBoxPro
      Açık kaynaktan hoşlanmıyor ve büyük bir şirketin rahatlığını tercih ediyorsanız, Mullvad’da da benzer bir iş yapan Mullvad Browser var gibi görünüyor
    • rdar/Feedback numarası da yer alsaydı daha iyi olurdu
    • macOS yıllardır ağ yığınını geliştirmeye çalıştı, ancak regresyonlar ortaya çıkınca geri almaya eğilimli oldu
      İlgili eski bir yazı: https://9to5mac.com/2015/05/26/apple-drops-discoveryd-in-lat...

  • Bu yeniden üretme kodu gerçekten çok iyi görünüyor

    • Basit olması da güzel, ama özellikle temizleme adımının da bulunması hoş. Bu tür yeniden üretme adımlarında sıkça eksik kalan bir unsur
    • Bana sadece basit bir güvenlik duvarı kuralı ayarlayıp, o kuralı ihlal eden bir sorgu denemek gibi geliyor
      Elbette hatanın kapsamı da bu, ama bu test bana özellikle sofistike ya da güzel görünmüyor

  • İlgili mi bilmiyorum ama son iki macOS yükseltmesinden hemen sonra ağ çalışmadı
    Wi‑Fi, Ethernet ve hotspot’a bağlanabiliyordum, ancak tarayıcı veya ping gibi gerçek bağlantıların hiçbiri çalışmıyordu; yönlendiriciye bile erişemiyordum
    İki seferde de Mullvad VPN uygulamasını bir kez açmam her şeyin yeniden çalışması için yeterli oldu. Sadece uygulamayı açmanın sorunu neden düzelttiğini bilmiyorum

    • VPN uygulaması routing tablosunu değiştirdiği için, VPN uygulamasını çalıştırana kadar trafik var olmayan bir arayüze yönlendiriliyor olabilir

  • Tam olarak ilgili değil ama başka eski bir hata daha var: macOS Popen() içinde 11 yıllık bir hata: https://news.ycombinator.com/item?id=37238433

    • Kendi hatanızsa bir yama ile birlikte Feedback de göndermek iyi olur. Açık kaynak proje tarafı genelde PR kabul etmiyor

  • Bu arada Mullvad.app ile bağlantı sorunları yaşadım, ancak Wireguard.app içinde Mullvad WireGuard yapılandırmasını çalıştırınca sorunsuz çalıştı

  • Yakın zamanda en yeni Sonoma beta sürümünü kurmuştum ve Mullvad’ı ne yaptıysam çalıştıramamam şimdi anlam kazandı
    Mullvad’ın bir geçici çözüm üzerinde çalışmasına sevindim. Bu sabah Ventura’ya geri dönmeyi bile düşünüyordum; sorunun bende olmadığı hissi geldi

    • Bir geçici çözüm üzerinde çalıştıkları yazmıyor. Apple hatayı düzeltene kadar kullanıcıların Sonoma’ya yükseltmemesi gerektiği yazıyor
    • tailscale/mullvad kombinasyonu hâlâ çalışacak gibi. Apple düzeltene kadar iyi bir geçici çözüm olabilir

  • Mullvad’ın bu sorun için kamuoyu baskısını artırmasına sevindim. Bu hata kesinlikle göze çarpıyordu ve oldukça endişe vericiydi

    • Bu başka yerlerde zaten biliniyor muydu? Mullvad, 6. beta sonrasında bildirmiş gibi görünüyor; o noktada RC’ye oldukça yakın olunuyor
      Orijinal metinde “we have investigated this issue after the 6th beta was released and reported the bug to Apple” yazıyor

  • Benim için çözüm, WireGuard yapılandırmasını indirip Wireguard uygulamasını kullanmak oldu

    • Ama Wireguard uygulaması veri sızmasına yol açıp Mullvad uygulamasından daha az güvenli olmaz mı?
    • Bu ancak WireGuard yapılandırmasına PostUp ve PostDown güvenlik duvarı kuralları eklenmemişse bir çözüm. Öyle olunca da buna pek çözüm denemez

  • Soru: pflog1 oluşturulmazsa pf beklendiği gibi çalışıyor mu?
    tcpdump, pflog1 üzerinden çıkan hiçbir şeyi kaydetmiyorsa, verinin pflog1e gönderilmediği anlamına geliyor gibi. Bu da sorunun ondan daha önceki bir aşamada olduğu anlamına gelir
    pflog1 bağlı ve up durumda mıydı? Eskiden arayüzü elle bağlayıp up duruma getirmek gerekirdi. MacOS bunu otomatik yapıyor mu?
    Elbette bunu ayrıştırmak hata bildireni kişinin işi değil. Ama bir noktada sorumlu mühendis bu tür sorular soracaktır; bu yüzden yanıtları şimdiden hazırlamak iyi olur

    • Yeniden üretme adımlarına geçici çözüm olarak eklenebilecek bir şey var mı? Örneğin söylediğiniz gibi pfrules yüklendikten sonra arayüzü bağlayıp up duruma getirmek gibi
    • Sonrasında ek arayüzü kaldırmak için bunu da yapmak gerekir:
      ifconfig pflog1 destroy