アカウント名:
パスワード:
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 バイ
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: (スコア:4, 参考になる)
あまりにもレベルの低い、C言語入門レベルの知識が無いことに起因する脆弱性である根拠を書いとく。
というヘッダーがあると、DKIMやSenderIDの検証時には example.com が送信元だと判断され、「example.com」に対応する電子署名があれば正規のメールだと認証される。
From には差出人名(日本語など)も入っているので当然表示前には、上記ヘッダーを Base64 デコードされる。すると、
となる。「\0」はアスキーの NUL バイ
Re: (スコア:1)
MIME屋さん的視点からコメントすると、local-part は RFC2047(RFC1342,RFC1522) の拡張の対象ではないので
これを
とデコートするのがそもそも間違い。
Re: (スコア:0)
なるほど
じゃあ Thunderbird 52.5.0 の実装は二重に間違いなんですね
Re:Mozilla Thunderbird は MTA が悪いから対策する気がないと表明 (スコア:0)
え?
「DKIMやSenderIDの検証時には example.com が送信元だと判断」が間違い、ってことじゃないの?