macOS 14 Sonoma बग के कारण Mullvad VPN ऐप का काम करना बंद

 (mullvad.net)
1 पॉइंट द्वारा GN⁺ 2023-09-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • macOS 14 Sonoma beta और release candidate में PF firewall traffic को ठीक से filter नहीं कर पा रहा है, जिससे Mullvad VPN ऐप सामान्य रूप से काम नहीं कर रहा
  • local network sharing जैसी कुछ settings enabled होने पर traffic leak हो सकता है, इसलिए Mullvad का मानना है कि macOS 14 पर functionality और security की गारंटी देना मुश्किल है
  • Mullvad ने छठे beta के बाद issue की जांच कर Apple को report किया, लेकिन बाद के beta और release candidate में भी bug बना हुआ है
  • ऐप में patch लगाकर workaround संभव है या नहीं, इसकी समीक्षा की गई, लेकिन सुरक्षित समाधान नहीं मिला; मूल रूप से Apple के firewall fix की जरूरत है
  • PF filtering पर निर्भर users या संबंधित apps को macOS 14 upgrade करते समय सावधानी बरतनी चाहिए, और अगर bug मौजूद रहे तो macOS 13 Ventura पर रहना सुरक्षित है

macOS 14 Sonoma में PF firewall की समस्या

  • macOS 14 Sonoma beta अवधि के दौरान Apple ने macOS firewall, यानी packet filter(PF) में एक bug introduce किया
  • इस bug के कारण Mullvad VPN ऐप काम नहीं करता, और कुछ settings enabled होने पर traffic leak हो सकता है
    • उदाहरण setting के रूप में local network sharing का उल्लेख किया गया है
  • Mullvad ने छठे macOS 14 beta के बाद समस्या की जांच की और Apple को bug report किया
  • इसके बाद के macOS 14 beta और release candidate में भी वही समस्या बनी रही
  • उन्होंने यह आंका कि सिर्फ VPN ऐप को patch करके macOS 14 पर operation और security दोनों बनाए रखे जा सकते हैं या नहीं, लेकिन फिलहाल कोई अच्छा समाधान नहीं है
  • असर सिर्फ Mullvad VPN ऐप तक सीमित नहीं है
    • firewall rules network traffic पर ठीक से लागू नहीं हो रहे
    • ऐसा traffic भी pass हो सकता है जिसे allow नहीं होना चाहिए
    • PF filtering पर निर्भर users या background में इसका इस्तेमाल करने वाले apps को macOS 14 upgrade करते समय सावधान रहना चाहिए
  • macOS 14 Sonoma 26 सितंबर को release होने वाला है, और अगर bug बना रहता है तो Mullvad users को fix आने तक macOS 13 Ventura पर बने रहने की सलाह दी जाती है

पुनरुत्पादन प्रक्रिया और वास्तविक परिणाम

  • macOS 14 पर समस्या reproduce की जा सकती है, और यह प्रयोग PF में loaded firewall rules को clear कर देता है
  • Terminal में virtual logging interface बनाएं, और बाद में जोड़े जाने वाले rule से match होने वाले traffic को monitor करें
sudo ifconfig pflog1 create
sudo tcpdump -nnn -e -ttt -i pflog1
  • pfrules file में निम्न firewall rules लिखें
pass quick log (all, to pflog1) inet from any to 127.0.0.1
block drop quick log (all, to pflog1)
  • दूसरे Terminal में PF को enable करें और rules load करें
sudo pfctl -e
sudo pfctl -f pfrules

ping 45.83.223.209
  • अपेक्षित परिणाम यह है कि ping इकलौते pass rule की condition से match नहीं होगा, इसलिए block हो जाएगा, और traffic pflog1 में block rule से match के रूप में recorded होगा
  • वास्तविकता में ping internet पर चला जाता है और response वापस आता है, और pflog1 में traffic recorded नहीं होता
  • प्रयोग के बाद firewall को disable करें और सभी rules clear करें
