- 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)
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
1件のコメント
Hacker News のコメント
同じ PF のバグが OrbStack のネットワーク機能の一つも壊している
原因をここまで絞り込んだときは信じがたかったが、自分だけが遭遇しているわけではなさそう。安定版リリース前に必ず直ってほしい
Apple に報告できたのは昨日になってからだが、かなり最近のリグレッションに見え、おそらく beta 6 あたりから発生したようだ
PF は本来、最後に一致したルールが適用されるファイアウォールであるはずなのに、macOS はほとんど最初に一致したルールのように動いているように見える。前方の
blockルールがquickなしでも別アンカーのpassルールを上書きしてしまい、当然問題になるこの状態で安定版が出るなら受け入れられないし、個人的には Mac OS を見限る理由になる。真剣な仕事に使ってほしいなら、こうしたリグレッションのある製品を出すべきではない
記事がとても簡潔で有益で、バグの再現手順までシンプルに含まれていてよい
Mullvad は好感が持てる
余談だが、macOS はここ数リリースで奇妙なファイアウォール関連のバグが全体的に多く、なぜファイアウォール周りを作り直すことになったのか気になる
ローカルマシンや OS が何であれ、ブラウジングを専用サーバー経由にできる。ネットワーク接続全体を包むわけではなくブラウジングだけだが、その範囲内では IP アドレスを変え、位置を隠し、ブラウザのゼロデイからの保護も追加してくれる
BrowserBox にはプライバシーを尊重・保護し、体験全体を改善する機能を継続的に追加している。オープンソースなので好きなように変更もできる。AGPL-3.0 が気に入らなければ商用ライセンスも可能: https://github.com/dosyago/BrowserBoxPro
オープンソースが嫌で大企業の安心感を好むなら、Mullvad にも似たことをする Mullvad Browser があるようだ
関連する古い記事: https://9to5mac.com/2015/05/26/apple-drops-discoveryd-in-lat...
この 再現コードは本当に見やすい
もちろんそれがバグの範囲ではあるが、この検査が特別に精巧だったり美しかったりするようには見えない
関係あるかは分からないが、直近 2 回の macOS アップグレード直後にネットワークが動作しなかった
Wi‑Fi、Ethernet、ホットスポットには接続できたが、ブラウザや ping のような実際の接続は何もできず、ルーターにも届かなかった
2 回とも Mullvad VPN アプリを一度開くだけで、また全部動作するようになった。なぜアプリを開くだけで問題が直るのかは分からない
完全に関係があるわけではないが、別の古いバグもある: macOS
Popen()の 11 年前からのバグ: https://news.ycombinator.com/item?id=37238433参考までに、Mullvad.app では接続問題があったが、Wireguard.app で Mullvad WireGuard 設定を実行すると問題なく動作した
最近最新の Sonoma beta を入れたのだが、Mullvad をどうやっても動かせなかった理由が分かった
Mullvad が回避策に取り組んでいるとのことで安心した。今朝は Ventura にダウングレードしようかとも思っていたので、自分の問題だったのだと感じる
Mullvad がこの問題への 公開圧力を高めてくれてうれしい。このバグは確かに目立っていたし、かなり懸念していた
原文には “we have investigated this issue after the 6th beta was released and reported the bug to Apple” とある
自分の場合は WireGuard 設定をダウンロードして Wireguard アプリを使うのが解決策だった
PostUpとPostDownのファイアウォールルールを入れない場合に限って解決策になる。そうすると、あまり解決策とは言いにくい質問:
pflog1が作成されない場合、pf は期待どおりに動作するのか？tcpdumpがpflog1に出ていくものを何も記録しないなら、データがpflog1に送られていないという意味に見える。ならば、それより前段の問題ということになるpflog1は接続され、up になっていたのか？ 以前はインターフェースを手動で接続して up にする必要があった。MacOS はそれを自動でやってくれるのか？もちろん、これを切り分けるのはバグ報告者の仕事ではない。だがいずれ担当エンジニアがこうした質問をするはずなので、先に答えておくほうがよい
ifconfig pflog1 destroy