「sendmail 8.12.xにDNS経由で任意コードが実行可能な穴」記事へのコメント

実行可能かどうかはまだ分っていないはず

[Technical Type (3408)]

アナウンス [sendmail.org]に

Note that only FEATURE(`enhdnsbl') uses a DNS map. We do not have an assessment whether this problem is exploitable, however, if you use a DNS map and an 8.12 version older than 8.12.9, then either upgrade (strongly recommended) or apply the trivial patch given below.

とある通りですが、自分の Sendmail が DNSMAP オプション付きでコンパイルされているかどうか、また enhdnsbl 機能を使っているかどうかも判らない人がメールマスターをやっているなら、今回のはバグには違いないので

ただのちゃちゃ

[Anonymous Coward]

セキュリティーに敏感でスキルのあるメールマスターならとっくに qmail に移行すべきです

確かに qmail の方が問題は少ないかも

[Technical Type (3408)]

おっしゃる通りですね。最近出たのは7月15日の QMail-SMTPD-Auth True Program Remote E-Mail Vulnerability [securityfocus.com] ぐらいだしね。

Re:確かに qmail の方が問題は少ないかも

[lucky (14762)]

それは、単なるユーザのパッチなので qmail とはいえないのでは？ qmail 自体は、少なくとも 1997 年以降、セキュリティーホールは発見されていないようですけど。このページ The qmail security guarantee [cr.yp.to] では、

In March 1997, I offered $500 to the first person to publish a verifiable security hole in the latest version of qmail: for example, a way for a user to exploit qmail to take over another account.

My offer still stands. N

Re:確かに qmail の方が問題は少ないかも

[Technical Type (3408)]

設定をミスっても Open Relay に悪用されないようにするための非公式パッチなようですが、 qmail は設定ミスると Open Relay に悪用されるのを脆弱性と言わないなら、それはそれで一つの考えかも。

Re:確かに qmail の方が問題は少ないかも

[akahige (16299)]

QMail-SMTPD-AuthはSMTP-Authの機能を後付けするパッチかと。

qmailはデフォルト設定ではオープンリレーは許可しませんし。
よって、自宅のマシンからプロバイダ経由で会社のメールサーバにつないで送信することも不可能。
#自宅に固定IPとかを持っていれば別ですが・・・

まあ、それだと不便だから件のパッチのようなものが出てくるわけですけどね。

Re:確かに qmail の方が問題は少ないかも

[Anonymous Coward]

qmail って rcpthosts を作らないとオープンリレーになるよね。
わざわざファイル作らなきゃいけないのをデフォルトとは言わないのでは？

ORDB のサーバ別統計 [ordb.org] 見ると、決して qmail の登録が
少ないわけじゃないと思う。

Re:確かに qmail の方が問題は少ないかも

[IKEDA Kenji (4659)]

./config で control/locals と共に FQDN がセットされるはずです。 もしや、./config してない環境で qmail を動かすことを「デフォルト」と呼んでいるの?

いくらなんでも、それじゃあ DJB に同情したくなりますね。

Re:確かに qmail の方が問題は少ないかも

[Anonymous Coward]

デフォルトって、作者の意図通りにユーザが設定した状態なの？　間違ったり手順が抜けたときにも安全側に振られるようにしておくべきものだと思うのだが。

Re:確かに qmail の方が問題は少ないかも

[TxG (7966)]

Postfixやqmailはメールサーバとして使う場合に導入されるケースが多い(放置マシン等はsendmailが多い)と考えられます。

リンク先の統計に関してですが、数だけ見ても仕方ないものではないでしょうか。

MXが引けるか?
メールサーバ/ローカル利用での各MTAの利用比率は?

等の情報が(結果としての数字ではなく、設定ミスをする割合を論じるには)必要だと思います。

# でもとりあえずPostfixの少なさは立派。

正直に言うとrcpthostsをスペルミスして（笑）数日間放置してしまったことがあるのですが、チェックして気付きました。
幸いにして悪用はされていませんでしたが、いくらなんでもグローバルに置くサーバは(どのMTAを使っていても)確認しましょう。

Re:確かに qmail の方が問題は少ないかも

[IKEDA Kenji (4659)]

手順が抜けるというのも「間違った」場合だろうから一緒にするとして、./config を実行せず control/me さえ無い状態で qmail が機能するかも置くとして、control/ 下のファイルの内容も確認せずに「安全」を問われる場所のメイルサーバーを動かすことの是非も度外視したとして…

なんらかの間違いで rcpthosts を消してしまった場合、どう動くべきか?

私なんかは、間違えた通りに動いて欲しいと思ってしまう。 勝手に知らない挙動をされるのは迷惑だし。 さらに、すべて受け付けるか、すべて拒否するか、倒れる先のどちらが「安全側」かは単純には決められない。大事な顧客のメイルをすべて弾いてしまうと、顧客へのメイルが RBL で弾かれるとのでは、後者の方がまだましなので、より安全であると判断する立場だってあるはず。

なにが「安全」かといえば、make setup で ./config まで実行するようにしとくべきだったって事だろうね。

そういう話とは関係なく、あれこれ考えていて、rcpthosts が無い場合の仕様はおかしいと思うようになった。rcpthosts は受け付けるべき RCPT TO の内容を列挙するためのファイルなんだから、それがカラだったり無かったりしたら、すべて拒否する方が自然だよな。単に、RCPT TO の内容を問わないようにするだけなら、環境変数 RELAYCLIENT で実現できるわけだし、

このあたりのバランスは良くないやね。locals と rcpthosts の関係も、もうちょっといい設計ができたんではないかと思う。