CERT、dnsmasqの深刻なセキュリティ脆弱性6件のCVEを公開

 (lists.thekelleys.org.uk)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • CERTが2026年5月11日にdnsmasqの深刻なセキュリティ脆弱性6件に関するCVEセットを公開
  • 脆弱性はいずれも古いバグで、非常に古いバージョンを除くほぼすべてのdnsmasqバージョンに影響
  • CVEはベンダーに事前開示されており、各ベンダーはdnsmasqパッケージのパッチ版を適時配布する必要がある
  • 安定版リリース dnsmasq 2.92 にパッチを適用した2.92rel2が作成され、従来のダウンロード先から入手可能
  • まもなくdnsmasq-2.93rc1タグが作成される予定で、テストを経て約1週間以内の2.93リリースを目標としている

dnsmasq脆弱性の公開とパッチ

  • CERTが2026年5月11日にdnsmasqの深刻なセキュリティ脆弱性6件に関するCVEセットを公開
  • 脆弱性はいずれも古いバグで、非常に古いバージョンを除くほぼすべてのdnsmasqバージョンに適用される
  • CVEはベンダーに事前開示されており、各ベンダーはdnsmasqパッケージのパッチ版を適時配布する必要がある
  • 詳細情報とパッチはhttps://thekelleys.org.uk/dnsmasq/CVE/で確認可能
  • 安定版リリース dnsmasq 2.92 にパッチを適用した2.92rel2が作成され、従来のダウンロード先から入手可能
  • 開発ツリーにも同時期に修正コミットが上がる予定で、一部はバックポートと同じパッチを使い、一部は根本原因に対処するより包括的な書き直しとなっている

