บั๊กใน macOS 14 Sonoma ทำให้แอป Mullvad VPN ใช้งานไม่ได้

 (mullvad.net)
1 คะแนน โดย GN⁺ 2023-09-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ใน macOS 14 Sonoma เวอร์ชันเบตาและ release candidate ไฟร์วอลล์ PF ไม่สามารถกรองทราฟฟิกได้อย่างถูกต้อง ทำให้แอป Mullvad VPN ทำงานได้ไม่ปกติ
  • หากเปิดการตั้งค่าบางอย่าง เช่น การแชร์เครือข่ายภายในเครื่อง อาจทำให้เกิดการรั่วไหลของทราฟฟิกได้ ดังนั้น Mullvad จึงมองว่ายากที่จะรับประกันทั้งฟังก์ชันการทำงานและความปลอดภัยบน macOS 14
  • Mullvad ได้ตรวจสอบปัญหานี้หลังจากเบตาตัวที่ 6 และรายงานให้ Apple ทราบแล้ว แต่บั๊กยังคงอยู่ในเบตาหลังจากนั้นและใน release candidate
  • บริษัทได้พิจารณาว่าสามารถหลบเลี่ยงด้วยแพตช์ในตัวแอปเองได้หรือไม่ แต่ยังไม่พบวิธีแก้ที่ปลอดภัย และโดยพื้นฐานแล้วจำเป็นต้องมี การแก้ไขไฟร์วอลล์จาก Apple
  • ผู้ใช้ที่พึ่งพาการกรองของ PF หรือแอปที่เกี่ยวข้องควรระวังการอัปเกรดเป็น macOS 14 และหากบั๊กยังไม่ถูกแก้ การอยู่ต่อบน macOS 13 Ventura จะปลอดภัยกว่า

ปัญหาไฟร์วอลล์ PF ใน macOS 14 Sonoma

  • ระหว่างช่วงเบตาของ macOS 14 Sonoma นั้น Apple ได้ใส่บั๊กเข้ามาใน packet filter (PF) ซึ่งเป็นไฟร์วอลล์ของ macOS
  • บั๊กนี้ทำให้แอป Mullvad VPN ใช้งานไม่ได้ และเมื่อเปิดการตั้งค่าบางอย่างอาจเกิด การรั่วไหล ของทราฟฟิกได้
    • มีการยกตัวอย่างการตั้งค่าอย่างการแชร์เครือข่ายภายในเครื่อง
  • Mullvad เริ่มตรวจสอบปัญหานี้หลังจาก macOS 14 เบตาตัวที่ 6 ออกมา และได้รายงานบั๊กให้ Apple ทราบ
  • หลังจากนั้นปัญหาเดียวกันนี้ยังคงอยู่ใน macOS 14 เบตาและ release candidate
  • บริษัทประเมินแนวทางการแพตช์เฉพาะแอป VPN เพื่อให้ยังคงทั้งการทำงานและความปลอดภัยบน macOS 14 แต่ตัดสินใจว่าในตอนนี้ยังไม่มีทางออกที่ดี
  • ขอบเขตผลกระทบไม่ได้จำกัดอยู่แค่แอป Mullvad VPN เท่านั้น
    • กฎไฟร์วอลล์ไม่ถูกนำไปใช้กับทราฟฟิกเครือข่ายอย่างถูกต้อง
    • ทราฟฟิกที่ไม่ควรได้รับอนุญาตอาจผ่านออกไปได้
    • ผู้ใช้ที่พึ่งพาการกรองของ PF หรือแอปที่ใช้งานมันอยู่เบื้องหลังควรระวังการอัปเกรดเป็น macOS 14
  • macOS 14 Sonoma มีกำหนดออกในวันที่ 26 กันยายน และหากบั๊กยังคงอยู่ แนะนำให้ผู้ใช้ Mullvad อยู่ต่อบน macOS 13 Ventura จนกว่าจะมีการแก้ไข

