パスワードを忘れた? アカウント作成
13475058 story
バグ

メールの送信者を偽装できる問題が見つかる、多数のメールクライアントが影響を受ける 65

ストーリー by hylom
ありそう 部門より

非アスキー文字をメールのメッセージヘッダーに入れることで、メールの送信者を偽装できるという問題が見つかった。多くのメールクライアントがこの問題の影響を受け、本来の送信者でないメールアドレスなどを送信者として表示させることができるという(JPCERT/CCINTERNET WatchSecurity NEXT)。この問題はMailsploitなどと呼ばれているようだ。

電子メールのメッセージヘッダー内で非ASCII文字を利用したい場合、RFC1342で規定された方法でその文字をエンコードする。しかし、意図的に改行や制御文字などをエンコード後の文字列に挿入することでメールクライアントでのデコード処理に問題を発生させ、クライアント上でのメールアドレスの表示を別のものに差し替えることができるという。

JPERT/CCによると、Mac OS XのApple MailやWindowsのMail for Windows 10、Outlook 2016といった主要なメールクライアントのほとんどが影響を受けるようだ。いっぽうGmailははこの影響を受けないほか、Yahoo! Mailは修正が完了しているという。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2017年12月08日 17時39分 (#3326090)

    もともと脆弱なのに何が問題?と思ったけど、リンク先を見ると、DKIMの検証を回避できるってことなんですかね。

    • by Anonymous Coward

      携帯とかweb mailでメール使い始めた人は偽装ができるなんて考えたこともないと思う

    • by Anonymous Coward

      DMARC を通過できるので SPAM フィルターを容易に通過できる、というところが問題であるらしいです。
      「サーバーの問題である」として修正しないことに決定したメールソフトが2つ、というのはまぁ
      そもそも送信者の表示は信頼できないのでこれで動作が変わるのは本質的にはSPAM フィルターだけでしょ、
      という論理でしょうね。

      • by Anonymous Coward

        いや、全然違うでしょ。DKIMのチェックを通過していれば送信者(ドメイン)の表示は信頼できるはずなのに、
        DKIMのチェックを通過したドメインとは違うメールアドレスに偽装できてしまう脆弱性があったという話。

        「サーバーの問題である」というのは、この脆弱性を突くメールがRFCに従っていないからサーバで弾くべきという原則論に基づく話で、
        「そもそも送信者の表示は信頼できないのでこれで動作が変わるのは本質的にはSPAM フィルターだけでしょ」などという話ではない。

        • by Anonymous Coward

          いや、送信(クライアント)側は脆弱性があろうがなかろうが偽装しようと思えばできるし
          思わなければしないんだから関係ないでしょ
          結局のところ問題になるのは受信側検知能力
          検知の仕様がないというのならプロトコルの問題
          まあ、メールなんてそんなものだし、どうしても本人確認必要なら暗号化した署名を忍ばせるしかないわな

          • by Anonymous Coward on 2017年12月09日 4時01分 (#3326335)

            送信元ドメインの管理者は、SPFとDKIMの両方の認証に失敗したメールに対して、「そのまま通す(none)」、 「隔離する(quarantine)」、「受信拒否する(reject)」というように、受信時の処理方法をDMARCポリシーとして宣言できる。

            この宣言や公開鍵の公開は DNS の TXTレコードでやる。

            SPFと違ってDKIMは電子署名方式なので仮に受信側がメール転送をかけてもメールの中身(Fromとかのヘッダーも改変禁止)を改変しなければPASSするから reject の宣言をしても利便性は落ちない

            仮に reject の設定していないドメイン(DKIMには対応)を偽装しても受信ボックスに行かずに迷惑メールボックスに行くだろう。

            もう「メールのFromはいくらでも偽装できる」なんて時代はとっくに終わってる。だから、Fromを偽装できるのは「脆弱性」です

            親コメント
            • by Anonymous Coward on 2017年12月09日 14時05分 (#3326532)

              もう「メールのFromはいくらでも偽装できる」なんて時代はとっくに終わってる。だから、Fromを偽装できるのは「脆弱性」です

              これはこれで正論だけどさ。

              From: somebody@foo.com <dareka@hoge.com>

              みたいな記述で、送信者欄がデフォルトだと somebody@foo.com しか表示しないメーラーが普通にある昨今、脆弱性と言い切れるかというと・・・うん、すごく微妙な問題だと思う。

              親コメント
            • by Anonymous Coward

              それこそメールサーバの問題でメールソフト(クライアント)の問題ではないよね?

          • ここの文面だけ、読んで思ったのだが、
            物理メール(郵政メール)なんて偽装容易。
            差出人なんて簡単に嘘つける。

            書留とかなら、若干信頼性上がるが。

            親コメント
          • by Anonymous Coward

            受信側で偽装を検知できるはずなのに、偽装を許してしまうということなんですが。

  • by Anonymous Coward on 2017年12月08日 17時42分 (#3326092)

    メールの衰退を見ると、メッセージサービスを提供する各社の囲い込みが激しすぎて、利害調整に失敗しているように見える。実際、POP3もSMTPもIMAPも、読んでみると(今となっては)意味不明なレガシーを引き摺った酷い仕様だ。

    脚立の上に梯子をかけるような仕様を捨て去って、マルチバイトを前提にスクラッチから設計すれば、もっと綺麗で堅牢なプロトコルが作れると思うんだけど、誰もそこには手が延ばせないんだな。

    考えてみると、いろいろ批判されてるhtml5はわりと奇跡的なバランスの紆余曲折の結果で世に出てると思う。今のAmazonとGoogleがテレビ接続器の囲い込み合戦に必死になってるのとは対照的だ。それとも、ここから仲直りして、共通規格にできるんだろうか。

    • by Anonymous Coward

      考えてみると、いろいろ批判されてるhtml5はわりと奇跡的なバランスの紆余曲折の結果で世に出てると思う。

      なんだかんだ言っても、規格を更新することが業界全体の利益につながるから、妥協してでも規格を発展させようとする力が働くんだろうね。
      メールはそれがない。

    • by Anonymous Coward

      それでも各社ばらばら、囲い込み、非互換、相互やり取り不要、プロプラソフトのみ…
      という悲惨な状態のチャットプロトコルに比べれば数段まし。
      多少信頼できるエンドトゥーエンド暗号化もできるし。

    • by Anonymous Coward

      なんか今「LINEでメール来て」って特に違和感ないらしいです。新しいプロトコルって…

      • by Anonymous Coward

        プロトコルって条約だから、独自規格だと意味不明になっちゃいます。ツイッターからラインをフェイスブックに送れるようになれば、そりゃ、新時代の条約として認めてもいいですよ。

        • by Anonymous Coward

          弱者同士協力して、LINEとWeChatとKAKAOTALKなんかが相互に送受信できるようにはあり得そうだけど、
          Facebook、Whatsappなんかが乗ってくるとは到底思えないしなぁ。あ、この2つ同士だけならあり得るね。
          てか、Instagramも独自のメッセンジャーをテスト中とか。Facebookはどうしたいだろう。

          • by Anonymous Coward

            弱者同士とは言うが、国を限定すれば最凶なんだがな
            WeChatは中国国内では唯一のメッセージサービス(他はブロックされてるw)だし
            LINEも日本では強い、個人的にはゴミのようにゴテゴテ機能を付けずWhats appを見習えと思う
            ってことで、その地域に限って言えば譲歩する理由はないんだよ
            そもそもWeChatはブロック掛けられてるサービスと連携できない(LINEですら金盾ブロック対象)

        • by Anonymous Coward

          おいおい、独自規格でもプロトコルはあるぞ。

          英語のprotocolには条約という意味もあるけど、この場合はどちらかという外交儀礼(一連の手順)のほうだ。

        • by Anonymous Coward

          > プロトコルって条約だから、

          プロトコルを「条約」と訳すのは違和感があるなあ。その意味での適切な訳語としては議定書。主に国際会議の合意内容や決議、条約(treaty)の細目や付帯文書を指す。

          ただ、コンピュータ用語としてのprotocolが議定書の意味から派生したかは、どうだろう。protocolには外交儀礼なんて意味があるし、実施計画なんて意味もある。こっち方面じゃないかな。特に儀礼、「守らなくても紛争になる事は無いんだが、サクっと無視されて、何もなし得ない」の様な。

      • by Anonymous Coward

        電子「メール」の一種でしょう。
        手紙といったら何でもSMTPですか?

    • by Anonymous Coward

      メールが衰退したのは囲い込みの問題というより
      スパムが酷すぎた上にユーザ側自衛手段がない
      (迷惑メールフィルタは既に受信してしまってるから)
      ただ、薄いつながりのサービスとの連絡用には相変わらず有用だよ
      LINEとか双方ともLINEやってなきゃつながれないし

  • C言語系の言語だと NUL (\x00) を文字列の終了とみなして勝手に処理を打ち切るとか色々問題起こるので、NULLバイトとかASCIIの制御文字はバリエーションで弾くのが常識だと思ってたけど、いまだにこんなレベルの低い脆弱性が主要MUAにあったとは驚き。

    今はどうだか知らんが、10年ぐらい前はphpでもC言語系の非バイナリセーフ関数が入り乱れてて ereg() ですらNUL文字以降が無視されたからバリエーション回避に悪用されたし、ディレクトリトラバーサルもやり放題だったから、入力値は受け取った時点で \x00 が含まれていないことをバイナリセーフ関数で確認するのが常識だった。NULバイト対策をやらないと掲示板とかのメールフォームレベルのphpスクリプトですらクラッカーに荒らされて滅茶苦茶にされた時代があった。

    なのに、最近の若いプログラマーときたら、フレームワークにばっか頼っててC言語の基礎の基礎(ほんとの入門レベル)すら理解していないから、NULバイトを非バイナリセーフ関数にぶち込むような馬鹿な真似を平気でするのだろう。

    特に Thunderbird はメールヘッダーのNULバイトを排除しないのはMTAの責任だと主張して、脆弱性を修正しないことを決定する始末で恥の上塗りをしているようだけど、外部から受け取った文字列のNULバイトを排除していないとなると、C言語系の言語ではあらゆる関数でNULバイト問題が生じるので、表示偽装に留まらずこれから致命的な脆弱性が複数発見されていくことになるだろう。

    • あまりにもレベルの低い、C言語入門レベルの知識が無いことに起因する脆弱性である根拠を書いとく。

      From: =?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@example.com

      というヘッダーがあると、DKIMやSenderIDの検証時には example.com が送信元だと判断され、「example.com」に対応する電子署名があれば正規のメールだと認証される。

      From には差出人名(日本語など)も入っているので当然表示前には、上記ヘッダーを Base64 デコードされる。すると、

      From: potus@whitehouse.gov\0(potus@whitehouse.gov)@example.com

      となる。「\0」はアスキーの NUL バイトなんだけど、その処理系の関数がバイナリセーフでないC言語系関数だと \0 以降は無視される。結果、

      From: potus@whitehouse.gov

      になり、example.com から送信されたメール (送信元はDKIM署名等で認証)なのに、potus@whitehouse.gov からのメールだと表示される。

      これを Mozilla Thunderbird は、MTA の問題だという馬鹿な主張をしている。バイナリセーフでない関数に信頼できないデータを突っ込む前に、バイナリセーフ関数で NUL バイトその他の制御コードをバリデーションするべき。

      親コメント
      • MIME屋さん的視点からコメントすると、local-part は RFC2047(RFC1342,RFC1522) の拡張の対象ではないので

        From: =?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@example.com

        これを

        From: potus@whitehouse.gov\0(potus@whitehouse.gov)@example.com

        とデコートするのがそもそも間違い。

        親コメント
        • by Anonymous Coward

          なるほど
          じゃあ Thunderbird 52.5.0 の実装は二重に間違いなんですね

      • by Anonymous Coward

        え、そういう話なの?
        じゃあ制御文字が挿入されているのはエンコード後じゃなくて、エンコード前じゃないか。

    • 何のバリエーションなのかと思ったらひょっとしてバリデーションですかね…

      NULなんて言語(ライブラリ)で面倒見るべきってのは
      いうてもまぁ妥当なんじゃないかな…
      「プログラマが注意深くなければ間違う」なんて命令自体がおかしいのよやっぱ

      親コメント
      • 何のバリエーションなのかと思ったらひょっとしてバリデーションですかね…

        IMEで「バリ」と打った時の予測候補を信頼したら、文脈上誤った文字列がスラド投稿フォームにインジェクションされてしまったようです。IMEの飼い主としてお詫びします。

        NULなんて言語(ライブラリ)で面倒見るべきってのはいうてもまぁ妥当なんじゃないかな…

        使おうとする関数がバイナリセーフかを確認するのはプログラマーの責任だと思います。それが面倒なら、すべての関数がバイナリセーフである言語やライブラリを使うべきでしょう。

        親コメント
        • > 使おうとする関数がバイナリセーフかを確認するのはプログラマーの責任だと思います。それが面倒なら、すべての関数がバイナリセーフである言語やライブラリを使うべきでしょう。

          「プログラマの責任だからやるべきだ」
          てのはまぁわかりますが、
          「やるべきだからやるのだ」が通らないだけの量、
          これはコードの量であったり、必要なプログラマの数であったり、
          になってんじゃないですかねと言う感じです

          ベテランプロが知り尽くした言語で戦ってれば安全率は高いでしょうが、
          トータルの生産量が膨大なら結局ミスは出ます。

          「考えるのが面倒だからそういう言語は使わない」ではなく
          「考えるのが面倒なそういう言語は撲滅すべき」なんかなと思います。

          答えがある話じゃないですけどね…

          親コメント
          • by Anonymous Coward

            アセンブリ言語は考えるのが面倒だから撲滅すべきでしょうか?
            目的や状況に応じて言語を選べば良いのであって、特定の目的や状況に合わないからといって、何か言語を撲滅すべきという考えには全く賛同できません。

            • by Anonymous Coward

              撲滅もなにもアセンブリ言語って全ての根幹みたいなものだしなあ
              厳密には機械語だけど、その命令セットを単語に置き換えた以外はほぼ機械語だし
              良いとか悪いとか以前に全てのプログラムは機械語(アセンブリ言語)に通じてるから無くしようがない
              適材適所とは違う次元のものになるかと思います

        • 複数あるであろう予測候補からどれを選択するか、よく確認するのは他人に向けた文章を書く人の責任だと思います。
          それが面倒なら、IMEなど使わないで一文字一文字入力すべきでしょう。

          親コメント
          • by Anonymous Coward

            「IMEなど使わないで一文字一文字入力」って、これ [googleblog.com]のことですかね?

        • by Anonymous Coward

          日本では、開発経験のない管理職とか、こういうこと言っちゃう人っているよね。

          >使おうとする関数がバイナリセーフかを確認するのはプログラマーの責任だと思います。
          「バグを出さないのはプログラマーの責任だと思います。」YES

          「では対策は?」「バグを出すな」「それだけ?」「それだけ!」
          #後藤さんかよ。

          >それが面倒なら、すべての関数がバイナリセーフである言語やライブラリを使うべきでしょう。
          「バイナリセーフな言語やライブラリにバグがないことを確認するのはプログラマの責任だと思います」
          以下、無限ループ

      • by Anonymous Coward

        そういえば隣の部署の人たちがいつもバリエーションって言ってて
        バリデーションの間違いじゃないかといつも気になってる。

    • WIREDの記事 [wired.com]が更新されてコメントが出ています。

      (On Wednesday, a Thunderbird developer Jörg Knobloch wrote to WIRED to note that Thunderbird will make a patch avaiable in the next 24 hours.)

      パッチは出ているんでしょうか?

      親コメント
    • by Anonymous Coward

      もうおじいちゃんたら、杜撰なストリング処理によるバグなんてそれこそMorris wormの時代から日常茶飯事だったじゃないですか。
      最近の若い子たちが特にダメなわけじゃないですよ。

    • 8月ごろから最近、キャリア側のメールフィルタをすり抜けるSPAMが急増したので
      なんでか?とおもったら そういうことでした。

    • by Anonymous Coward

       Mozilla Thunderbird に何を期待しているのだ?

       他の物ならともかく、他者とのやりとりをするためのアプリなのに、分割メール対応から
      メールヘッダー対応その他で「相手に合わせない」と決めてきたような奴らが作ってるんだぞ。
      まともなレベルのものを作れると期待する方がおかしい。

  • by Anonymous Coward on 2017年12月08日 18時23分 (#3326124)

    メールのウィルス対策って、プロバイダのメールサーバでやってもらった方が、安心感がある。
    プロバイダのメールサーバの段階でそういった危険なものを排除してもらえるなら、追加料金も安いものだ。

    • by Anonymous Coward

      プロバイダのメールサーバの段階でそういった危険なものを排除してもらえるなら、追加料金も安いものだ。

      プロバイダ < ではログにあった単純所持案件で危険人物込みでの排除ということで

      # フィルタリングするってのはそこまで見られるってーこった

  • by Anonymous Coward on 2017年12月08日 22時36分 (#3326244)

    ぬるぽ¥0

    • by Anonymous Coward

        Λ_Λ  \\
        ( ・∀・)   | | ガッ
       と    )    | |
         Y /ノ    人
          / )    _Λ∩
        _/し' //. V`Д´)/
       (_フ彡        / ← #3326244

      2017年にもなってヌルバイト攻撃なんてタイムマシンに乗った気分
      20年前の脆弱性ですからね

      • by Anonymous Coward

        いつまでたっても高水準言語では基幹を構成しきれないということですね。

  • by Anonymous Coward on 2017年12月09日 10時01分 (#3326408)

    淡々と対応すればいいのに、「Mailsploit」なんて大げさな名前を付け、ドメインまで取ってウェブサイトを作り、Back to the Future のロゴをパクり、映画の映像を埋め込み、「俺はすごい脆弱性を見つけちまったぜ!」的な煽ってる感満載。鼻息荒すぎでしょ。
    https://www.mailsploit.com/index [mailsploit.com]

    • by Anonymous Coward

      でも自分の息子がいじめられてたら集団で学校で話し合いするんでしょ。

      • by Anonymous Coward

        自分の息子になりすまして、悪事に加担させられるのを防ぐっていう話じゃなかったっけ?

    • by Anonymous Coward

      POODLEを大々的に喧伝したGoogle先生をディスるのはやめるんだ。

typodupeerror

物事のやり方は一つではない -- Perlな人

読み込み中...