macOS 14 Sonoma 버그로 Mullvad VPN 앱 작동 중단

 (mullvad.net)
1P by GN⁺ | ★ favorite | 댓글 1개
  • macOS 14 Sonoma 베타와 릴리스 후보에서 PF 방화벽이 트래픽을 제대로 필터링하지 못해 Mullvad VPN 앱이 정상 동작하지 않음
  • 로컬 네트워크 공유 같은 일부 설정이 켜진 경우 트래픽 누수로 이어질 수 있어, Mullvad는 macOS 14에서 기능과 보안을 보장하기 어렵다고 봄
  • Mullvad는 6번째 베타 이후 문제를 조사해 Apple에 보고했지만, 이후 베타와 릴리스 후보에도 버그가 남아 있음
  • 앱 자체 패치로 우회할 수 있는지 검토했으나 안전한 해결책을 찾지 못했고, 근본적으로 Apple의 방화벽 수정이 필요함
  • PF 필터링에 의존하는 사용자나 관련 앱은 macOS 14 업그레이드에 주의해야 하며, 버그가 남아 있으면 macOS 13 Ventura에 머무르는 것이 안전함

macOS 14 Sonoma의 PF 방화벽 문제

  • macOS 14 Sonoma 베타 기간에 Apple이 macOS 방화벽인 packet filter(PF) 에 버그를 도입함
  • 이 버그로 Mullvad VPN 앱이 작동하지 않으며, 특정 설정이 켜진 경우 트래픽 누수가 발생할 수 있음
    • 예시 설정으로 로컬 네트워크 공유가 언급됨
  • Mullvad는 6번째 macOS 14 베타가 나온 뒤 문제를 조사했고 Apple에 버그를 보고함
  • 이후 macOS 14 베타와 릴리스 후보에도 같은 문제가 계속 남아 있음
  • VPN 앱만 패치해 macOS 14에서 동작과 보안을 모두 유지하는 방안을 평가했지만, 현재로서는 좋은 해결책이 없다고 판단함
  • 영향 범위는 Mullvad VPN 앱에만 그치지 않음
    • 방화벽 규칙이 네트워크 트래픽에 제대로 적용되지 않음
    • 허용되지 않아야 할 트래픽이 통과할 수 있음
    • PF 필터링에 의존하는 사용자나 이를 백그라운드에서 쓰는 앱은 macOS 14 업그레이드에 주의해야 함
  • macOS 14 Sonoma는 9월 26일 출시 예정이며, 버그가 남아 있다면 Mullvad 사용자는 수정 전까지 macOS 13 Ventura에 머무르는 것이 권장됨

재현 절차와 실제 결과

  • macOS 14에서 문제를 재현할 수 있으며, 이 실험은 PF에 로드된 방화벽 규칙을 지움
  • 터미널에서 가상 로깅 인터페이스를 만들고, 나중에 추가할 규칙과 일치하는 트래픽을 감시함
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 45.83.223.209
  • 기대 결과는 ping이 유일한 pass 규칙 조건과 일치하지 않아 차단되고, 트래픽이 pflog1에 block 규칙과 일치한 것으로 기록되는 것임
  • 실제로는 ping이 인터넷으로 나가고 응답이 돌아오며, pflog1에 트래픽이 기록되지 않음
  • 실험 후에는 방화벽을 비활성화하고 모든 규칙을 지움