ขั้นตอนการทดสอบซ้ำและผลลัพธ์จริง

  • สามารถทดสอบให้เกิดปัญหานี้ซ้ำได้บน macOS 14 และการทดลองนี้จะลบกฎไฟร์วอลล์ที่โหลดอยู่ใน PF
  • ในเทอร์มินัล ให้สร้าง virtual logging interface และเฝ้าดูทราฟฟิกที่ตรงกับกฎที่จะเพิ่มในภายหลัง
sudo ifconfig pflog1 create
sudo tcpdump -nnn -e -ttt -i pflog1
  • เขียนกฎไฟร์วอลล์ต่อไปนี้ลงในไฟล์ pfrules
pass quick log (all, to pflog1) inet from any to 127.0.0.1
block drop quick log (all, to pflog1)
  • ในอีกเทอร์มินัลหนึ่ง ให้เปิดใช้งาน PF และโหลดกฎ
sudo pfctl -e
sudo pfctl -f pfrules
  • ส่ง ping ไปยังเว็บเซิร์ฟเวอร์ของ mullvad.net
ping 45.83.223.209
  • ผลลัพธ์ที่คาดหวังคือ ping จะไม่ตรงกับเงื่อนไขของกฎ pass เพียงข้อเดียว จึงควรถูกบล็อก และทราฟฟิกควรถูกบันทึกใน pflog1 ว่าตรงกับกฎ block
  • แต่ผลที่เกิดขึ้นจริงคือ ping ออกสู่อินเทอร์เน็ตได้และมีการตอบกลับกลับมา โดยไม่มีการบันทึกทราฟฟิกไว้ใน pflog1
  • หลังการทดลอง ให้ปิดใช้งานไฟร์วอลล์และลบกฎทั้งหมด
