パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

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

  • by Anonymous Coward

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

    • by Anonymous Coward

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

      • by Anonymous Coward on 2017年12月08日 21時00分 (#3326196)

        いや、全然違うでしょ。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

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

                何言ってんだか
                メールサーバーでDKIM認証されたメールアドレス(From)のドメインが srad.jp なのに
                クライアントの脆弱性(BASE64エンコードに含んだヌルバイトを使用)で hoge.go.jp にできるってのが今回の脆弱性
                つまりクライアントの問題

              • by Anonymous Coward

                #3326196もサーバのどういう問題か、しか話してないと思うけど

              • by Anonymous Coward

                能動的に偽装するやつはクライアント自体を偽装する
                偽装しないようなやつはそもそもそんな脆弱性を使おうともしない
                別のプログラムが勝手に情報を偽装するんならそれはマルウェア
                よって、クライアント側のただの不具合であって脆弱性というのは何か違う

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

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

            親コメント
            • by Anonymous Coward

              書留も、内容証明すらも、送信元の確認なんて行われませんよ。

              実在性確認も、発送者が本人であるかの確認も、どちらもね。

              # まあ、それを言い出すと「メール送信元は適正でも、そのPCを操作したのが本人である証拠はない」みたいな物言いもできちゃうけど

              • by Anonymous Coward

                自宅に送られてきた、若干センシティブな書留を何回か職場に転送してもらいました。
                転送依頼には、本人確認なんてなかったとおもいます。
                配達員も、まっとうな相手が受け取ったかどうかなんて確認してくれませんでした。

          • by Anonymous Coward

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

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

処理中...