アカウント名:
パスワード:
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) の拡張の対象ではないので
これを
とデコートするのがそもそも間違い。
なるほどじゃあ Thunderbird 52.5.0 の実装は二重に間違いなんですね
え？「DKIMやSenderIDの検証時には example.com が送信元だと判断」が間違い、ってことじゃないの？
え、そういう話なの？じゃあ制御文字が挿入されているのはエンコード後じゃなくて、エンコード前じゃないか。
(ここにつけさせていただきます)
メールヘッダに"様"とか役職名を入れるべきというマナー講師をやっつけたい(ひとりごと
本当に「あまりにもレベルが低い」と思ってるんだったら、パッチを書いて送れば済む話でしょ。
何のバリエーションなのかと思ったらひょっとしてバリデーションですかね…
NULなんて言語(ライブラリ)で面倒見るべきってのはいうてもまぁ妥当なんじゃないかな…「プログラマが注意深くなければ間違う」なんて命令自体がおかしいのよやっぱ
IMEで「バリ」と打った時の予測候補を信頼したら、文脈上誤った文字列がスラド投稿フォームにインジェクションされてしまったようです。IMEの飼い主としてお詫びします。
NULなんて言語(ライブラリ)で面倒見るべきってのはいうてもまぁ妥当なんじゃないかな…
使おうとする関数がバイナリセーフかを確認するのはプログラマーの責任だと思います。それが面倒なら、すべての関数がバイナリセーフである言語やライブラリを使うべきでしょう。
> 使おうとする関数がバイナリセーフかを確認するのはプログラマーの責任だと思います。それが面倒なら、すべての関数がバイナリセーフである言語やライブラリを使うべきでしょう。
「プログラマの責任だからやるべきだ」てのはまぁわかりますが、「やるべきだからやるのだ」が通らないだけの量、これはコードの量であったり、必要なプログラマの数であったり、になってんじゃないですかねと言う感じです
ベテランプロが知り尽くした言語で戦ってれば安全率は高いでしょうが、トータルの生産量が膨大なら結局ミスは出ます。
「考えるのが面倒だからそういう言語は使わない」ではなく「考えるのが面倒なそういう言語は撲滅すべき」なんかなと思います。
答えがある話じゃないですけどね…
アセンブリ言語は考えるのが面倒だから撲滅すべきでしょうか？目的や状況に応じて言語を選べば良いのであって、特定の目的や状況に合わないからといって、何か言語を撲滅すべきという考えには全く賛同できません。
撲滅もなにもアセンブリ言語って全ての根幹みたいなものだしなあ厳密には機械語だけど、その命令セットを単語に置き換えた以外はほぼ機械語だし良いとか悪いとか以前に全てのプログラムは機械語（アセンブリ言語）に通じてるから無くしようがない適材適所とは違う次元のものになるかと思います
「C言語」とかそれに類する低級言語を安全に使うには、ベテランプロである必要があるんです言語を知り尽くさないと安全に使えないけど、その代わりにマシン後に近くて高速なんです
それができないなら高級言語使っててください
低級言語の世界を知らない人向けにたとえ話をしましょうか？
言語仕様を知り尽くしていない人がWebアプリでSQL使うなら、SQLインジェクションを防ぐためにプレースホルダを使うべきですパフォーマンスが悪いのは我慢してAWSに課金して回避してください
高速化やクエリキャッシュ最適化などを目的としてプレースホルダを使わずに独自のエスケープ処理をしたいのなら言語仕様を知り尽くして絶対に穴がないようにしてください
それだけのことです
別に数年単位の話じゃなくて方向性の話ですがね、究極のとこアセンブラだのC言語なんてのは人間が使うのは止めれば良いんですよ
高速だのなんだのはすべて広義のコンパイラが解決すればいい話ですやって出来ない、そんなこと出来る日が来ない、そんな問題でも無いのにCを引きずるなんて必要は無いでしょ低級言語なんてのは博物館と研究所にあれば十分だと思います
現状の問題は「言語仕様を知り尽くし」てなくても生SQLが発行出来る言語がゴロゴロしてること、そのためそんな言語が新規開発に選ばれることだとおもいますね
言語を開発している人数とその質、言語を使う側の人数とその人数の多さから来る相対的に低くなる質を考えたとき、「コードを書く側がしっかりしてりゃ良い」という言説にはうーん、与しかねます
そんなに低級言語が必要ですか?login.cの話とか思い出すとCなんてとっくの昔に十二分に高級化しててブラックボックス触ってるも同然だと思いますけど
一応書いときますとCメインで組み込みもやってますよぼくは高速化のためにアセンブリいじることも度々ですでも新しい言語やライブラリを使うときにゼロ終端文字列について考えたくないし、考えさせるべきで無いと思ってます
若者はもっと目的だけを考えていて欲しいのです
なるほど素晴らしい理念だと思います
確かに言語側を改善してプログラマが楽できた方が良いですね
複数あるであろう予測候補からどれを選択するか、よく確認するのは他人に向けた文章を書く人の責任だと思います。それが面倒なら、IMEなど使わないで一文字一文字入力すべきでしょう。
「IMEなど使わないで一文字一文字入力」って、これ [googleblog.com]のことですかね？
日本では、開発経験のない管理職とか、こういうこと言っちゃう人っているよね。
＞使おうとする関数がバイナリセーフかを確認するのはプログラマーの責任だと思います。「バグを出さないのはプログラマーの責任だと思います。」YES
「では対策は？」「バグを出すな」「それだけ？」「それだけ！」＃後藤さんかよ。
＞それが面倒なら、すべての関数がバイナリセーフである言語やライブラリを使うべきでしょう。「バイナリセーフな言語やライブラリにバグがないことを確認するのはプログラマの責任だと思います」以下、無限ループ
元コメで誤変換やらかしているように、人間誰しも間違いはあるのですそれを「飼い主としてお詫びする」などと、さも自分は悪くないように振る舞う人に責任どうこう言われても困るのです
そういえば隣の部署の人たちがいつもバリエーションって言っててバリデーションの間違いじゃないかといつも気になってる。
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.)
パッチは出ているんでしょうか？
情報ありがとうございます。Mailsploit 脆弱性は 2017年8月21日 に Mozilla へ報告され「対応しない」という返答をもらった [google.com] ようですが、方針が変わったのですね。Thunderbirdのアップデート機能からはまだパッチを受け取れないようですがそろそろ公開されるかもしれません。
もうおじいちゃんたら、杜撰なストリング処理によるバグなんてそれこそMorris wormの時代から日常茶飯事だったじゃないですか。最近の若い子たちが特にダメなわけじゃないですよ。
８月ごろから最近、キャリア側のメールフィルタをすり抜けるSPAMが急増したのでなんでか？とおもったら そういうことでした。
Mozilla Thunderbird に何を期待しているのだ？
他の物ならともかく、他者とのやりとりをするためのアプリなのに、分割メール対応からメールヘッダー対応その他で「相手に合わせない」と決めてきたような奴らが作ってるんだぞ。まともなレベルのものを作れると期待する方がおかしい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
Mozilla Thunderbird は MTA が悪いから対策する気がないと表明 (スコア:0)
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 が悪いから対策する気がないと表明 (スコア: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)
本当に「あまりにもレベルが低い」と思ってるんだったら、パッチを書いて送れば済む話でしょ。
Re:Mozilla Thunderbird は MTA が悪いから対策する気がないと表明 (スコア:2)
何のバリエーションなのかと思ったらひょっとしてバリデーションですかね…
NULなんて言語(ライブラリ)で面倒見るべきってのは
いうてもまぁ妥当なんじゃないかな…
「プログラマが注意深くなければ間違う」なんて命令自体がおかしいのよやっぱ
Re:Mozilla Thunderbird は MTA が悪いから対策する気がないと表明 (スコア:1)
IMEで「バリ」と打った時の予測候補を信頼したら、文脈上誤った文字列がスラド投稿フォームにインジェクションされてしまったようです。IMEの飼い主としてお詫びします。
使おうとする関数がバイナリセーフかを確認するのはプログラマーの責任だと思います。それが面倒なら、すべての関数がバイナリセーフである言語やライブラリを使うべきでしょう。
Re:Mozilla Thunderbird は MTA が悪いから対策する気がないと表明 (スコア:3)
> 使おうとする関数がバイナリセーフかを確認するのはプログラマーの責任だと思います。それが面倒なら、すべての関数がバイナリセーフである言語やライブラリを使うべきでしょう。
「プログラマの責任だからやるべきだ」
てのはまぁわかりますが、
「やるべきだからやるのだ」が通らないだけの量、
これはコードの量であったり、必要なプログラマの数であったり、
になってんじゃないですかねと言う感じです
ベテランプロが知り尽くした言語で戦ってれば安全率は高いでしょうが、
トータルの生産量が膨大なら結局ミスは出ます。
「考えるのが面倒だからそういう言語は使わない」ではなく
「考えるのが面倒なそういう言語は撲滅すべき」なんかなと思います。
答えがある話じゃないですけどね…
Re: (スコア:0)
アセンブリ言語は考えるのが面倒だから撲滅すべきでしょうか？
目的や状況に応じて言語を選べば良いのであって、特定の目的や状況に合わないからといって、何か言語を撲滅すべきという考えには全く賛同できません。
Re: (スコア:0)
撲滅もなにもアセンブリ言語って全ての根幹みたいなものだしなあ
厳密には機械語だけど、その命令セットを単語に置き換えた以外はほぼ機械語だし
良いとか悪いとか以前に全てのプログラムは機械語（アセンブリ言語）に通じてるから無くしようがない
適材適所とは違う次元のものになるかと思います
Re: (スコア:0)
「C言語」とかそれに類する低級言語を安全に使うには、ベテランプロである必要があるんです
言語を知り尽くさないと安全に使えないけど、その代わりにマシン後に近くて高速なんです
それができないなら高級言語使っててください
低級言語の世界を知らない人向けにたとえ話をしましょうか？
言語仕様を知り尽くしていない人がWebアプリでSQL使うなら、SQLインジェクションを防ぐためにプレースホルダを使うべきです
パフォーマンスが悪いのは我慢してAWSに課金して回避してください
高速化やクエリキャッシュ最適化などを目的としてプレースホルダを使わずに独自のエスケープ処理をしたいのなら
言語仕様を知り尽くして絶対に穴がないようにしてください
それだけのことです
Re:Mozilla Thunderbird は MTA が悪いから対策する気がないと表明 (スコア:2)
別に数年単位の話じゃなくて方向性の話ですがね、
究極のとこアセンブラだのC言語なんてのは人間が使うのは止めれば良いんですよ
高速だのなんだのはすべて広義のコンパイラが解決すればいい話です
やって出来ない、そんなこと出来る日が来ない、
そんな問題でも無いのにCを引きずるなんて必要は無いでしょ
低級言語なんてのは博物館と研究所にあれば十分だと思います
現状の問題は「言語仕様を知り尽くし」てなくても生SQLが発行出来る言語がゴロゴロしてること、
そのためそんな言語が新規開発に選ばれることだとおもいますね
言語を開発している人数とその質、言語を使う側の人数とその人数の多さから来る相対的に低くなる質を考えたとき、
「コードを書く側がしっかりしてりゃ良い」という言説にはうーん、与しかねます
そんなに低級言語が必要ですか?
login.cの話とか思い出すとCなんてとっくの昔に
十二分に高級化しててブラックボックス触ってるも同然だと思いますけど
一応書いときますとCメインで組み込みもやってますよぼくは
高速化のためにアセンブリいじることも度々です
でも新しい言語やライブラリを使うときにゼロ終端文字列について考えたくないし、考えさせるべきで無いと思ってます
若者はもっと目的だけを考えていて欲しいのです
Re: (スコア:0)
なるほど
素晴らしい理念だと思います
確かに言語側を改善してプログラマが楽できた方が良いですね
Re:Mozilla Thunderbird は MTA が悪いから対策する気がないと表明 (スコア:1)
複数あるであろう予測候補からどれを選択するか、よく確認するのは他人に向けた文章を書く人の責任だと思います。
それが面倒なら、IMEなど使わないで一文字一文字入力すべきでしょう。
Re: (スコア:0)
「IMEなど使わないで一文字一文字入力」って、これ [googleblog.com]のことですかね？
Re: (スコア:0)
日本では、開発経験のない管理職とか、こういうこと言っちゃう人っているよね。
＞使おうとする関数がバイナリセーフかを確認するのはプログラマーの責任だと思います。
「バグを出さないのはプログラマーの責任だと思います。」YES
「では対策は？」「バグを出すな」「それだけ？」「それだけ！」
＃後藤さんかよ。
＞それが面倒なら、すべての関数がバイナリセーフである言語やライブラリを使うべきでしょう。
「バイナリセーフな言語やライブラリにバグがないことを確認するのはプログラマの責任だと思います」
以下、無限ループ
Re: (スコア:0)
元コメで誤変換やらかしているように、人間誰しも間違いはあるのです
それを「飼い主としてお詫びする」などと、さも自分は悪くないように振る舞う人に責任どうこう言われても困るのです
Re: (スコア:0)
そういえば隣の部署の人たちがいつもバリエーションって言ってて
バリデーションの間違いじゃないかといつも気になってる。
Thunderbird開発者は24時間以内にパッチを用意すると表明 (スコア:1)
WIREDの記事 [wired.com]が更新されてコメントが出ています。
パッチは出ているんでしょうか？
Re:Thunderbird開発者は24時間以内にパッチを用意すると表明 (スコア:1)
情報ありがとうございます。
Mailsploit 脆弱性は 2017年8月21日 に Mozilla へ報告され「対応しない」という返答をもらった [google.com] ようですが、方針が変わったのですね。
Thunderbirdのアップデート機能からはまだパッチを受け取れないようですがそろそろ公開されるかもしれません。
Re: (スコア:0)
もうおじいちゃんたら、杜撰なストリング処理によるバグなんてそれこそMorris wormの時代から日常茶飯事だったじゃないですか。
最近の若い子たちが特にダメなわけじゃないですよ。
Re:ちんぽこぴーん！ (スコア:0)
８月ごろから最近、キャリア側のメールフィルタをすり抜けるSPAMが急増したので
なんでか？とおもったら そういうことでした。
Re: (スコア:0)
Mozilla Thunderbird に何を期待しているのだ？
他の物ならともかく、他者とのやりとりをするためのアプリなのに、分割メール対応から
メールヘッダー対応その他で「相手に合わせない」と決めてきたような奴らが作ってるんだぞ。
まともなレベルのものを作れると期待する方がおかしい。