MediaTek Wi-Fiチップセットの致命的エクスプロイト: ゼロクリック脆弱性

 (blog.sonicwall.com)
1 ポイント 投稿者 GN⁺ 2024-09-22 | 1件のコメント | WhatsAppで共有

MediaTek Wi-Fiチップセットの深刻な脆弱性: Zero-Click脆弱性(CVE-2024-20017)がルーターとスマートフォンを脅かす

概要
  • SonicWall Capture Labs脅威研究チームはCVE-2024-20017脆弱性を認識し、その影響を評価して緩和策を開発
  • CVE-2024-20017はCVSS 3.0スコア9.8の深刻なzero-click脆弱性で、MediaTek Wi-FiチップセットMT7622/MT7915およびRTxxxx SoftAPドライバーバンドルに影響
  • Ubiquiti、Xiaomi、Netgearなどさまざまなメーカー製品で使われるMediaTek SDKバージョン7.4.0.1以前、およびOpenWrt 19.07と21.02が影響を受ける
  • この脆弱性はユーザー操作なしでリモートコード実行を可能にし、MediaTekはこれを緩和するためのパッチを配布
  • この脆弱性は3月に公開・パッチ適用されたが、最近公開されたPoCにより悪用可能性が高まっている
技術的概要
  • 脆弱性は、MediaTek MT7622/MT7915 SDKおよびRTxxxx SoftAPドライバーバンドルに含まれるネットワークデーモン wappd に存在
  • wappd は無線インターフェースとアクセスポイントを構成・管理する役割を担い、特にHotspot 2.0技術と関連する
  • wappd のアーキテクチャは、ネットワークサービス本体、デバイスの無線インターフェースと相互作用するローカルサービス群、そしてUnixドメインソケットを介したコンポーネント間通信チャネルで構成される
  • この脆弱性は、攻撃者が制御するパケットデータから直接取得した長さの値をメモリコピーに使用することで発生するバッファオーバーフローに起因する
脆弱性のトリガー
  • 脆弱性は IAPP_RcvHandlerSSB 関数で発生し、攻撃者が制御する長さの値が IAPP_MEM_MOVE マクロに渡される
  • 最大パケット長1600バイトを超えないことを確認する以外、境界チェックは行われない
  • 攻撃者は想定された構造体を攻撃ペイロードの前に付加してパケットを送信する必要がある
  • RT_IAPP_HEADER 構造体の長さは小さくなければならず、RT_IAPP_HEADER.Command フィールドは50でなければならない
悪用
  • 公開されたエクスプロイトコードはROPチェーンを使用し、グローバルアドレステーブル上書き手法によってリモートコード実行を達成
  • system() 呼び出しを利用して、攻撃者にリバースシェルを送るコマンドを実行
  • リバースシェルはBashとNetcatツールを使って設定される
SonicWallの保護
  • SonicWallの顧客がこの脆弱性による悪用に備えられるよう、以下のシグネチャが配布されている
    • IPS: 20322 MediaTek MT7915 wlan Service OOB Write 1
    • IPS: 20323 MediaTek MT7915 wlan Service OOB Write 2
緩和の推奨事項
  • エクスプロイトコードが公開されているため、ユーザーには当該チップセットの最新ファームウェア版へアップグレードすることを強く推奨
関連リンク

GN⁺のまとめ

  • この記事はMediaTek Wi-Fiチップセットの深刻なzero-click脆弱性について扱っており、これはユーザー操作なしでリモートコード実行を可能にする
  • SonicWall研究チームはこの脆弱性を認識して緩和策を開発しており、ユーザーには最新ファームウェアへのアップグレードを推奨している
  • この脆弱性はさまざまなメーカーのルーターやスマートフォンに影響し、最近公開されたPoCにより悪用可能性が高まっている
  • 類似機能を持つ製品としてはQualcommのWi-Fiチップセットがあり、セキュリティアップデートを定期的に確認することが重要

関連記事

