Lỗi trên macOS 14 Sonoma khiến ứng dụng Mullvad VPN ngừng hoạt động

 (mullvad.net)
1 điểm bởi GN⁺ 2023-09-14 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trên bản beta và bản phát hành ứng viên của macOS 14 Sonoma, tường lửa PF không thể lọc lưu lượng đúng cách, khiến ứng dụng Mullvad VPN không hoạt động bình thường
  • Khi một số thiết lập như chia sẻ mạng cục bộ được bật, điều này có thể dẫn tới rò rỉ lưu lượng, vì vậy Mullvad cho rằng rất khó đảm bảo cả chức năng lẫn bảo mật trên macOS 14
  • Mullvad đã điều tra vấn đề từ sau bản beta thứ 6 và báo cáo cho Apple, nhưng lỗi vẫn còn tồn tại trong các bản beta tiếp theo và cả bản phát hành ứng viên
  • Họ đã xem xét liệu có thể lách qua bằng bản vá cho chính ứng dụng hay không, nhưng không tìm được giải pháp an toàn; về cơ bản cần Apple sửa tường lửa
  • Người dùng phụ thuộc vào bộ lọc PF hoặc các ứng dụng liên quan nên thận trọng khi nâng cấp lên macOS 14; nếu lỗi vẫn còn, ở lại với macOS 13 Ventura sẽ an toàn hơn

Vấn đề với tường lửa PF trên macOS 14 Sonoma

  • Trong giai đoạn beta của macOS 14 Sonoma, Apple đã đưa vào một lỗi trong packet filter (PF), tức tường lửa của macOS
  • Lỗi này khiến ứng dụng Mullvad VPN không hoạt động, và khi một số thiết lập nhất định được bật có thể gây rò rỉ lưu lượng
    • Một ví dụ được nhắc tới là chia sẻ mạng cục bộ
  • Mullvad đã điều tra vấn đề sau khi bản beta macOS 14 thứ 6 được phát hành và đã báo lỗi cho Apple
  • Sau đó, cùng một vấn đề vẫn tiếp tục tồn tại trong các bản beta của macOS 14 và cả bản phát hành ứng viên
  • Họ đã đánh giá phương án chỉ vá ứng dụng VPN để vừa duy trì hoạt động vừa giữ bảo mật trên macOS 14, nhưng hiện tại kết luận là chưa có giải pháp tốt
  • Phạm vi ảnh hưởng không chỉ giới hạn ở ứng dụng Mullvad VPN
    • Các quy tắc tường lửa không được áp dụng đúng với lưu lượng mạng
    • Lưu lượng lẽ ra không được phép có thể vẫn đi qua
    • Người dùng phụ thuộc vào bộ lọc PF hoặc các ứng dụng sử dụng nó ở chế độ nền nên cẩn trọng khi nâng cấp lên macOS 14
  • macOS 14 Sonoma dự kiến phát hành vào ngày 26/9, và nếu lỗi vẫn còn, người dùng Mullvad được khuyến nghị ở lại với macOS 13 Ventura cho tới khi có bản sửa lỗi

Các bước tái hiện và kết quả thực tế

  • Có thể tái hiện vấn đề trên macOS 14, và thử nghiệm này sẽ xóa các quy tắc tường lửa đã được nạp vào PF
  • Trong terminal, tạo một giao diện ghi log ảo và giám sát lưu lượng khớp với các quy tắc sẽ được thêm sau đó
sudo ifconfig pflog1 create
sudo tcpdump -nnn -e -ttt -i pflog1
  • Viết các quy tắc tường lửa sau vào tệp pfrules
pass quick log (all, to pflog1) inet from any to 127.0.0.1
block drop quick log (all, to pflog1)
  • Trong một terminal khác, bật PF và nạp các quy tắc
sudo pfctl -e
sudo pfctl -f pfrules

ping 45.83.223.209
  • Kết quả kỳ vọng là ping không khớp với điều kiện của quy tắc pass duy nhất nên sẽ bị chặn, và lưu lượng sẽ được ghi vào pflog1 là đã khớp với quy tắc block
  • Nhưng trên thực tế, ping vẫn đi ra Internet và nhận được phản hồi, đồng thời không có lưu lượng nào được ghi vào pflog1
  • Sau thử nghiệm, tắt tường lửa và xóa toàn bộ quy tắc
