メールの送信者を偽装できる問題が見つかる、多数のメールクライアントが影響を受ける 16
ストーリー by hylom
ありそう 部門より
ありそう 部門より
非アスキー文字をメールのメッセージヘッダーに入れることで、メールの送信者を偽装できるという問題が見つかった。多くのメールクライアントがこの問題の影響を受け、本来の送信者でないメールアドレスなどを送信者として表示させることができるという（JPCERT/CC、INTERNET Watch、Security NEXT）。この問題はMailsploitなどと呼ばれているようだ。
電子メールのメッセージヘッダー内で非ASCII文字を利用したい場合、RFC1342で規定された方法でその文字をエンコードする。しかし、意図的に改行や制御文字などをエンコード後の文字列に挿入することでメールクライアントでのデコード処理に問題を発生させ、クライアント上でのメールアドレスの表示を別のものに差し替えることができるという。
JPERT/CCによると、Mac OS XのApple MailやWindowsのMail for Windows 10、Outlook 2016といった主要なメールクライアントのほとんどが影響を受けるようだ。いっぽうGmailははこの影響を受けないほか、Yahoo! Mailは修正が完了しているという。
メールの送信者は普通に偽装できるよね？ (スコア:1)
もともと脆弱なのに何が問題？と思ったけど、リンク先を見ると、DKIMの検証を回避できるってことなんですかね。
Re: (スコア:0)
携帯とかweb mailでメール使い始めた人は偽装ができるなんて考えたこともないと思う
Re: (スコア:0)
DMARC を通過できるので SPAM フィルターを容易に通過できる、というところが問題であるらしいです。
「サーバーの問題である」として修正しないことに決定したメールソフトが2つ、というのはまぁ
そもそも送信者の表示は信頼できないのでこれで動作が変わるのは本質的にはSPAM フィルターだけでしょ、
という論理でしょうね。
新しいプロトコルを (スコア:1, 興味深い)
メールの衰退を見ると、メッセージサービスを提供する各社の囲い込みが激しすぎて、利害調整に失敗しているように見える。実際、POP3もSMTPもIMAPも、読んでみると(今となっては)意味不明なレガシーを引き摺った酷い仕様だ。
脚立の上に梯子をかけるような仕様を捨て去って、マルチバイトを前提にスクラッチから設計すれば、もっと綺麗で堅牢なプロトコルが作れると思うんだけど、誰もそこには手が延ばせないんだな。
考えてみると、いろいろ批判されてるhtml5はわりと奇跡的なバランスの紆余曲折の結果で世に出てると思う。今のAmazonとGoogleがテレビ接続器の囲い込み合戦に必死になってるのとは対照的だ。それとも、ここから仲直りして、共通規格にできるんだろうか。
Re: (スコア:0)
なんだかんだ言っても、規格を更新することが業界全体の利益につながるから、妥協してでも規格を発展させようとする力が働くんだろうね。
メールはそれがない。
Mozilla Thunderbird は MTA が悪いから対策する気がないと表明 (スコア:1)
C言語系の言語だと NUL (\x00) を文字列の終了とみなして勝手に処理を打ち切るとか色々問題起こるので、NULLバイトとかASCIIの制御文字はバリエーションで弾くのが常識だと思ってたけど、いまだにこんなレベルの低い脆弱性が主要MUAにあったとは驚き。
今はどうだか知らんが、10年ぐらい前はphpでもC言語系の非バイナリセーフ関数が入り乱れてて ereg() ですらNUL文字以降が無視されたからバリエーション回避に悪用されたし、ディレクトリトラバーサルもやり放題だったから、入力値は受け取った時点で \x00 が含まれていないことをバイナリセーフ関数で確認するのが常識だった。NULバイト対策をやらないと掲示板とかのメールフォームレベルのphpスクリプトですらクラッカーに荒らされて滅茶苦茶にされた時代があった。
なのに、最近の若いプログラマーときたら、フレームワークにばっか頼っててC言語の基礎の基礎（ほんとの入門レベル）すら理解していないから、NULバイトを非バイナリセーフ関数にぶち込むような馬鹿な真似を平気でするのだろう。
特に Thunderbird はメールヘッダーのNULバイトを排除しないのはMTAの責任だと主張して、脆弱性を修正しないことを決定する始末で恥の上塗りをしているようだけど、外部から受け取った文字列のNULバイトを排除していないとなると、C言語系の言語ではあらゆる関数でNULバイト問題が生じるので、表示偽装に留まらずこれから致命的な脆弱性が複数発見されていくことになるだろう。
Re:Mozilla Thunderbird は MTA が悪いから対策する気がないと表明 (スコア:2)
何のバリエーションなのかと思ったらひょっとしてバリデーションですかね…
NULなんて言語(ライブラリ)で面倒見るべきってのは
いうてもまぁ妥当なんじゃないかな…
「プログラマが注意深くなければ間違う」なんて命令自体がおかしいのよやっぱ
Re:Mozilla Thunderbird は MTA が悪いから対策する気がないと表明 (スコア:1)
IMEで「バリ」と打った時の予測候補を信頼したら、文脈上誤った文字列がスラド投稿フォームにインジェクションされてしまったようです。IMEの飼い主としてお詫びします。
使おうとする関数がバイナリセーフかを確認するのはプログラマーの責任だと思います。それが面倒なら、すべての関数がバイナリセーフである言語やライブラリを使うべきでしょう。
Re:Mozilla Thunderbird は MTA が悪いから対策する気がないと表明 (スコア:2)
> 使おうとする関数がバイナリセーフかを確認するのはプログラマーの責任だと思います。それが面倒なら、すべての関数がバイナリセーフである言語やライブラリを使うべきでしょう。
「プログラマの責任だからやるべきだ」
てのはまぁわかりますが、
「やるべきだからやるのだ」が通らないだけの量、
これはコードの量であったり、必要なプログラマの数であったり、
になってんじゃないですかねと言う感じです
ベテランプロが知り尽くした言語で戦ってれば安全率は高いでしょうが、
トータルの生産量が膨大なら結局ミスは出ます。
「考えるのが面倒だからそういう言語は使わない」ではなく
「考えるのが面倒なそういう言語は撲滅すべき」なんかなと思います。
答えがある話じゃないですけどね…
Re:Mozilla Thunderbird は MTA が悪いから対策する気がないと表明 (スコア:1)
あまりにもレベルの低い、C言語入門レベルの知識が無いことに起因する脆弱性である根拠を書いとく。
というヘッダーがあると、DKIMやSenderIDの検証時には example.com が送信元だと判断され、「example.com」に対応する電子署名があれば正規のメールだと認証される。
From には差出人名（日本語など）も入っているので当然表示前には、上記ヘッダーを Base64 デコードされる。すると、
となる。「\0」はアスキーの NUL バイトなんだけど、その処理系の関数がバイナリセーフでないC言語系関数だと \0 以降は無視される。結果、
になり、example.com から送信されたメール (送信元はDKIM署名等で認証）なのに、potus@whitehouse.gov からのメールだと表示される。
これを Mozilla Thunderbird は、MTA の問題だという馬鹿な主張をしている。バイナリセーフでない関数に信頼できないデータを突っ込む前に、バイナリセーフ関数で NUL バイトその他の制御コードをバリデーションするべき。
Re: (スコア:0)
え、そういう話なの？
じゃあ制御文字が挿入されているのはエンコード後じゃなくて、エンコード前じゃないか。
Thunderbird開発者は24時間以内にパッチを用意すると表明 (スコア:1)
WIREDの記事 [wired.com]が更新されてコメントが出ています。
パッチは出ているんでしょうか？
Re:Thunderbird開発者は24時間以内にパッチを用意すると表明 (スコア:1)
情報ありがとうございます。
Mailsploit 脆弱性は 2017年8月21日 に Mozilla へ報告され「対応しない」という返答をもらった [google.com] ようですが、方針が変わったのですね。
Thunderbirdのアップデート機能からはまだパッチを受け取れないようですがそろそろ公開されるかもしれません。
Re: (スコア:0)
もうおじいちゃんたら、杜撰なストリング処理によるバグなんてそれこそMorris wormの時代から日常茶飯事だったじゃないですか。
最近の若い子たちが特にダメなわけじゃないですよ。
プロバイダのメールサービス (スコア:0)
メールのウィルス対策って、プロバイダのメールサーバでやってもらった方が、安心感がある。
プロバイダのメールサーバの段階でそういった危険なものを排除してもらえるなら、追加料金も安いものだ。
Re: (スコア:0)
プロバイダのメールサーバの段階でそういった危険なものを排除してもらえるなら、追加料金も安いものだ。
プロバイダ ＜ ではログにあった単純所持案件で危険人物込みでの排除ということで
# フィルタリングするってのはそこまで見られるってーこった