公式サイト上のSendmailソースにトロイの木馬 64
ストーリー by Oliver
OpenSSHの時にそっくり 部門より
OpenSSHの時にそっくり 部門より
isi 曰く、 "IT Proによると、Sendmailのソースコードにトロイの木馬が仕込まれている恐れがあることを、米CERT/CCが警告した。危険なVer.は「sendmail.8.12.6.tar.Z」と「sendmail.8.12.6.tar.gz」。9月28日ごろ以降にダウンロードしたユーザーは，PGP署名やMD5チェックサムでの検証を勧めている。タイムスタンプやファイル・サイズで確認するだけでは不十分で、公式サイトから入手したものも安全でないという。18:00現在、日本語の情報はIT Proのものだけしか確認できなかった。ビルド中に動作するという感染形態も興味深いが、公式サイト上のソースコードすら要注意とは、いったい何が起こっているのであろうか。"
情報源 (スコア:2)
メールベースですがiDefense [idefense.co.jp]が日本語訳と分析、対応情報が比較的早かったような。
ま、19:00ころにはLACの和訳 [lac.co.jp]が出てましたが。
＃今回のはIIJからCERT/CCへ報告された情報らしいってのが興味深い
みんつ
Re:情報源 (スコア:1)
Sendmailの一部のバージョンにトロイの木馬、9月28日以降のバージョンに注意 [impress.co.jp]
18:20頃に読みました。
Re:情報源 (スコア:0)
15:30ごろにはメールが届いていたようです。
#この時間はLinux Kernel Conference中で
#編集長さんはチュートリアルの会場にいたはずだが・・・。
Sendmail？ (スコア:1, 余計なもの)
記事は確かにSendmailになっているようですが。
CERTでもSendmailになっているようですが。
その割にはこっち [sendmail.com]は無反応。
謎が謎を呼んでいるので誰かsendmail:-)に詳しい方は事情を教えていただけるとありがたいです。
Re:Sendmail？ (スコア:1)
Re:Sendmail？ (スコア:0)
頭文字が大文字か小文字かが、それほどまでに問題なんですか？
Re:Sendmail？ (スコア:2, おもしろおかしい)
Re:Sendmail？ (スコア:0)
ガッテン！ガッテン！(笑)
Re:Sendmail？ (スコア:1)
商用版だとひょっとしてパッケージで売っててソースを自分でおとすわけではない??と思って詳しい方に教えて頂こうとしたのですが。
分かりにくい書き方してすみません。
Sendmail (スコア:2, 参考になる)
.com(Sendmail) で提供(販売)しているものは、 .org(sendmail)で提供しているもの(少し古い)をベースに、 WebBase(SSLなApache+php+cf)の管理ツールで操作するための仕組みや、 複数サーバで連携して稼動するための仕組みが植え込んであります。
これはオープンソースではなくクローズドソースのバイナリ提供型です。
Sendmailから提供される体験版と製品版はまったく同一バイナリで、 ライセンスキーが違うのみです。
sendmail (MTA)に相当するのは Sendmail Switch(通称Switch)で、
POP/IMAP サーバが Sendmail Advanced Message Server(通称SAMS)です。
あと、WebBase MUAとして Sendmail Mobile Message Server(通称SMMS)もあったかな。
実際に導入した経験上では sendmail の問題点ともいえる設定の難しさ (sendmailに習熟しないと意図したとおりの設定が難しい) がWebBaseの設定ツールによってだいぶ軽減されています。 設定項目の意味を直接検索できるのもだいぶ助けになります。
Switch+SAMS の環境だと、マルチドメインが楽に構築できるので重宝しました。
アカウントデータベースを独自に持ち、 その結果ドメインごとにアカウントの名前空間が独立しているおかげのようです。
# Sendmailの回し者ではありません(^^;;)
# rm -rf ./.
ケン・トンプソンのトロイの木馬 (スコア:1)
Re:ケン・トンプソンのトロイの木馬 (スコア:4, 参考になる)
UNIXの生みの親、 Ken ThompsonがACMチューリング賞受賞講演で説明したものですね。 知らない人のために説明すると、Thompsonはこの講演 [acm.org]で、 「ソースをいくら調べても発見できないトロイの木馬」をコンパイラなどの「プログラムを扱うプログラム」に埋め込めることを示しています。
SendmailはSendmail自体を使って生成されるわけではないので、今回のトロイの木馬はThompsonのトロイの木馬とは違って単純な奴なのでしょうけれど(未確認)、Thompsonの警告するようなトロイの木馬も、本気で心配しなくてはいけない状況になってきた気はしますね。
現在、多くの重要なソフトウェアが、オープンソース(あるいはフリー)ソフトウェアとして開発・使用されています。「ソースが公開されているから、トロイの木馬が混入しても結局は(ほとんどの場合すぐに)発見される」と信じている人も多いと思います。確かにソース非公開のソフトウェアよりは、トロイの木馬を仕込むのは難しくなります。しかしThompsonの手法を使えば、ソースを見ても発見できないトロイの木馬を仕込むことは実は可能なのです。
gccやLinux, *BSDなどにも、もしかするとすでに人知れずトロイの木馬が潜んでいるかもしれないと思うとゾッとします。そしてそれが一度仕込まれてしまえば、後はいくらソースを精査したところで、発見は不可能なわけです。
「完全にすべて自分で作らなければ信用できない」ことになるわけですが、Thompsonはそれに続けて、ハードウェアのmicrocodeにまで同じ手法でトロイの木馬が仕込める、なんて書いてまして。私などは為す術無く途方に暮れるばかりなのですが。うーん……。ホント、どうすればいいんだ。
心配しなくても (スコア:1)
って、もっと心配か・・・
Re:ケン・トンプソンのトロイの木馬 (スコア:1, 参考になる)
これが普段は静かにしていて、ある特定のキーワードを含むメールが届いたときに
行動を起こすものだったら発見に時間がかかったかもしれません。
今回は開発・配布元ではなく、外部の方が先に発見したようですので、
ソースを見て発見ではなく動作を見て発見されたものと思います。
ありがちな妄想 (スコア:0)
同じくありがちな妄想 (スコア:0)
多分これがWindowsUpdateで起きたら、
今頃スレ1000オーバーになってるに100カノッサ。
ついでに言うと、
スレが100越えないに100,000カノッサ。（ｗ
＃まあ、/.Jだからねえ…。
Re:同じくありがちな妄想 (スコア:0)
いまどきカノッサいう人いるのか……
Re:同じくありがちな妄想 (スコア:0)
/.j初の
(updated)
が出ただろうね。
その程度のネタでないと盛り上がれない人たちってのもどうかと思うがね。
自省とか、人の振り見てとか、そういう事考えられない奴ばっかりなんだね。
問題が起きていながら、自分がお世話になっていながら、自分
改竄チェック (スコア:0)
これってオープンソースの危機じゃねぇの？ (スコア:0, 余計なもの)
Re:これってオープンソースの危機じゃねぇの？ (スコア:1)
以下再送。
この間のOpenSSHといい、
オープンソース陣営としてかなり冷や汗ものの事態ではなかろうか。
＃オープンソースであるか否かに関わらないんだけど
＃世間はそう見るよね。
＃これを肴にオープンソース叩きをされたら
＃かなり効くと思うんだが・・・
自サーバもってる他のオープンソースプロジェクトで
セキュリティ監査始めたところってあるかなぁ。
sendmailとしては
postfixやqmailが持ち上げられるようになっている時にこれは痛い。
＃今回もすり替えかな？
＃通常通りの手順を踏んでコミットされていたら２度ビックリ。
ホントに駄文スマソ 。
Re:これってオープンソースの危機じゃねぇの？ (スコア:2, すばらしい洞察)
> ＃かなり効くと思うんだが・・・
いえ、MX 落としてはいけない物リスト [tripod.co.jp] を見せれば「クローズドソースは昔から遥かに危険だった」と一撃で反論できるでしょう。
まあ、 PGP も MD5 のチェックもしないでインストールすれば、本質的に改竄されていても判らないという当たり前の事の認識がまだ甘い所があるのでしょうね。 もう「古き良き時代」ではないので、今後はとりあえずダウンロードの紹介ページは https ベースにして、ここに PGP署名か MD5値 を載せ、後はユーザーが http か ftp で、どこからダウンロードしてきた物に対し改竄されてない事を確認し、それからインストール、でしょう。
MD5 でいいんなら、 (スコア:1)
# 自動で MD5 やってくれますから。
フリビユーザーはそれでも昔から、それが完全な安全を保障する方法だと考えていた訳では無いですが、少なくとも Linux でのソース DL、 展開、コンパイルという手順に安全面で違和感を覚えていて、今回のような事が起きそうな予感を持っていたのも事実です。
Linux でも ports システム [freebsd.org]が導入されて、各ディストリビューションで共通して使えるようになれば、便利さや、今と比較しての相対的な安全性も確保出来るんでは？
何よりも副産物として、ディストリビューションを越えて統一された文化のようなものが出来ると嬉しい。
Re:MD5 でいいんなら、 (スコア:2, 参考になる)
つまり、ソースコード本体だけでなく、PGP署名やMD5チェックサムも同時にすり替えられている危険があります。 セキュリティメモ [ryukoku.ac.jp]によると、www.cert.org上のadvisory には sendmail@Sendmail.ORG の fingerprintがあり、sendmail.org 配布の PGP 公開鍵 とクロスチェックできるとのことです。
私はportsシステムについて無知なので判断できません。しかし「自動で」というところに一抹の懸念を感じます。無知ゆえの杞憂であれば申し訳ありません。
Re:MD5 でいいんなら、 (スコア:1)
> しかし「自動で」というところに一抹の懸念を感じます。
ports は make した時にソースが無ければ自動で ftp で取りに行って、 md5 のチェックをして、合わなければエラーで終わって、md5 が合えばパッチをあててコンパイル、という流れになります。ですから ports が正しければ改竄ファイルは見つけられるが、 ports も改竄された物をつかまされてそれで置き換えてしまっていればアウトです。
ここの [ryukoku.ac.jp]「その情報って本物? あるいは、なぜ未だにこうなのか」でまとめられている情報は参考になります。
Re:MD5 でいいんなら、 (スコア:2, 参考になる)
>> 言うか、安全性が高いと見て良いのでしょうか？
ports の MD5 は、ports 作成者が、自分が作業するときに取得した配付物を元にして作ります。よって、保証されるのは、配付物が ports 作成時のものと同じであるということです。
# ports 自体がいじられていない前提で
よって、ports 作成時点ですでに木馬入りだったら、検出は不可能です。作成後に配付ファイルが置き換えられたのであれば、それが公式サイトであろうが検出できます。
Re:MD5 でいいんなら、 (スコア:1)
FreeBSD に関しては、 frebsd.org のサイトにはソースは置いておらず、ソースのありかと正しい md5値 が載せられているので、
- ソースが置いてあるサイト
- freebsd.org のサイト
の両方に侵入して改竄(あるいは、両方共にニセサイトに誘導)しないと騙せないという点では安全性が高いと思います。Re:MD5 でいいんなら、 (スコア:1)
FreeBSD ports 上での話ですね。
ports には、世界中のユーザによって mirror されている配付物の改竄を監視できるという利点もあるわけです。
Re:MD5 でいいんなら、 (スコア:1)
それはまさに本トピックの件そのものですね。いまさらな洞察 (-1)。
mirror される過程での改竄に ports が対抗できるという話をしているので、繋げるならそれに対する意見をお願いします。
Re:MD5 でいいんなら、 (スコア:1)
>> ・偽サイトに誘導
>> ・偽サイト用のMD5を参照
>> させらんね？
その通りですね。freefall.FreeBSD.org に侵入するだけで充分で、「ソースが置いてあるサイト」まで同時に侵入する必要はないですね。
逆に言えば、freefall および cvs の mirror サイトさえ充分に守られていれば、ユーザはまずまず安心していられます。
Re:MD5 でいいんなら、 (スコア:1)
ソースからバイナリパッケージを作成する仕組み(MD5等でのチェック
機構を含む)があるのだから、今更portsを導入することも無いだ
ろう。gentooとかもあるしね。Linuxでは、統一的なXXXという
ことが話題になるが、これに関してはパッケージングシステムの
根幹に関わりそうなので実現は難しいかもしれない。
Re:MD5 でいいんなら、 (スコア:1)
http://www.gentoo.org
ってか、Debianじゃどうなんすか？
Re:MD5 でいいんなら、 (スコア:1)
> ってか、Debianじゃどうなんすか？
Debian も Ver.1.1 くらい(??)の頃から使ってないので現状を詳しく知りません。暇をみて調べてみようと思います。
Re:これってオープンソースの危機じゃねぇの？ (スコア:0)
正規なサイト(もしくは商品としてのCDROM)から
正当な手段でダウンロードしたものに
ウィルスが混ざっていれば危険だとは思いますが、
そもそもMXをつかってああいった商用ソフトウェアを
見知らぬ場所からダウンロードすること
Re:これってオープンソースの危機じゃねぇの？ (スコア:1)
例えば「Get Acrobat Reader Now!」というアイコンを置いて、それにリンクを張って、ハードディスクを全消去するプログラムを Acrobat Reader であるかの様に偽ってWebやFTPでダウンロードさせるといった悪質な悪戯は誰にでもできます。オープンソースなら、まだソースを見るという手がありますが、クローズドソースで EXE の実行ファイルしか無く、PGPやMD5も無いなら、「信じて実行してみないと判らない」のですから。
> 正規なサイト(もしくは商品としてのCDROM)から
sendmail では正規なサイトにトロイの木馬入りが仕掛けられたようですから、「正規のサイトであるから」という理由で安全だとは言えません。それに「正規のサイト」を装ったニセサイトに誘導する手がありますし。(だから https が必要になります) 商品ならさすがにチェックしているでしょうが、例えば誰かが「有用フリーソフト集」といったCDを焼いて値段を付けて配布する事はできますし、その中身の一部をハードディスク全消去のプログラムと置き換えるといった程度の事は技術的に可能です。よって、これも商品だから絶対に安全とも言い切れません。
Re:これってオープンソースの危機じゃねぇの？ (スコア:3, すばらしい洞察)
LinuxでもFreeBSDでも、いちいち配布物のソースツリー全体を自分でチェックする奴なんていないでしょうから、(心理的な意味合いは別として)実態としては大して変わらないと思いますけど。
例えばadobeのweb siteに置いてあるacrobat readerがウィルス感染したような状況はユーザ側では防ぎようがないわけで、それと同様の問題が今回のsendmailの件ですね。つまり、いずれにせよ一次配布先がやられるととっても困るねっていうだけの当たり前な話で、オープンだろうがプロプラだろうが本質的には関係無いと思いますけどね、僕は。
Re:これってオープンソースの危機じゃねぇの？ (スコア:1)
それが重要なんじゃん。
その前提をすっとばして、MXでダウンロードすればクローズドソースだってキケンだよって言ったところで、
>>何を言いたいのかが良くわかりません。
というのは当然の反応ではないかと。
>例えば誰かが
意味のない置き換えはやめませう。
Re:これってオープンソースの危機じゃねぇの？ (スコア:1)
- Acrobat 5J とか、午後のこ～だ 239d を装ったHDD全消去プログラムがあって、被害も出てる。
- この被害例では MX が使われているが、別に MX 以外の、普通の HTTP や FTP によるダウンロードでも、容易に真似できる。
- こうなると、sendmail の件は「オープンソースだからいけなかったのだ」とは言えない。
という事を言いたかったのですが、> 意味のない置き換えはやめませう。
たとえ話は相手に判りやすくするために使うのが目的なので、正直言って「ここまで話を何度も置き換えて説明しないと駄目かな」とは思いますが、私の説明が imo さんにとって意味が無く、幾ら説明しても「MX だからが悪いんだ!」という風に逸れてしまうのでしたら、逆にどういう事に置き換えて説明すれば imo さんは理解してもらえるのか教えてください。それに合った説明をしますから。
# ああ、 MX の実例なんか出すんじゃなかった・・・おかげで大ハマリだぁ、、、
Re:これってオープンソースの危機じゃねぇの？ (スコア:0)
以上の事象を説明するに適当な例を出しなさい。
> (＃180854) [srad.jp]
> 「クローズドソースは昔から遥
Re:これってオープンソースの危機じゃねぇの？ (スコア:1)
おっしゃるとおりです。持ち出した例えが不適切でした。反省しています。
Re:これってオープンソースの危機じゃねぇの？ (スコア:0)
あなたが言っているのは
>> 「クローズドソースは昔から遥かに危険だった」
ではありませんでしたか？あなたは
「オープンソースだったからいけなかった」に反論しているのではなく、「クローズドな商用ソフトウェアは、昔からオープンソースなソフトウェア以上に危険だ」と言っているのだと感じられますが。
MXにかかわらず、こういうもの（リストに載っているもの）が
HTTP経由で公開されている可能性もあるのだから、危険だろう、
と、そういうことですよね？
私には、どうしてクローズド
Re:これってオープンソースの危機じゃねぇの？ (スコア:0)
話をずらすのはやめよう。
これはオープンソースだから安全ではないというインパクトの大きい具体例だということで
君のその論法ではオープンソースでも安全でないのだから優位性が保たれなくなったと認めることになる。
Re:これってオープンソースの危機じゃねぇの？ (スコア:1)
> 保証も無いような場所からダウンロードするかが不思議でなりません。
> こういうソフトって、普通は一時配布元からダウンロードするものではないでしょうか。
Yahoo! [yahoo.co.jp]、 Vector [vector.co.jp]、 窓の杜 [impress.co.jp] は代表的なダウンロードサイトです。そこではフリーウェアもシェアウェアも配布されていますが、ここは一時配布元ではありません。 ここからダウンロードするのは、ごく普通のことです。
こう言うとまた紛糾したり話が逸れるかもしれませんが、 今回 Sendmail.org のサイトがクラックされてトロイの木馬入りソースが仕掛けられたというのは、 技術的観点からは、もし Yahoo!、Vector、窓の杜などがクラックされてファイルを置き換えられた場合、 ユーザーがニセのバイナリだと見破れるだろうかという問題と変わりは無いと思います。
Re:これってオープンソースの危機じゃねぇの？ (スコア:1)
はあ? 改竄に関しては「同じような物」でしょ?
> オープンソースだから安全ではないというインパクトの大きい具体例
いや、話がずれてるのはこっち↑でしょう。
改竄予防のための手段が講じられているか、一次サイトがクラッキングを許すか否かの問題は、オープンソースか否かは関係しないでしょう。
Re:これってオープンソースの危機じゃねぇの？ (スコア:1)
そうすれば既知のウイルスに感染した物に関しては検出可能でしょう。でも、例えば「HDD を全部消す」なんてプログラムを作って、バイナリを全く置き換えたら、アンチウイルスソフトでも事前に検出できず、実行したら「さよ～なら～」になるかと思います。
Re:これってオープンソースの危機じゃねぇの？ (スコア:1)
本来、正規の入手ルートにも関わらず、キケンがイッパイな例をあげればよかったと思いますよ。
クローズドソースの商品だって、開発元以外にも代理店から正規に購入することも可能なので、
代理店がウイルス仕掛けまくれるとかそういう事例があればよかったのではないかと。 ^^;
クローズドソースのくせに、バックドアがいっぱい仕込まれてるMS製品って言い出すと荒れるかな?
Re:これってオープンソースの危機じゃねぇの？ (スコア:1)
試しにパッと検索してみました。目についただけでも結構ありますね。
Re:これってオープンソースの危機じゃねぇの？ (スコア:1)
トロイの木馬として、既知のものであれば検出されると思います。
と言うか、されます。
Re:これってオープンソースの危機じゃねぇの？ (スコア:0)
>オープンソース陣営としてかなり冷や汗ものの事態ではなかろうか。
であるならば sendmail に限らず postfix や qmail だって
その配布物が似たような環境に置いてあれば立場は同じかと。
# 誤爆って"目標を間違えて爆撃すること"であり
# 爆撃の仕方を誤ったこととは違うぞ。
Re:これってオープンソースの危機じゃねぇの？ (スコア:0)
> ＃オープンソースであるか否かに関わらないんだけど
の意味をちゃんと取ってからレスしる。