sudo pfctl -d
sudo pfctl -f /etc/pf.conf

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 같은 PF 버그가 OrbStack의 네트워킹 기능 하나도 망가뜨리고 있음
    원인을 여기까지 좁혔을 때 믿기 어려웠지만, 나만 겪는 건 아닌 듯함. 안정 버전 출시 전에 꼭 고쳐지길 바람
    어제서야 Apple에 보고할 수 있었는데, 꽤 최근 회귀로 보이고 아마 beta 6 즈음부터 생긴 듯함
    PF는 원래 마지막으로 일치한 규칙이 적용되는 방화벽이어야 하는데, macOS가 거의 첫 번째 일치 규칙처럼 동작하는 것 같음. 앞쪽의 block 규칙이 quick 없이도 다른 앵커의 pass 규칙을 덮어써서 당연히 문제가 생김

    • “정말 바란다” 정도로는 부족함. 이건 출시 전에 반드시 고쳐져야 함
      이런 상태로 안정 버전이 나오면 받아들일 수 없고, 개인적으로는 Mac OS를 포기할 이유가 됨. 진지한 업무에 쓰이길 원한다면 이런 회귀가 있는 제품을 내면 안 됨

  • 글이 아주 간결하고 유익하며, 버그 재현 절차까지 단순하게 들어가 있어서 좋음
    Mullvad가 마음에 듦
    곁가지지만 macOS는 최근 몇 릴리스 동안 이상한 방화벽 버그가 전반적으로 많았고, 왜 방화벽 쪽을 갈아엎고 다시 만들게 됐는지 궁금함

    • 재작성은 Catalina에서 Big Sur로 넘어가며 커널 확장에서 사용자 공간의 System Extensions, 특히 NetworkExtension으로 강제 이전한 영향이 확실히 있었을 것임: https://developer.apple.com/documentation/networkextension
    • 로컬 운영체제 플랫폼의 이런 버그가 걱정된다면, 원격 브라우저로 로컬 접속 지점을 추상화하는 방법도 고려할 수 있음
      로컬 머신과 운영체제가 무엇이든 브라우징을 전용 서버를 통해 돌릴 수 있음. 전체 네트워크 연결을 감싸는 건 아니고 브라우징만 해당하지만, 그 범위 안에서는 IP 주소를 바꾸고 위치를 숨기며 브라우저 제로데이로부터 보호를 더해 줌
      BrowserBox에는 개인정보를 존중하고 보호하며 전체 경험을 개선하는 기능을 계속 추가 중임. 오픈소스라 원하는 대로 바꿀 수도 있음. AGPL-3.0이 마음에 들지 않으면 상용 라이선스도 가능함: https://github.com/dosyago/BrowserBoxPro
      오픈소스가 싫고 큰 회사의 편안함을 선호한다면 Mullvad에도 비슷한 일을 하는 Mullvad Browser가 있는 듯함
    • rdar/Feedback 번호까지 포함했으면 더 좋았을 것 같음
    • macOS는 수년간 네트워킹 스택을 발전시키려 했지만, 회귀가 생기면 다시 되돌리곤 했음
      관련된 오래된 글: https://9to5mac.com/2015/05/26/apple-drops-discoveryd-in-lat...

  • 이 재현 코드는 정말 보기 좋음

    • 단순한 것도 좋지만, 정리 단계까지 들어 있는 점이 특히 좋음. 이런 재현 절차에서 자주 빠지는 요소임
    • 그냥 단순한 방화벽 규칙을 설정하고 그 규칙을 위반하는 질의를 시도하는 것 아닌가 싶음
      물론 그게 버그의 범위이긴 하지만, 이 검사가 특별히 정교하거나 아름답다고 보이진 않음

  • 관련 있는지는 모르겠지만, 최근 두 번의 macOS 업그레이드 직후 네트워킹이 동작하지 않았음
    Wi‑Fi, 이더넷, 핫스팟에는 연결할 수 있었지만 브라우저나 ping 같은 실제 연결은 아무것도 되지 않았고, 라우터에도 닿지 않았음
    두 번 모두 Mullvad VPN 앱을 한 번 열기만 하면 다시 전부 동작했음. 왜 앱을 여는 것만으로 문제가 고쳐지는지는 모르겠음

    • VPN 앱은 라우팅 테이블을 바꾸므로, VPN 앱을 실행하기 전까지 트래픽이 존재하지 않는 인터페이스로 라우팅되고 있었던 것 같음

  • 완전히 관련 있진 않지만, 또 다른 오래된 버그도 있음: macOS Popen()의 11년 된 버그: https://news.ycombinator.com/item?id=37238433

    • 본인 버그라면 패치와 함께 Feedback도 보내는 게 좋음. 오픈소스 프로젝트 쪽은 보통 PR을 받지 않음

  • 참고로 Mullvad.app으로는 연결 문제가 있었지만, Wireguard.app에서 Mullvad WireGuard 설정을 실행하면 잘 동작했음

  • 최근 최신 Sonoma beta를 설치했는데 Mullvad를 아무리 해도 동작시킬 수 없었던 게 이해됨
    Mullvad가 우회책을 작업 중이라니 다행임. 오늘 아침에는 Ventura로 다운그레이드할까도 생각했는데, 내 문제가 맞았다는 느낌이 듦

    • 우회책을 작업 중이라고 쓰여 있진 않음. Apple이 버그를 고칠 때까지 사용자가 Sonoma로 업그레이드하지 말라고 되어 있음
    • tailscale/mullvad 조합은 여전히 동작할 것 같음. Apple이 고칠 때까지 괜찮은 우회책이 될 수도 있음

  • Mullvad가 이 문제의 공개 압박을 올려줘서 반가움. 이 버그는 확실히 눈에 띄었고 꽤 우려스러웠음

    • 이게 다른 곳에서도 이미 알려졌나? Mullvad는 6번째 beta 이후에 보고한 것 같고, 그 시점이면 RC에 꽤 가까움
      원문에는 “we have investigated this issue after the 6th beta was released and reported the bug to Apple”라고 되어 있음

  • 내 경우에는 WireGuard 설정을 내려받아 Wireguard 앱을 쓰는 게 해결책이었음

    • 하지만 Wireguard 앱이 데이터를 새게 만들고, Mullvad 앱보다 덜 안전한 건 아닌가?
    • WireGuard 설정에 PostUp과 PostDown 방화벽 규칙을 넣지 않는 경우에만 해결책임. 그러면 별로 해결책이라고 하기 어려움

  • 질문: pflog1이 생성되지 않으면 pf는 기대한 대로 동작하나?
    tcpdump가 pflog1로 나가는 것을 아무것도 기록하지 않는다면, 데이터가 pflog1로 보내지지 않는다는 뜻으로 보임. 그러면 그보다 앞단의 문제라는 의미가 됨
    pflog1은 연결되고 올라온 상태였나? 예전에는 인터페이스를 수동으로 연결하고 올려야 했음. MacOS가 그걸 자동으로 해 주나?
    물론 이걸 분리해내는 건 버그 신고자의 일이 아님. 하지만 어느 시점에는 담당 엔지니어가 이런 질문을 할 테니, 답을 미리 해두는 편이 좋음

    • 재현 절차에 우회책으로 추가할 수 있는 게 있을까? 예를 들어 말한 것처럼 pfrules 로드 후 인터페이스를 연결하고 올리는 식으로
    • 이후에는 추가 인터페이스를 제거하려면 이것도 해야 함:
      ifconfig pflog1 destroy
답변달기