アカウント名:
パスワード:
C言語系の言語だと NUL (\x00) を文字列の終了とみなして勝手に処理を打ち切るとか色々問題起こるので、NULLバイトとかASCIIの制御文字はバリエーションで弾くのが常識だと思ってたけど、いまだにこんなレベルの低い脆弱性が主要MUAにあったとは驚き。
今はどうだか知らんが、10年ぐらい前はphpでもC言語系の非バイナリセーフ関数が入り乱れてて ereg() ですらNUL文字以降が無視されたからバリエーション回避に悪用されたし、ディレクトリトラバーサルもやり放題だったから、入力値は受け取った時点で \x00 が含まれていないことをバイナリセーフ関数で確認するのが常
あまりにもレベルの低い、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) の拡張の対象ではないので
これを
とデコートするのがそもそも間違い。
なるほどじゃあ Thunderbird 52.5.0 の実装は二重に間違いなんですね
え？「DKIMやSenderIDの検証時には example.com が送信元だと判断」が間違い、ってことじゃないの？
え、そういう話なの？じゃあ制御文字が挿入されているのはエンコード後じゃなくて、エンコード前じゃないか。
(ここにつけさせていただきます)
メールヘッダに"様"とか役職名を入れるべきというマナー講師をやっつけたい(ひとりごと
本当に「あまりにもレベルが低い」と思ってるんだったら、パッチを書いて送れば済む話でしょ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
Mozilla Thunderbird は MTA が悪いから対策する気がないと表明 (スコア:0)
C言語系の言語だと NUL (\x00) を文字列の終了とみなして勝手に処理を打ち切るとか色々問題起こるので、NULLバイトとかASCIIの制御文字はバリエーションで弾くのが常識だと思ってたけど、いまだにこんなレベルの低い脆弱性が主要MUAにあったとは驚き。
今はどうだか知らんが、10年ぐらい前はphpでもC言語系の非バイナリセーフ関数が入り乱れてて ereg() ですらNUL文字以降が無視されたからバリエーション回避に悪用されたし、ディレクトリトラバーサルもやり放題だったから、入力値は受け取った時点で \x00 が含まれていないことをバイナリセーフ関数で確認するのが常
Re:Mozilla Thunderbird は MTA が悪いから対策する気がないと表明 (スコア:4, 参考になる)
あまりにもレベルの低い、C言語入門レベルの知識が無いことに起因する脆弱性である根拠を書いとく。
というヘッダーがあると、DKIMやSenderIDの検証時には example.com が送信元だと判断され、「example.com」に対応する電子署名があれば正規のメールだと認証される。
From には差出人名（日本語など）も入っているので当然表示前には、上記ヘッダーを Base64 デコードされる。すると、
となる。「\0」はアスキーの NUL バイトなんだけど、その処理系の関数がバイナリセーフでないC言語系関数だと \0 以降は無視される。結果、
になり、example.com から送信されたメール (送信元はDKIM署名等で認証）なのに、potus@whitehouse.gov からのメールだと表示される。
これを Mozilla Thunderbird は、MTA の問題だという馬鹿な主張をしている。バイナリセーフでない関数に信頼できないデータを突っ込む前に、バイナリセーフ関数で NUL バイトその他の制御コードをバリデーションするべき。
Re:Mozilla Thunderbird は MTA が悪いから対策する気がないと表明 (スコア:1)
MIME屋さん的視点からコメントすると、local-part は RFC2047(RFC1342,RFC1522) の拡張の対象ではないので
これを
とデコートするのがそもそも間違い。
Re: (スコア:0)
なるほど
じゃあ Thunderbird 52.5.0 の実装は二重に間違いなんですね
Re: (スコア:0)
え？
「DKIMやSenderIDの検証時には example.com が送信元だと判断」が間違い、ってことじゃないの？
Re: (スコア:0)
え、そういう話なの？
じゃあ制御文字が挿入されているのはエンコード後じゃなくて、エンコード前じゃないか。
Re: (スコア:0)
(ここにつけさせていただきます)
メールヘッダに"様"とか役職名を入れるべきというマナー講師をやっつけたい(ひとりごと
Re: (スコア:0)
本当に「あまりにもレベルが低い」と思ってるんだったら、パッチを書いて送れば済む話でしょ。