AIベースのレポート増加と2.93計画

  • ここ数か月でAIベースのセキュリティ研究によりバグレポートが大幅に増え、重複排除とバグ分類に多くの時間がかかっている
  • バグはベンダーへの事前開示が必要な項目と、公開後に即時修正した方がよい項目に分けられ、この区分は避けがたく主観的である
  • 同じバグを複数の“good guys”が繰り返し見つけている以上、“bad guys”も発見できた可能性があり、長いエンバーゴの実効性は高くないと見ている
  • エンバーゴの調整とバックポート提供には、すべての参加者に多くの時間と労力が必要となる
  • ほとんどのバグは今後のリリースで修正し、新しいdnsmasqリリースを可能な限りバグの少ない状態にすることが優先される
  • 発表前の数週間にわたりgitリポジトリに多くのセキュリティ修正コミットが上がっていたことも、この方針とつながっている
  • まもなくdnsmasq-2.93rc1タグを作成する予定で、安定版 2.93 をできるだけ早く出すことを目標としている
  • リリース候補のテストは重要であり、可能なユーザーは早めにテストすべきである
  • 順調に進めば2.93は約1週間以内にリリースされる可能性がある
  • AI生成バグレポートの“tsunami”は止まる気配がなく、同じプロセスが近いうちに再び繰り返される可能性がある
  • 2.93に進行中のバグの流れをできるだけ多く反映することと、適時にリリースすることの間には緊張関係があり、優先順位はタイムリーなリリースにある

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Hacker Newsのコメント

  • Cで書かれたコードをメモリ安全な言語に置き換えることが、いよいよ急務になる転換点のように思える
    最近見つかる脆弱性の大半はメモリ安全でない言語と直接関係しており、DNS/DHCPサーバーをRustやGoで、できればunsafeなしに書けないと正当化するのはかなり難しそうだ

    • https://news.ycombinator.com/item?id=47943499 — coreutilsを新しいRust実装に置き換えようとして44件のCVEが出た例がある。うまい話はない
    • 問題は言語ではなく、これをやろうとする人材不足だ
      AIセキュリティ研究者たちは少なくとも何かはしている。すべてをRustで書き直すのがそんなに簡単なら、こういう事故の翌日には堅牢なRust代替が出てきているはずだ
      そうならないのは、こういうことをしてもGitHubスターを得にくいからだ
    • もしかすると問題は動的メモリの捉え方かもしれない
      「最大サイズがわからないから全部動的であるべきだ」が本当に正しいのか疑問だ。プログラムが入力の許容最大サイズを宣言し、それを超えたらエラーにするかリングバッファを使うのは、別に世界の終わりではない
      サイズがわかるなら、それに合わせて設計できる。RAMは有限なのに、その中のあらゆる層が無限であるかのように設計されているのは奇妙だ
      Rustへの置き換えは莫大な時間の無駄に見えるし、プログラムを有限なシステム資源という現実に合わせてモデル化できていない根本問題を解決しない。メモリだけの問題でもない。Chromeがユーザー端末に4GBモデルを載せる例も似た話だ
    • 同意しない。潜在的な脆弱性を見つけるAIエージェントのおかげで、防御策は明らかに改善している

  • https://xchglabs.com/blog/dnsmasq-five-cves.html

  • OpenWRTが新しいビルドを出したのか気になっていたが、答えはまだで、作業中だ
    https://forum.openwrt.org/t/dnsmasq-set-of-serious-cves/2500...

  • 私のMaraDNSは、AI支援のセキュリティ監査時代に入ってから、かなり広範に監査されてきた
    2023年以降、深刻なセキュリティバグは1件も見つかっていない [1]
    監査者が見つけたのは、「Deadwoodが完全再帰モードのときに妙なパケットを受けると、普段よりリソース解放に時間がかかる」[2] とか、「MaraDNSに含まれる補助ユーティリティが2022年からそもそもコンパイルすらできていないのに、$HOMEが50文字を超える場合にだけバッファオーバーフローがある」[3] といったものだけだ
    深く実践的なセキュリティ監査を受けている今、MaraDNSがかなり安全だという点には個人的にとても満足している
    [1] https://samboy.github.io/MaraDNS/webpage/security.html
    [2] https://github.com/samboy/MaraDNS/discussions/136
    [3] https://github.com/samboy/MaraDNS/pull/137

    • Lua 5.1をライブラリとしてロードせずにLunacyへ組み込んでいて、それも2012年版だとしたら、おそらくCVE-2014-5461などの影響も受けうる
      Luaにもセキュリティ修正がなかったわけではない
    • それでもMaraDNSはdnsmasqよりはるかに不人気だ
      私にも自作ライブラリがいくつかあるが、1991年以降、深刻なセキュリティバグは1件も見つかっていない。もちろん誰も私のライブラリを使っていない
      実績をけなすつもりはないが、こういう主張はユーザーベースがどうかという文脈と一緒に語るのが重要だ
    • 以前DNSサーバーを設定したとき、dnsmasqの「何でもやる」方式の代わりにMaraDNSを見つけてうれしかったし、もっと重要なのは、その後ほとんど気にかける必要がなかったことだ
    • 何を言いたいのかよくわからない。dnsmasqの代替があるという話なのか、自分のソフトウェアが somehow「より良い」と言いたいのか？
      この宣伝はdnsmasqの議論にほとんど価値がない
      より広く使われているソフトウェアほど、より多く精査され、より多くのバグや境界事例が見つかる
    • よくやったとは思う。ただ、2026年になっても中核的なネットワークツールをCのような脆弱な言語で書き続けているのは驚きだ

  • 幸い、このソフトウェアがほとんど更新されない何百万台もの機器で使われているわけではないだろう

    • ベンダーが「好きなようには使わせない」と言うとき、自分のハードウェアを自分で制御できるのは良いことだ
    • たいていの場合、クライアントが先にWi‑Fiで認証するか、Ethernetポートに物理的に挿さない限りパケットを送れない機器上で動いている点は、まだ救いだ
    • Y2K26?

  • かなり深刻だ
    「DNSクエリを送れる、あるいはDNS応答を返せるリモート攻撃者が、ヒープ上で大きな範囲外書き込みを引き起こせる」
    不正なDNS応答は「無限ループを誘発し、dnsmasqがすべてのクエリに応答しなくなる」可能性がある
    悪意あるDHCPリクエストはバッファオーバーフローを引き起こしうる

  • AIバグレポートの津波がすべてのプロジェクトにあるわけではない。上で言った通り、MaraDNSにはなかった
    djbdnsやtinydnsにもなかっただろうと思う。もしあれば大々的に知らされていたはずだ
    なぜあるプロジェクトは極端に人気が出て、別のプロジェクトはそうならないのか、ずっと理解できなかった
    「公開するには危険すぎる」ツールがすべてのプロジェクトをスキャンしつつ、問題のあるところにだけ選択的に連絡しているようにも見える。そうすれば、自分たちのツールが何も見つけられなかった事実を認めずに済むからだ

    • そういうことは人気のあるプロジェクトで起きる

  • dnsmasqを使うのが好きだったことはない。1つのツールにあまりに多くを詰め込みすぎている感じだった
    ローカルのキャッシングリゾルバ、DHCPサーバー、TFTP/PXEブート設定は、常に別々に構成するほうを好んできた

    • 人によっては代えが利きにくいdnsmasqの機能がいくつかある
      たとえば、*.example.comへのクエリを特定の上位サーバーに送る機能、フィッシングサイトにNXDOMAINを返す機能、*.example.orgに解決されたすべてのIPをポリシールーティング用のipsetに追加する機能だ
      最後の機能は、BSDにはipsetがないのにFreeBSDでも動作する。*.example_xyz.comのリストは非常に大きくなりうるが、最近のdnsmasqはこれを効率よく処理すると言われている
    • そういう考えから、かなり前にDNSホスティングにMaraDNSを使うようになった
      10点満点で10点、後悔なし、薦められる
    • 同意する。これはLinuxの「流儀」にも反している感じがする
      たとえばOpnsenseはDHCP部分だけdnsmasqを使い、DNSにはunboundを使っているが、これが少し「変」に感じる
    • それがある程度目的でもある。dnsmasqは「小さなルーター1台を動かす」ためのアプリを1箱に詰めたものだ
      DHCPとDNSはつながっているし、PXEにはDHCPエントリが必要だ。簡単な構成をしたいなら、そうでなければ設定文法の違うデーモン最低3つをつなぎ合わせる必要がある

  • この分野の経験がもっとある人に聞きたい初心者質問なのだが、なぜこの領域のソフトウェアはErlangのようなガベージコレクションと並行性を備えた言語ランタイムで、もっと多く書かれていないのだろうか

    • dnsmasqの最初のリリースは2001年だった。当時、高性能なネットワークサーバーに現実的に使えた言語の選択肢はそれほど多くなく、Erlangはそこに入っていなかった
      性能面の損失が大きすぎたし、当時安定していたのかもわかりにくい不透明なランタイムがあり、コントリビューターも少なく、ほとんどのシステムに入っていない依存関係のフットプリントも大きかった
      2015年ごろに本番システムでErlangを使ったときでさえ、本来の想定用途から少し外れると荒い部分があった。Erlangだけの批判ではなく、多くの言語やランタイムが似たようなものだった
      今後数週間から数か月にわたって影響を受け続けるこの手のシステムのかなり多くも、似た背景を持っている。Linuxカーネルで当時選べた潜在的代替はC++くらいだった。セキュリティ問題の常連であるOpenSSLは1998年に始まっている
      「ネットワークアクセスのある新規プロジェクトをCで書くな」という点には私も非常に強く同意するが、1998年に戻ったとして、他にどんな選択肢が現実的だったかを言うのは難しい
      より安全な言語はあったが、Cコミュニティよりはるかに小さく、安定性を保証するのも難しかった。Javaはすでに存在していたが、ネットワークサーバーの本格的候補になった正確な時期はわからず、だいたい2000年代後半くらいだと思う。1999年に見たJavaはまだそうではなかった
      たとえば2011年に、比較的重要でない用途でHaskellのネットワークサーバーを運用したことがあるが、本番ネットワークとしてはそれほど極端でもない条件で倒れた。2013年に同じコードベースをコア実行ループの変更なしで再利用したら約90%改善したので、私のコードというよりHaskell側の問題だったと思う
      それでも実運用に入れられるほどではなかったが、少なくとも失敗の原因が私のコードではなかったことは示せた。つまり、たとえHaskellが2000年代に存在していたとしても、当時のネットワークサーバーの現実的選択肢とは言いがたかったということだ
      今は昔よりずっと選択肢が多い
    • Cでは通常、structをネットワークパケットに直接マッピングできるのでかなり簡単だ
      他の言語では、そう単純でないことが多い
      もちろん、より遅く、より大きくなるという点もある