Exim4はSMTP-AUTH over TLSをサポートしない

セキュリティ

exim4の実装は、他のSMTPサーバーにSMTP-AUTHでログインする際に、TLSのCommon Nameではなく逆引きドメイン名に対応する認証情報を送ってしまう。

本来フル機能のMTAのexim4が、二つ以上の異なるスマートホストに対する認証情報を持つ、というレアなケースでは、あるホストが他のホストに送られるべき認証情報を詐取することが出来る。

実際には複数のスマートホストを設定することは稀だろうから、現実にこの問題が脅威となることは考えにくい。単一の（あるいは同じ管理者が運用する）SMTP-AUTHサーバーに依存しているのであれば、サーバーの逆引き名が変化しても、そのSMTP-AUTHアカウントが使えなくなるだけだ。

ただし、eximが保持するパスワードがTLSで正しく保護されていないのは事実で、検証されたドメインをまたぐ情報漏洩を許す実装は潜在的に脆弱であると見るべきだ。 万一、exim4に複数のアカウントのパスワードを持たせている場合には、一つを残して他を削除することが望ましい。

SSL/TLSが保証するのは「接続先が、証明書の持ち主である」ということだけ。TLS接続を確立できても、証明書と無関係なドメインの情報を送信してしまうのでは意味が無い。

攻撃シナリオ

eximがそれ自体では直接メールを送信せず、リモートの二つのスマートホスト（フル機能のMTA） somehost.example.com と otherhost.example.net をTLS接続で利用している。 設定時には、DNSレコードが

somehost.example.com.  A  10.1.2.3
otherhost.example.net  A  10.4.5.6

とその逆引きだったとする。

Debianのドキュメントにならえば、パスワードが書かれる/etc/exim/passwd.clientは次のようになる。

somehost.example.com:someuser:somepasswd
otherhost.example.net:otheruser:otherpasswd

設定した時点では、二つのサーバーはそれぞれ固有の証明書を持っているので、証明書を検証することで、目的のホストに正しく接続したことを保証できる。

ここで、

  • otherhostが乗っ取られたが、まだ証明書は失効していない
  • DNSインジェクションなどで経路を操作可能

という条件がそろうと、otherhostを掌握した攻撃者はeximが持つ、somehost用の認証情報を盗むことが出来る。

例えば、次のようにな毒入れをして、otherhostを経由するメールが来るのを待つ。

otherhost.example.net.  CNAME  somehost.example.com.
6.5.4.10.in-addr.arpa.  PTR somehost.example.com.
somehost.example.com.   A 10.4.5.6    ; inject it

eximはTLS接続先のCommonNameではなく、逆引きしたドメイン名を用いてSMTP-AUTHサーバーを識別するので、otherhost.example.net に正しくTLS接続し、パラノイアチェックしているにも関わらず、somehost.example.comの認証情報が送信される。 そしてSMTP-AUTHは通常（TLSで保護されるので）平文パスワードが用いられる。