sudo pfctl -d
sudo pfctl -f /etc/pf.conf

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-09-14
ความคิดเห็นจาก Hacker News

  • บั๊ก PF เดียวกันนี้กำลังทำให้ฟีเจอร์เครือข่ายอย่างหนึ่งของ OrbStack พังอยู่ด้วย
    ตอนที่ไล่สาเหตุมาถึงตรงนี้แทบไม่น่าเชื่อ แต่ดูเหมือนจะไม่ใช่แค่ผมคนเดียวที่เจอ หวังอย่างยิ่งว่าจะถูกแก้ก่อนออกรุ่นเสถียร
    ผมเพิ่งรายงานไปยัง Apple ได้เมื่อวานนี้เอง ดูเหมือนเป็น regression ที่ค่อนข้างใหม่ และน่าจะเริ่มเกิดราว ๆ beta 6
    โดยปกติ PF ควรเป็นไฟร์วอลล์ที่ใช้กฎตัวสุดท้ายที่ match แต่ macOS ดูเหมือนจะทำงานเกือบเหมือนใช้กฎตัวแรกที่ match กฎ block ที่อยู่ด้านหน้าทับกฎ pass ใน anchor อื่นแม้ไม่มี quick จึงเกิดปัญหาขึ้นอย่างหลีกเลี่ยงไม่ได้

    • แค่ “หวังอย่างยิ่ง” ยังไม่พอ เรื่องนี้ต้องถูกแก้ก่อนปล่อยจริง
      ถ้ารุ่นเสถียรออกมาในสภาพนี้ ถือว่ายอมรับไม่ได้ และสำหรับผมเป็นเหตุผลให้ เลิกใช้ Mac OS ได้เลย ถ้าอยากให้คนใช้ทำงานจริงจัง ก็ไม่ควรปล่อยผลิตภัณฑ์ที่มี regression แบบนี้ออกมา

  • บทความกระชับและมีประโยชน์มาก แถมมี ขั้นตอนทำซ้ำบั๊ก ที่เรียบง่ายด้วย ชอบมาก
    ผมชอบ Mullvad
    นอกเรื่องนิดหนึ่ง แต่ macOS มีบั๊กไฟร์วอลล์แปลก ๆ โดยรวมเยอะในช่วงหลายรุ่นหลัง ๆ และสงสัยว่าทำไมถึงต้องรื้อแล้วเขียนส่วนไฟร์วอลล์ใหม่

    • การเขียนใหม่น่าจะได้รับผลชัดเจนจากการย้ายแบบบังคับจาก kernel extension ไปเป็น System Extensions ใน user space โดยเฉพาะ NetworkExtension ตอนเปลี่ยนจาก Catalina ไป Big Sur: https://developer.apple.com/documentation/networkextension
    • ถ้ากังวลเรื่องบั๊กแบบนี้ของแพลตฟอร์มระบบปฏิบัติการในเครื่อง อาจพิจารณาใช้ remote browser เพื่อ abstract จุดเชื่อมต่อในเครื่อง
      ไม่ว่าเครื่องและระบบปฏิบัติการในเครื่องจะเป็นอะไร ก็สามารถให้การท่องเว็บวิ่งผ่านเซิร์ฟเวอร์เฉพาะได้ แม้จะไม่ได้ครอบการเชื่อมต่อเครือข่ายทั้งหมด ครอบเฉพาะการท่องเว็บ แต่ภายในขอบเขตนั้นจะช่วยเปลี่ยน IP address ซ่อนตำแหน่ง และเพิ่มการป้องกันจาก browser zero-day
      BrowserBox กำลังเพิ่มฟีเจอร์ที่เคารพและปกป้องความเป็นส่วนตัว พร้อมปรับปรุงประสบการณ์โดยรวมอย่างต่อเนื่อง เป็นโอเพนซอร์สจึงปรับได้ตามต้องการ ถ้าไม่ชอบ AGPL-3.0 ก็มีไลเซนส์เชิงพาณิชย์: https://github.com/dosyago/BrowserBoxPro
      ถ้าไม่ชอบโอเพนซอร์สและชอบความสบายใจจากบริษัทใหญ่ ดูเหมือน Mullvad ก็มี Mullvad Browser ที่ทำงานคล้ายกัน
    • ถ้ามี หมายเลข rdar/Feedback ใส่มาด้วยก็คงดีกว่านี้
    • macOS พยายามพัฒนา networking stack มาหลายปี แต่เมื่อเกิด regression ก็มักย้อนกลับไป
      บทความเก่าที่เกี่ยวข้อง: https://9to5mac.com/2015/05/26/apple-drops-discoveryd-in-lat...

  • โค้ดสำหรับทำซ้ำ นี้ดูดีมากจริง ๆ

    • นอกจากจะเรียบง่ายแล้ว สิ่งที่ชอบเป็นพิเศษคือมี ขั้นตอน cleanup รวมมาด้วย ซึ่งเป็นสิ่งที่มักขาดไปในขั้นตอนทำซ้ำแบบนี้
    • ผมรู้สึกเหมือนมันก็แค่ตั้งกฎไฟร์วอลล์ง่าย ๆ แล้วลองส่ง query ที่ละเมิดกฎนั้น
      แน่นอนว่านั่นคือขอบเขตของบั๊ก แต่ผมไม่ได้มองว่าการตรวจสอบนี้ซับซ้อนหรือสวยงามเป็นพิเศษ

  • ไม่แน่ใจว่าเกี่ยวข้องไหม แต่หลัง อัปเกรด macOS สองครั้งล่าสุด เครือข่ายใช้งานไม่ได้
    เชื่อมต่อ Wi‑Fi, Ethernet และ hotspot ได้ แต่การเชื่อมต่อจริงอย่าง browser หรือ ping ใช้ไม่ได้เลย และเข้าถึง router ไม่ได้ด้วย
    ทั้งสองครั้ง แค่เปิดแอป Mullvad VPN หนึ่งครั้ง ทุกอย่างก็กลับมาใช้งานได้ ไม่รู้เหมือนกันว่าทำไมแค่เปิดแอปถึงแก้ปัญหาได้

    • แอป VPN เปลี่ยน routing table ดังนั้นก่อนเปิดแอป VPN traffic น่าจะถูก route ไปยัง interface ที่ไม่มีอยู่

  • ไม่ได้เกี่ยวข้องโดยตรงทั้งหมด แต่มีบั๊กเก่าอีกตัวหนึ่ง: บั๊กอายุ 11 ปีของ Popen() บน macOS: https://news.ycombinator.com/item?id=37238433

    • ถ้าเป็นบั๊กของตัวเอง ก็ควรส่ง Feedback พร้อม patch ด้วย ฝั่งโปรเจกต์โอเพนซอร์สมักไม่รับ PR

  • เผื่อเป็นข้อมูล ผมมีปัญหาการเชื่อมต่อกับ Mullvad.app แต่ถ้าใช้การตั้งค่า Mullvad WireGuard ใน Wireguard.app ก็ทำงานได้ดี

  • ผมเพิ่งติดตั้ง Sonoma beta ล่าสุดเมื่อไม่นานนี้ แล้วก็เข้าใจแล้วว่าทำไมพยายามแค่ไหนก็ทำให้ Mullvad ทำงานไม่ได้
    ดีใจที่ Mullvad กำลังทำ workaround อยู่ เมื่อเช้านี้ยังคิดจะ downgrade กลับไป Ventura อยู่เลย ตอนนี้รู้สึกว่าเจอปัญหาถูกจุดแล้ว

    • ในบทความไม่ได้เขียนว่ากำลังทำ workaround อยู่ แต่บอกให้ผู้ใช้ อย่าอัปเกรดเป็น Sonoma จนกว่า Apple จะแก้บั๊ก
    • ชุด tailscale/mullvad น่าจะยังทำงานได้อยู่ อาจเป็น workaround ที่พอใช้ได้จนกว่า Apple จะแก้

  • ดีใจที่ Mullvad ช่วยเพิ่ม แรงกดดันสาธารณะ ต่อปัญหานี้ บั๊กนี้เห็นได้ชัดและน่ากังวลพอสมควร

    • เรื่องนี้เป็นที่รู้กันที่อื่นแล้วหรือยัง? ดูเหมือน Mullvad รายงานหลัง beta ตัวที่ 6 และจุดนั้นก็ค่อนข้างใกล้ RC แล้ว
      ในต้นฉบับเขียนว่า “we have investigated this issue after the 6th beta was released and reported the bug to Apple”

  • กรณีของผม วิธีแก้คือดาวน์โหลด การตั้งค่า WireGuard แล้วใช้แอป Wireguard

    • แต่แอป Wireguard จะทำให้ข้อมูลรั่ว และปลอดภัยน้อยกว่าแอป Mullvad หรือเปล่า?
    • จะเป็นวิธีแก้เฉพาะในกรณีที่ไม่ได้ใส่กฎไฟร์วอลล์ PostUp และ PostDown ในการตั้งค่า WireGuard เท่านั้น ถ้าอย่างนั้นก็เรียกว่าวิธีแก้ได้ยาก

  • คำถาม: ถ้า pflog1 ไม่ถูกสร้างขึ้น pf จะทำงานตามที่คาดหรือไม่?
    ถ้า tcpdump ไม่บันทึกอะไรที่ออกไปทาง pflog1 เลย ก็ดูเหมือนหมายความว่าข้อมูลไม่ได้ถูกส่งไปยัง pflog1 ดังนั้นน่าจะเป็นปัญหาก่อนถึงจุดนั้น
    pflog1 ถูกเชื่อมต่อและอยู่ในสถานะ up หรือเปล่า? สมัยก่อนต้องเชื่อมต่อ interface และสั่งให้ up เอง MacOS ทำให้โดยอัตโนมัติหรือไม่?
    แน่นอนว่าการแยกประเด็นนี้ไม่ใช่หน้าที่ของคนรายงานบั๊ก แต่สักจุดหนึ่ง engineer ที่รับผิดชอบคงถามคำถามแบบนี้ ดังนั้นตอบไว้ล่วงหน้าจะดีกว่า

    • มีอะไรที่เพิ่มเข้าไปในขั้นตอนทำซ้ำเป็น workaround ได้ไหม? เช่นอย่างที่พูดไว้ คือหลัง โหลด pfrules แล้ว ค่อยเชื่อมต่อ interface และสั่งให้ up
    • หลังจากนั้น ถ้าจะลบ interface เพิ่มเติม ก็ต้องทำสิ่งนี้ด้วย:
      ifconfig pflog1 destroy