sendmail 8.12.xにDNS経由で任意コードが実行可能な穴 61
ストーリー by Oliver
いにしえのMTA 部門より
いにしえのMTA 部門より
Anonymous Coward曰く、 "Certの"Vulnerability Note"および各ディストリビューションのSecurity Advisoriesによると、バージョン8.12.8以前(8.12系のみ)のSendmailに潜在的に存在していたセキュリティホールが見つかったようです。Sendmail 8.12.9では、fixされています。
攻撃者がsendmailサーバーへ巧妙に工作した不正なDNSレスポンスを送ることによってsendmailデーモンをクラシュさせたり、任意のコードを実行すること出来る可能性があるようです。
2003年3月末に大きな問題となった "CERT Advisory CA-2003-12 のBuffer Overflow in Sendmail”の時点では気が付いていないバグだたようです。したがって、このときに公開されたsendmail.8.12.security.cr.patchには
今回のパッチが含まれていません。
FEATURE(`enhdnsbl')の指定によって顕在化するもののようなで、disable にすれば回避できるかもしれませんが、これによって運用上問題が生じるようであればやはり根本的な対応をした方が良いと思います。"
実行可能かどうかはまだ分っていないはず (スコア:4, 参考になる)
# セキュリティーに敏感でスキルのあるメールマスターならとっくに 8.12.9 に上げてると思いますが・・・
どうも表現がまずかったですね。 (スコア:1)
今回のは 8.12.9 では直っている問題だし深刻度も大した事なさそうだし・・とも思いまして。まあ、以前のバージョンにパッチを当てて使い続けて、今回もまたパッチを当てて使う、でもOKですけどね。でもそこまでする位なら最新バージョンにするほうがずっといいと思いますけど。
ただのちゃちゃ (スコア:0, フレームのもと)
メールマスターは登録商標です (スコア:1)
補足 (スコア:3, 参考になる)
- メール管理用 postmaster (例: postmaster@example.com)
- web 管理用 webmaster (例:webmaster@example.net)
- DNS 管理用 hostmaster (例: hostmaster@example.org)
参考: RFC2142:一般的なサービス、役割、機能に対するメールボックス名 [nic.ad.jp]so many days pass my by... (スコア:0)
Re:so many days pass my by... (スコア:0)
メールサーバー触ったことないとおもふ...
とにかくメールマスターとは言わないよねぇ。
メシマスターは登録商標です (スコア:0)
オフトピなんですが、この名前、これがあればあともう一杯ごはんが食べられそうな気がしませんか？
Re:メシマスターは登録商標です (スコア:0)
#召しますた。
釣られてみるテスト (スコア:1, すばらしい洞察)
逆に他の穴に対して鈍感になる管理者。
どうしてこう (スコア:1, すばらしい洞察)
私はそういう雰囲気がいやでpostfixを使っているクチですが。
何にせよ選択肢があるのは良い事です。
#qmail信者に刺されるのがいやなのでAC
Re:どうしてこう (スコア:1)
下手な営業と同じで, 困っている人に解決策を与えるのが目的ではなく, qmailを使わせることが目的の様に見えますからね. この記事みたいに他のMTAが話題になっていても, 何の前提も出すことなくqmail使えじゃ信者呼ばわりされても仕方ないように私も思います.
せめて何故sendmailが使われているのか, 何故sendmailでバグが見つかりやすいのかあたりから話を広げて, 条件付きでqmailを一例として勧めるとかのアプローチを取れば見方も変わるんでしょうけどね.
Re:どうしてこう (スコア:1)
qmail の場合は RCPT の段階で local user の存在をチェックして reject できないので、嘘の envelope from で流されて対象ユーザがいない場合に error mail のループに陥りやすいとか、そういった事を理解していないと使えないかと思います。
sendmail は、少なくとも MAILER(local) はこれを行います。(Cyrus IMAPd を使うと qmail と同じように取り込んでしまうのですが)
sendmail の設定が難しいというは過去の話だとしか思えません。普通 .mc から生成でしょ。
配送性能の優位性を誇る、と言っても相手が受けきれなかったら全く意味がありませんし、同一ドメインへのまとめ送りを標準でサポートしない qmail はどうなのよ、という気もします。社内サーバとかで、ほとんど流れるメールが同一ドメインなどだと、無駄にトラフィック発生しまくりで嫌すぎ、とか十分あり得ます。
qmail の場合、ポリシーに従って使う場合、標準のまま使う人はそうそういないので patch を当てまくって使う場合なども多いわけですが、patch の全ての内容をチェックして、system call 置き換えるの? とかまで拘らないとダメなのでは、とか考えさせられます。
いわゆるイマドキの機能を使いたい、という場合には、qmail では patch を当てて……から始まるので、結構きついです。
似たようなことをする patch が複数あり、それぞれを評価して……とかになってくると、qmail のシンプルさの優位点などというのは存在しないように思えます。
djb の主張に従って使うのであれば、複雑な TLS なんて使いたくないとかになるでしょうし、TLS 周りの実装を OpenSSL を利用せずに djb の主義にしたがって再実装とかまでやるとしたら……非現実的すぎますね。
あと、FreeBSD 辺りだと /etc/mail で make cf install で sendmail.cf/submit.cf をさくっと生成してくれるとか、その辺りのワークフレームが標準提供されているのは非常に便利です。下手すると qmail より設定は少ないかもしれません。
ports ではなく、contrib の範囲に関しては gshapiro [gshapiro.net] がメンテナンスしてるので安心感があります。多分 sendmail を利用する場合、一番幸せな環境。ports から入れていても、このワークフレームはそのまま利用できます。
TLS + SMTP AUTH 辺りまでの要求であれば Postfix でもいいのですが、+IPv6 となるといきなり Postfix はこける (TLS + IPv6 がどうにも……) などの理由から、Postfix は未だに現実的な評価ができません。
用途に応じて、qmail の方が長けている場合も十分にありますから一概に否定する気はありませんが、私は qmail から sendmail に移行しました。
Re:どうしてこう (スコア:1)
＞普通 .mc から生成でしょ。
.def にしろ .mc にしろ、十分難しい存在だと思います。
あなたの言う「過去」は .cf を自前でかく話ですか？
もしそうなら戻りすぎですし、そうでないならsendmailに習熟しているからこそ出る台詞ではないでしょうか。
必ず.mc → .cf という手順を踏むことに十分なメリットがあるとはどうしても思えません。
.mcから生成できない設定がしたければは結局.cfを編集することになり、cfが出力する書式が変わればそれを追いかけねばなりません。
# sendmailは万能ナイフで逆に扱いづらく、
# qmail は理想ばかりで現実的メリットが言う程じゃないと感じたのでpostfix使ってます。
# rm -rf ./.
Re:どうしてこう (スコア:1)
教育用計算機センターのアカウントから別ホストで qmailで運用している クラスMLとかサークルMLに記事を投稿すると。。。 たとえば80人登録されていると（全員センターのアカウントが 登録されているので）80倍のトラヒックになって帰ってくる。 さらにそれにウィルスが付いていると、センターのメールサーバから ウィルス検知報告メールが80通システム管理者に送られる。 などと、システム管理者が愚痴ってました。
sendmail.cfの生成は昔より楽になったけど、一般論としては まだ結構大変だと思いますよ。 しかし、生成しないといけないような複雑な運用をしている マシンの割合は少ないと思いますが。たいていは、添付の client.cfをそのままつかうとか、中の 「自分のFQDN」定義の １行だけエディタで書き換えれば済むとおもうのですが。
しかし、sendmail.cfは難しくてと主張している人のうち sendmail.cfに実際に挑戦してみて難しいと体感した人は 何割居るのでしょうか？多くは誰かに言われたのをそのまま オウム返ししてるだけじゃないの？
Re:どうしてこう (スコア:1)
sendmail.cfは文法はシンプルだしね。下手なアセンブラの方が syntaxは複雑かも。
Re:どうしてこう (スコア:1)
私が言っている過去は、CF の頃です。CF 自身が sendmail に追従するまでは、.cf 自体を弄らなければいけないのはこの頃でしょう。
現状の cf は標準配布物で提供されていて、基本的には作者側が自分達で管理する上で使いやすいツールを提供しているので、追従されないということは考えにくいものです。ドキュメンテーションが追い付いていないというのは実際にありましたが。
.mc から生成できない設定というものに遭遇したことはありませんが、どのような内容のことを言われているのでしょうか。LOCAL_* などを使っても対応しきれない世界というのが、ちょっとわかりません。
一般的に利用される機能関係については、FEATURE で簡単に有効にしたりなどができるわけで、大抵は .mc 中に 1 ～ 数行程度の指定しか書かないと思います。
標準配布物に patch を当てずに各種機能を利用したい (当て忘れの防止などよりも、バージョンアップ時などの追従に関する時間差や、patch を探す手間の問題) という要求はあるわけで、そう考えると、Postfix も十分ではないかと思います。qmail ほどではありませんが。
security hole が見つかった時に、patch 待ちなので update できませんとか、一時的に機能が低下しますとか、そんなこと言えるわけがないので。
cf を使った管理は qmail より楽、というのが実体験上からの経験でしょうか。参考になるというかそのまま書き写してしまえば終わるようなレベルの記事 [imasy.or.jp]が存在するのも理由ですけど。
Re:どうしてこう (スコア:0)
A: qmailなら○○ってすればできますよ。sendmail捨て
こういう感じの人のことかな？確かにイヤかも
Re:どうしてこう (スコア:2, すばらしい洞察)
Re:どうしてこう (スコア:0)
確かに qmail の方が問題は少ないかも (スコア:1)
Re:確かに qmail の方が問題は少ないかも (スコア:1)
Re:確かに qmail の方が問題は少ないかも (スコア:1)
Re:確かに qmail の方が問題は少ないかも (スコア:1)
qmailはデフォルト設定ではオープンリレーは許可しませんし。
よって、自宅のマシンからプロバイダ経由で会社のメールサーバにつないで送信することも不可能。
#自宅に固定IPとかを持っていれば別ですが・・・
まあ、それだと不便だから件のパッチのようなものが出てくるわけですけどね。
こうしたパッチをあてずに満足できるならqmailは一番と個人的には思います。
いろいろやろうとすると面倒になってきますけどね。
私の手元ではメールサーバとしては内部のデーモンが管理者宛にメールを送信する程度の機能があれば
いいサーバは全部qmailにしてあります。
Re:確かに qmail の方が問題は少ないかも (スコア:1)
いくらなんでも、それじゃあ DJB に同情したくなりますね。
Re:確かに qmail の方が問題は少ないかも (スコア:1)
リンク先の統計に関してですが、数だけ見ても仕方ないものではないでしょうか。
MXが引けるか?
メールサーバ/ローカル利用での各MTAの利用比率は?
等の情報が(結果としての数字ではなく、設定ミスをする割合を論じるには)必要だと思います。
# でもとりあえずPostfixの少なさは立派。
正直に言うとrcpthostsをスペルミスして（笑）数日間放置してしまったことがあるのですが、チェックして気付きました。
幸いにして悪用はされていませんでしたが、いくらなんでもグローバルに置くサーバは(どのMTAを使っていても)確認しましょう。
Re:確かに qmail の方が問題は少ないかも (スコア:1)
手順が抜けるというのも「間違った」場合だろうから一緒にするとして、./config を実行せず control/me さえ無い状態で qmail が機能するかも置くとして、control/ 下のファイルの内容も確認せずに「安全」を問われる場所のメイルサーバーを動かすことの是非も度外視したとして…
なんらかの間違いで rcpthosts を消してしまった場合、どう動くべきか?
私なんかは、間違えた通りに動いて欲しいと思ってしまう。 勝手に知らない挙動をされるのは迷惑だし。 さらに、すべて受け付けるか、すべて拒否するか、倒れる先のどちらが「安全側」かは単純には決められない。大事な顧客のメイルをすべて弾いてしまうと、顧客へのメイルが RBL で弾かれるとのでは、後者の方がまだましなので、より安全であると判断する立場だってあるはず。
なにが「安全」かといえば、make setup で ./config まで実行するようにしとくべきだったって事だろうね。
そういう話とは関係なく、あれこれ考えていて、rcpthosts が無い場合の仕様はおかしいと思うようになった。rcpthosts は受け付けるべき RCPT TO の内容を列挙するためのファイルなんだから、それがカラだったり無かったりしたら、すべて拒否する方が自然だよな。単に、RCPT TO の内容を問わないようにするだけなら、環境変数 RELAYCLIENT で実現できるわけだし、
このあたりのバランスは良くないやね。locals と rcpthosts の関係も、もうちょっといい設計ができたんではないかと思う。
Re:確かに qmail の方が問題は少ないかも (スコア:1)
Re:確かに qmail の方が問題は少ないかも (スコア:1, すばらしい洞察)
最後は否定的肯定で〆てますが、その否定自体が間違ってる。
設定を間違ってもOpenRelayにならないMTAって何ですか？
Re:確かに qmail の方が問題は少ないかも (スコア:0)
#ってあるのかな？
Re:確かに qmail の方が問題は少ないかも (スコア:0)
Re:確かに qmail の方が問題は少ないかも (スコア:1, おもしろおかしい)
Re:確かに qmail の方が問題は少ないかも (スコア:0)
Re:確かに qmail の方が問題は少ないかも (スコア:0)
Re:確かに qmail の方が問題は少ないかも (スコア:0)
qmailのセキュリティホール (スコア:1)
Re:qmailのセキュリティホール (スコア:1)
Re:確かに qmail の方が問題は少ないかも (スコア:0)
Re:確かに qmail の方が問題は少ないかも (スコア:0)
djbはそんなミスなんか犯さないんだい、てな感じで
擁護発言が出たりするのを見そうになる気がしてこわいです。
あの人のは、その辺ではあたりまえとして考えられていることを
あえて「やらなくてもいい」と考えて実装しないでいたりして、
それはそれで正しいとは思うのだけど、
その分周
Re:確かに qmail の方が問題は少ないかも (スコア:0)
Re:ただのちゃちゃ (スコア:1)
Re:ただのちゃちゃ (スコア:0)
Re:ただのちゃちゃ (スコア:2, おもしろおかしい)
qmail食わばdjbdnsまで。
Re:ただのちゃちゃ (スコア:0)
思想的に嫌でも (スコア:0)
Re:思想的に嫌でも (スコア:0)
vpopmailを使いたいためだけに使っています。
# 仕事だから仕方ないよねってことで
Re:ただのちゃちゃ (スコア:0)
・DJBの脳内理想だけで構築されていて、現実的とは思えない箇所がいくつかある。
・ドキュメントや解説文が「DJBの言うとおりにしてれば安全なんです」といわんばかりの風潮で、理由の詳細がわかりづらい
・qmail.jpの氏の人格,言動
Re:ただのちゃちゃ (スコア:0)
思想がどうとかよりも大きな穴があかない点で即決です。
もう2年以上つかってますが一度もバージョンアップしてない(する必要がない)(というかバージョンアップがない)です。
難解な .cf や度重なるセキュリティホール発覚で心を砕かれている管理者様には同情します。:-p
Re:ただのちゃちゃ (スコア:0)
とりあえず (スコア:0)
#makeしたまま放置してinstall忘れてる罠(T_T
#で、設定ファイルは古いままでも大丈夫なのかな？（ぉ
#接続するとSendmail 8.12.9/8.12.6を名乗るのでAC