sudo pfctl -d
sudo pfctl -f /etc/pf.conf

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-09-14
Hacker News की राय

  • वही PF bug OrbStack की एक networking feature को भी तोड़ रहा है
    जब वजह को यहाँ तक narrow down किया तो यकीन करना मुश्किल था, लेकिन लगता है मैं अकेला नहीं हूँ। उम्मीद है stable version रिलीज़ होने से पहले यह ज़रूर ठीक हो जाएगा
    कल ही इसे Apple को report कर पाया, और यह काफी recent regression लगता है, शायद beta 6 के आसपास आया होगा
    PF तो असल में ऐसा firewall होना चाहिए जहाँ आख़िरी matching rule लागू होता है, लेकिन macOS लगभग पहले matching rule जैसा behave कर रहा है। आगे वाला block rule, quick के बिना भी, दूसरे anchors के pass rules को override कर रहा है, इसलिए दिक्कत होना तय है

    • “सच में उम्मीद है” कहना काफी नहीं है। इसे रिलीज़ से पहले हर हाल में ठीक होना चाहिए
      अगर stable version ऐसी हालत में आता है तो यह स्वीकार्य नहीं होगा, और निजी तौर पर मेरे लिए यह Mac OS छोड़ने की वजह बन जाएगा। अगर वे चाहते हैं कि इसे serious काम में इस्तेमाल किया जाए, तो ऐसे regression वाला product release नहीं करना चाहिए

  • लेख बहुत concise और उपयोगी है, और इसमें bug reproduce करने के steps भी आसान तरीके से दिए गए हैं, यह अच्छा है
    Mullvad मुझे पसंद है
    थोड़ा off-topic, लेकिन macOS में पिछले कुछ releases से कुल मिलाकर अजीब firewall bugs काफी रहे हैं, और सोचता हूँ कि firewall side को फिर से लिखने की ज़रूरत क्यों पड़ी

    • Catalina से Big Sur में जाते समय rewrite पर kernel extensions से user-space System Extensions, खासकर NetworkExtension, पर जबरन migration का असर ज़रूर रहा होगा: https://developer.apple.com/documentation/networkextension
    • अगर local operating system platform के ऐसे bugs चिंता में डालते हैं, तो local access point को abstract करने के लिए remote browser का तरीका भी consider कर सकते हैं
      local machine और operating system कुछ भी हो, browsing को dedicated server के ज़रिए चला सकते हैं। यह पूरे network connection को wrap नहीं करता, सिर्फ browsing पर लागू होता है, लेकिन उस दायरे में IP address बदलता है, location छिपाता है और browser zero-days से अतिरिक्त protection देता है
      BrowserBox में privacy का सम्मान और सुरक्षा करने, और पूरे experience को बेहतर बनाने वाली features लगातार जोड़ी जा रही हैं। यह open source है, इसलिए आप इसे अपनी पसंद से बदल भी सकते हैं। अगर AGPL-3.0 पसंद नहीं है तो commercial license भी उपलब्ध है: https://github.com/dosyago/BrowserBoxPro
      अगर open source पसंद नहीं है और बड़ी company की comfort चाहते हैं, तो लगता है Mullvad के पास भी Mullvad Browser है जो मिलता-जुलता काम करता है
    • rdar/Feedback number भी शामिल होता तो और अच्छा होता
    • macOS ने कई सालों तक networking stack को evolve करने की कोशिश की, लेकिन regression आने पर अक्सर वापस पलट जाता था
      इससे जुड़ा एक पुराना लेख: https://9to5mac.com/2015/05/26/apple-drops-discoveryd-in-lat...

  • यह reproduction code सच में देखने में अच्छा है

    • simple होना तो अच्छा है ही, लेकिन खास तौर पर इसमें cleanup step भी शामिल है। ऐसी reproduction procedures में यह चीज़ अक्सर छूट जाती है
    • मुझे तो लगता है यह बस एक simple firewall rule set करता है और फिर उस rule को violate करने वाली query try करता है
      बेशक bug का scope यही है, लेकिन यह test मुझे खास refined या खूबसूरत नहीं लगता

  • पता नहीं related है या नहीं, लेकिन हाल की दो macOS upgrades के तुरंत बाद networking काम नहीं कर रही थी
    Wi‑Fi, Ethernet और hotspot से connect हो पा रहा था, लेकिन browser या ping जैसे actual connections कुछ भी नहीं चल रहे थे, और router तक भी नहीं पहुँच पा रहा था
    दोनों बार Mullvad VPN app को सिर्फ एक बार open करने से सब फिर से काम करने लगा। सिर्फ app खोलने से समस्या कैसे ठीक हुई, पता नहीं

    • VPN app routing table बदलता है, इसलिए लगता है VPN app चलाने से पहले traffic किसी non-existent interface की ओर route हो रहा था

  • पूरी तरह related नहीं है, लेकिन एक और पुराना bug भी है: macOS Popen() का 11 साल पुराना bug: https://news.ycombinator.com/item?id=37238433

    • अगर यह आपका bug है तो patch के साथ Feedback भी भेजना अच्छा होगा। open source project आम तौर पर PR accept नहीं करता

  • संदर्भ के लिए, Mullvad.app से connection problem थी, लेकिन Wireguard.app में Mullvad WireGuard config चलाने पर सब ठीक काम करता था

  • हाल ही में latest Sonoma beta install किया था और Mullvad को किसी भी तरह काम नहीं करा पा रहा था, अब समझ आया
    अच्छा है कि Mullvad workaround पर काम कर रहा है। आज सुबह Ventura पर downgrade करने का भी सोच रहा था, अब लगता है सच में यही मेरी problem थी

    • इसमें यह नहीं लिखा कि वे workaround पर काम कर रहे हैं। लिखा है कि जब तक Apple bug ठीक नहीं करता, users को Sonoma में upgrade नहीं करना चाहिए
    • tailscale/mullvad combo शायद अभी भी काम करेगा। Apple के fix करने तक यह ठीक-ठाक workaround हो सकता है

  • अच्छा लगा कि Mullvad ने इस मुद्दे पर public pressure बढ़ाया। यह bug निश्चित रूप से noticeable था और काफी worrying भी

    • क्या यह पहले से कहीं और known था? लगता है Mullvad ने 6th beta के बाद report किया, और उस समय तक RC के काफी करीब होता है
      original में लिखा है “we have investigated this issue after the 6th beta was released and reported the bug to Apple”

  • मेरे case में WireGuard config download करके Wireguard app इस्तेमाल करना solution था

    • लेकिन क्या Wireguard app data leak कराता है, और Mullvad app से कम secure नहीं है?
    • यह तभी solution है जब WireGuard config में PostUp और PostDown firewall rules न डालें। तब इसे solution कहना मुश्किल है

  • सवाल: अगर pflog1 create नहीं होता, तो क्या pf expected तरीके से काम करता है?
    अगर tcpdump, pflog1 पर जाने वाली कोई चीज़ record नहीं करता, तो इसका मतलब लगता है कि data pflog1 को भेजा ही नहीं जा रहा। फिर problem उससे पहले की layer में है
    क्या pflog1 connected और up state में था? पहले interface को manually connect और up करना पड़ता था। क्या MacOS यह automatically करता है?
    बेशक इसे isolate करना bug reporter का काम नहीं है। लेकिन किसी point पर responsible engineer ऐसे सवाल पूछेगा, इसलिए पहले से जवाब रखना बेहतर है

    • क्या reproduction steps में workaround के रूप में कुछ जोड़ा जा सकता है? जैसे आपने कहा, pfrules load करने के बाद interface को connect और up करना
    • बाद में extra interface हटाने के लिए यह भी करना होगा:
      ifconfig pflog1 destroy