sudo pfctl -d
sudo pfctl -f /etc/pf.conf

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-09-14
Ý kiến trên Hacker News

  • Cùng một lỗi PF cũng đang làm hỏng một chức năng mạng của OrbStack
    Khi thu hẹp nguyên nhân đến mức này thì thật khó tin, nhưng có vẻ không chỉ mình tôi gặp. Mong là nó nhất định được sửa trước khi bản ổn định phát hành
    Mãi đến hôm qua tôi mới có thể báo cáo cho Apple; có vẻ đây là một hồi quy khá gần đây, có lẽ xuất hiện khoảng từ beta 6
    PF vốn phải là tường lửa áp dụng quy tắc khớp cuối cùng, nhưng macOS dường như hoạt động gần giống kiểu quy tắc khớp đầu tiên. Quy tắc block ở phía trước ghi đè quy tắc pass trong anchor khác dù không có quick, nên đương nhiên là gây vấn đề

    • “Thật sự mong vậy” vẫn là chưa đủ. Việc này bắt buộc phải được sửa trước khi phát hành
      Nếu bản ổn định ra mắt trong tình trạng này thì không thể chấp nhận được, và với cá nhân tôi đó sẽ là lý do để từ bỏ Mac OS. Nếu muốn được dùng cho công việc nghiêm túc thì không thể phát hành một sản phẩm có hồi quy như thế này

  • Bài viết rất ngắn gọn, hữu ích, và còn có cả các bước tái hiện lỗi đơn giản, nên tôi rất thích
    Tôi thích Mullvad
    Nói bên lề, trong vài bản phát hành gần đây macOS nói chung có khá nhiều lỗi tường lửa kỳ lạ, và tôi tò mò vì sao họ lại phải đại tu rồi viết lại phần tường lửa

    • Việc viết lại chắc chắn có liên quan đến quá trình chuyển bắt buộc từ kernel extension sang System Extensions ở user space, đặc biệt là NetworkExtension, khi chuyển từ Catalina sang Big Sur: https://developer.apple.com/documentation/networkextension
    • Nếu lo ngại các lỗi kiểu này trên nền tảng hệ điều hành cục bộ, bạn cũng có thể cân nhắc cách trừu tượng hóa điểm truy cập cục bộ bằng trình duyệt từ xa
      Dù máy cục bộ và hệ điều hành là gì, bạn vẫn có thể chạy việc duyệt web thông qua một máy chủ chuyên dụng. Nó không bao toàn bộ kết nối mạng, chỉ phần duyệt web, nhưng trong phạm vi đó nó có thể đổi địa chỉ IP, che giấu vị trí và bổ sung lớp bảo vệ trước các zero-day của trình duyệt
      BrowserBox đang tiếp tục bổ sung các tính năng tôn trọng và bảo vệ quyền riêng tư, đồng thời cải thiện toàn bộ trải nghiệm. Vì là mã nguồn mở nên bạn có thể sửa theo ý muốn. Nếu không thích AGPL-3.0 thì cũng có giấy phép thương mại: https://github.com/dosyago/BrowserBoxPro
      Nếu không thích mã nguồn mở và muốn sự yên tâm từ một công ty lớn, có vẻ Mullvad cũng có Mullvad Browser làm việc tương tự
    • Sẽ còn tốt hơn nếu có cả số rdar/Feedback
    • macOS đã cố phát triển networking stack trong nhiều năm, nhưng mỗi khi có hồi quy lại quay về cách cũ
      Bài viết cũ liên quan: https://9to5mac.com/2015/05/26/apple-drops-discoveryd-in-lat...

  • Mã tái hiện này thật sự rất đẹp

    • Đơn giản đã là tốt, nhưng đặc biệt hay ở chỗ có cả bước dọn dẹp. Đây là thứ thường bị thiếu trong các quy trình tái hiện lỗi như vậy
    • Tôi nghĩ nó chỉ là thiết lập một quy tắc tường lửa đơn giản rồi thử một truy vấn vi phạm quy tắc đó
      Tất nhiên đó đúng là phạm vi của lỗi, nhưng tôi không thấy bài kiểm tra này đặc biệt tinh vi hay đẹp mắt

  • Không biết có liên quan không, nhưng ngay sau hai lần nâng cấp macOS gần đây, mạng đều không hoạt động
    Tôi có thể kết nối Wi‑Fi, Ethernet, hotspot, nhưng không có kết nối thực tế nào như trình duyệt hay ping hoạt động, và cũng không tới được router
    Cả hai lần, chỉ cần mở ứng dụng Mullvad VPN một lần là mọi thứ hoạt động trở lại. Tôi không biết vì sao chỉ việc mở ứng dụng lại khắc phục được vấn đề

    • Ứng dụng VPN thay đổi bảng định tuyến, nên có vẻ trước khi chạy ứng dụng VPN, lưu lượng đang được định tuyến tới một interface không tồn tại

  • Không hoàn toàn liên quan, nhưng còn có một lỗi cũ khác: lỗi 11 năm tuổi của Popen() trên macOS: https://news.ycombinator.com/item?id=37238433

    • Nếu là lỗi của bạn thì nên gửi cả Feedback kèm bản vá. Phía dự án mã nguồn mở thường không nhận PR

  • Để tham khảo, tôi gặp vấn đề kết nối với Mullvad.app, nhưng khi chạy cấu hình Mullvad WireGuard trong Wireguard.app thì hoạt động tốt

  • Gần đây tôi đã cài Sonoma beta mới nhất và giờ thì hiểu vì sao dù làm gì cũng không thể khiến Mullvad hoạt động
    Thật may là Mullvad đang làm phương án vòng tránh. Sáng nay tôi còn nghĩ đến chuyện hạ cấp về Ventura, nhưng giờ thấy đúng là vấn đề của tôi rồi

    • Không thấy viết rằng họ đang làm phương án vòng tránh. Bài nói rằng người dùng không nên nâng cấp lên Sonoma cho đến khi Apple sửa lỗi
    • Tổ hợp tailscale/mullvad có lẽ vẫn hoạt động. Nó cũng có thể là một phương án vòng tránh ổn cho đến khi Apple sửa

  • Rất vui vì Mullvad đã tạo thêm áp lực công khai cho vấn đề này. Lỗi này chắc chắn rất dễ nhận thấy và khá đáng lo

    • Lỗi này đã được biết đến ở nơi khác chưa? Có vẻ Mullvad báo cáo sau beta thứ 6, mà thời điểm đó đã khá gần RC
      Trong bài gốc có viết “we have investigated this issue after the 6th beta was released and reported the bug to Apple”

  • Với tôi, cách giải quyết là tải cấu hình WireGuard xuống và dùng ứng dụng Wireguard

    • Nhưng như vậy liệu ứng dụng Wireguard có làm rò rỉ dữ liệu và kém an toàn hơn ứng dụng Mullvad không?
    • Chỉ là giải pháp nếu bạn không đưa các quy tắc tường lửa PostUp và PostDown vào cấu hình WireGuard. Như thế thì khó gọi là giải pháp

  • Câu hỏi: nếu pflog1 không được tạo thì pf có hoạt động như mong đợi không?
    Nếu tcpdump không ghi nhận gì đi ra pflog1, thì có vẻ dữ liệu không được gửi tới pflog1. Khi đó nghĩa là vấn đề nằm ở tầng trước đó
    pflog1 đã được gắn và bật lên chưa? Trước đây phải gắn và bật interface thủ công. MacOS có tự động làm việc đó không?
    Tất nhiên việc tách bạch chuyện này không phải là trách nhiệm của người báo lỗi. Nhưng đến một lúc nào đó kỹ sư phụ trách cũng sẽ hỏi những câu như vậy, nên trả lời sẵn thì tốt hơn

    • Có thể thêm gì vào các bước tái hiện như một phương án vòng tránh không? Ví dụ như đã nói, sau khi tải pfrules thì gắn và bật interface lên
    • Sau đó, để xóa interface bổ sung thì cũng cần làm việc này:
      ifconfig pflog1 destroy