1件のコメント

 
GN⁺ 2024-09-22
Hacker News のコメント

  • MediaTek のベンダー SDK ドライバーのソースコードを mt76 と比較してみた立場からすると、それほど驚きではない。控えめに言ってもごちゃごちゃしている
    残念ながら、mt76 よりスループットが少し出るという理由で、ベンダードライバーを入れたサードパーティ製ファームウェアビルドも一部使われている
    幸い、MediaTek と WiSoC 部門には自由・オープンソースソフトウェアコミュニティと積極的にやり取りしているエンジニアが何人かいて、mt76 ベースの小さな OpenWrt フォークも自分たちで保守している: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk...

    • こういうハードウェア/ファームウェアは、なぜこんなにも概念実証コードを本番環境にデプロイしたように感じられるのだろう。ちゃんと分かっている人を雇えないのか
    • そのプログラムの目的や、そのフィードのうちどれくらいが上流プロジェクトにマージされたのか、といったプレスリリースや情報があるのか気になる

  • タイトルの表現は少し誤解を招く。家に mt76 Wi-Fi 搭載のルーターが何台かあるので、ファームウェアかシリコンのバグかと思ってリンクをクリックしたが、実際はベンダーの SDK の雑多なコードのバグだと分かって安心した
    メインラインカーネルと hostapd で mt76 のサポートはかなり良いのに、誰がそれを使おうとしたのか理解できない

    • 「ベンダーの SDK の雑多なコードのバグだと分かって安心した」と言うには、心配すべきベンダーが複数ある
      「Ubiquiti、Xiaomi、Netgear などを含む複数メーカーの製品で使われたドライバーバンドル」とされている
      ただし Ubiquiti のように、実際の製品ではこれを使っていないと明らかにしているベンダーもある: https://community.ui.com/questions/CVE-2024-20017/b3f1a425-d...
    • OpenWRT 21.02.x 系はメインラインカーネル 5.4 ベースなのに影響を受けるとされている。この界隈の人たちは Linux の無線ネットワークに詳しいし、実際メインラインカーネルの mt76 ドライバーも OpenWRT 開発者が保守していると理解している

  • 元のブログ: https://blog.coffinsec.com/0day/2024/08/30/exploiting-CVE-20...

    • wappd サービスは主に Hotspot 2.0 と関連技術を使って、無線インターフェイスとアクセスポイントの動作を設定・調整するために使われる
      アプリケーション構造はやや複雑だが、本質的にはネットワークサービス1つ、デバイスの無線インターフェイスと相互作用するローカルサービス群、そして Unix ドメインソケットを使うコンポーネント間通信チャネルで構成されている
      まだ救いなのは、これがベースバンドファームウェア内のバグというより、無線ネットワークカード自体の動作に必須ではない「付加価値」サービス側の問題のように聞こえる点だ
      一部デバイスのドライバーパッケージでは、実際のドライバーは小さくて静かなのに、ユーザーの99%が必要とせず望んでもいない機能のために桁違いに大きいバンドルウェアを一緒にインストールする方式を思い出す。プリンターと GPU は特にひどい

  • MediaTek の命名規則に何らかの論理があるのか、それとも全デバイスが単に MTxxxx で x が増分値か乱数なのか気になる
    mt6631 Wi-Fi チップ入りのデバイスを持っているが、影響を受けるリストにないので大丈夫だとは推測できても、製品ファミリーのどのあたりに位置するのか分かりにくい

  • OpenWrt 19.07 と 21.02 が影響を受けるというが、見る限り公式の OpenWrt ビルドは Mediatek SDK ではなく mt76 ドライバーだけを使っているように見える

  • AMD CPU 搭載のノート PC を買うと、いつも MediaTek RZ616 Wi-Fi カードが付いてくるのはなぜなのか分からない
    全部 Intel Wi-Fi カードに交換してきたので、今では将来マイクロプラスチックになる RZ616 カードの山ができている

    • Intel は Wi-Fi カードを2種類売っている。末尾が1のモデルは CNVI プロトコルを使うため Intel チップでしか動作せず、OEM には非常に安く売られる
      末尾が0のモデルは標準 PCIe を使い、OEM にはおよそ10ドル高く売られる
      AMD は OEM に Intel の xx1 チップと同じ価格帯で売れるものを作るため、MediaTek MT7921 と MT7922 をそれぞれ RZ608、RZ616 としてリブランドしたのだ
    • Lenovo も MediaTek に不満を持ち、AMD プラットフォームで WLAN 用に Qualcomm チップをはんだ付けし始めたが、Linux でファームウェアとドライバーの相互作用バグにまたやられた。Lenovo は Linux を公式に販売・サポートしているにもかかわらずだ
      Qualcomm はチップセット世代が最新でなくなると、メインラインカーネル側のサポート余力がかなり薄くなる。今どき Qualcomm を動かすには、とてつもないベンダーからの圧力が必要だ
    • iwlwifi にも固有の問題があり、最大のものは 5GHz AP モードがないことだ。Intel のファームウェアライセンスも MediaTek より制限が強く、fullmac なのでファームウェアがはるかに多くの仕事を背負う
      個人的には softmac のほうが好みだ。最近は良い選択肢があまりなく、ath9k の黄金時代は過ぎ去った
    • 単に「MediaTek は信用できない」という以上に、実際に使ってみたのか気になる
      仕事用に Intel ThinkPad と AMD ThinkPad を順に使ったが、AMD 側の MediaTek チップセット Wi-Fi は Intel 側の Intel チップセットよりはるかに良かった
      Intel 側は1時間に何度もネットワーク接続が切れ、5GHz でも ssh を使うとすぐ体感できるほど遅延がひどかった。今使っている MT7921 デバイスは Linux でこの2〜3年非常に安定している
      結局、チップセットとノート PC の組み合わせによってかなり違うようだ

  • 自分の携帯電話も MediaTek チップセットを使っていると記憶している。そしてメーカーがその後 MediaTek から離れた理由は、それら製品の、ええと、品質だったとぼんやり覚えている
    携帯電話で Wi-Fi がどう構成されているのかは分からない。この携帯電話が影響を受けるか確認する方法はあるだろうか。無制限のモバイルデータ通信と良好なカバレッジがあるので Wi-Fi はほとんど使わないが、それでも知っておけるとありがたい

    • termux で "sudo su" を実行してから ls /sys/module を見ればいい
      出力は lsmod と似た感じになる

  • 最近のように、人々が手に入るシリコンなら何でも買う時代でも、こういうC級ベンダーが PC 戦略にならってファームウェアを完全に開放し、オープンソースコミュニティに任せない理由がいまだに理解できない

    • 許可された帯域外へ送信しにくくしなければならないという FCC 規制が、たいていこういう状況を生む

  • 「影響を受けるバージョンには MediaTek SDK 7.4.0.1 以下と OpenWrt 19.07、21.02 が含まれる」「脆弱性は MediaTek MT7622/MT7915 SDK および RTxxxx SoftAP ドライバーバンドルに含まれるネットワークデーモン wappd にある」とされているが、肝心の OpenWRT は wappd を使っていないように見える

    • OpenWrt のコントリビューターとして、人々がなぜ OpenWrt と独自ベンダー SDK を区別しないのか疑問だ。Nobara にバグがあったからといって Fedora に言及することはなかっただろう
    • 自宅ネットワークで Netgear AP 複数台に OpenWRT を載せて使っているので、同じ点が気になった。この説明どおりなら自分は大丈夫なのだろうか

  • だから自由なファームウェアが必要なのだ。Broadcom と Ralink にはもううんざりだ