vsftpdにバックドアが仕込まれる 50
ストーリー by hylom
気になる方はご確認を 部門より
気になる方はご確認を 部門より
あるAnonymous Coward 曰く、
多くのLinuxディストリビューションでも採用されているFTPサーバーvsftpdにバックドアが見つかった。The Hによると、公開されているvsftpd 2.3.4のソースコードにバックドアを実装するコードが発見されたそうだ。このバックドアはユーザー名「:)」、ポート番号6200で任意のユーザーの接続を許すというもので、またシェルを実行することもできるという。
このコードは2～3.5日前（記事公開が7月4日なので7月2日前後？）に混入した模様。安全なソースコードはGoogle AppEngine上のvsftpdサイトで公開されている。
最近ではソースからビルドしてインストールしている人は多くないと思うが、思い当たる節のある方はご確認を。また、ソースコードをダウンロードした際はGPG署名を確認するようにとも述べられている。
GPG署名を確認 (スコア:3, 参考になる)
Re: (スコア:0)
なんでおもおかモデがついてるのかわからんけど、これ重要なことだよ。
署名自体は誰でも(悪意の第三者でも)できるので、
.tar.gz だけでなく .tar.gz.asc までセットで置き換えられたら改竄を検知できない。
なので、誰がどんな鍵を使って署名したのかという情報も合わせて
チェックしないといけないんだけど、そのへんの情報は公開されてんのかしら。
Re:GPG署名を確認 (スコア:3, 参考になる)
ああ、フィンガープリント置いてあった [appspot.com]。
vsftpd tarballs are now GPG signed by me (8660 FD32 91B1 84CD BC2F 6418 AA62 EC46 3C0E 751C)
このサイト自体が改竄されてる可能性もないではないけど、まあ何とか検証できるかな。
% gpg --verify vsftpd-2.3.4.tar.gz.asc
Warning: using insecure memory!
gpg: Signature made Wed Feb 16 07:38:11 2011 JST using DSA key ID 3C0E751C
gpg: Can't check signature: No public key
% gpg --recv 3C0E751C
Warning: using insecure memory!
gpg: requesting key 3C0E751C from hkp server keys.gnupg.net
gpg: key 3C0E751C: public key "Chris Evans " imported
gpg: Total number processed: 1
gpg: imported: 1
% gpg --fingerprint 3C0E751C
Warning: using insecure memory!
pub 1024D/3C0E751C 2004-06-29
Key fingerprint = 8660 FD32 91B1 84CD BC2F 6418 AA62 EC46 3C0E 751C
uid Chris Evans
sub 1024g/0A9EB17D 2004-06-29
% gpg --verify vsftpd-2.3.4.tar.gz.asc
Warning: using insecure memory!
gpg: Signature made Wed Feb 16 07:38:11 2011 JST using DSA key ID 3C0E751C
gpg: Good signature from "Chris Evans "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 8660 FD32 91B1 84CD BC2F 6418 AA62 EC46 3C0E 751C
ということで、いくつか警告出たけど、公開されてる情報とフィンガープリントが一致し、Good signature になりました。
Re: (スコア:0)
Re:GPG署名を確認 (スコア:2, 興味深い)
うん、そこまで検証するの難しいよねぇ。
その fingerprint が置いてある security.appspot.com にオレオレじゃない HTTPS でつながってるので、
とりあえずそこまでの経路は正しいことはわかった。
問題は、そこに書いてあることがほんとに信用できるのかということだな。
というあたりが検証しきれていない。
でも、そこまで念入りに改竄するのはかなり困難なので、まあたぶん大丈夫だろう、と。
というか、公開されてる情報からはこれ以上の検証は無理なんじゃないかな。
あとはそういうイケナイことをするような奴がそこまで念入りに改竄するような周到な人間でないことを祈るだけ。
Re: (スコア:0)
いままで検証してきた人ならすぐ気づくけど、
いきなり改ざん版を検証した人は気づきにくいね。
Re: (スコア:0)
ところで、鍵の方はみんなどうしてる？
昔よく見た鍵サーバは、誰でも適当に作って勝手に登録できたんで信用できないし。
PGP Global Directoryは、一応メールアドレスの確認をしているけど、PGPがやってるんであまり好かない人とかいそうだし。
Re: (スコア:0)
誰でも作れることがどうして信用できないことに繋がるの？
Re:GPG署名を確認 (スコア:2)
もしこの人物の鍵が鍵サーバに登録されていたらそれは本人が作った鍵なのだろうか？
当然違う。
知ってはいるが使っていない人物であっても状況は大差ないだろう。
鍵サーバへの登録に確実な本人確認が必要であればこのようなことは不可能、あるいは現状よりだいぶ困難であるはず。
（とはいえ、これを以て「鍵サーバに置いてある鍵は全く信用出来ない」と言い切れるわけでもないが。）
そんなポート番号じゃFWで弾かれるんじゃないの (スコア:1, 興味深い)
6200ポートでググるとOracle通知サーバー・リモート・ポートなんてのがヒットするが、Oracle載ってるサーバをターゲットにした？
Re:そんなポート番号じゃFWで弾かれるんじゃないの (スコア:1, 興味深い)
バックドアのアカウント名から実利？を目指したというより、
コミュニティに恨みなり開発体制の脆弱性を指摘したい（方法は間違った）愉快犯…かなぁとか勘ぐってみますがどうなんでしょう。
Re: (スコア:0)
そこvsfptdだから笑うところですよ
ソースコード (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
何を言っているのかよくわかりません。ソース配布すると、バックドアが混入しやすくなるのですか？
ソースの比較ができるからこそ(チェックする人が存在すれば)より安全にはなりえますが。
それよりも、一次配布元のファイルに混入していた事実が問題ですよ。
ハッシュ値の情報ファイル自体が信用できないので。
# tar.gz ファイルにデジタル署名する技術ってあるのかしらん。
Re:ソースコード (スコア:3, すばらしい洞察)
はっきりいって、混入しやすくなる。
バイナリで配布されているソフトウェアにバックドアを仕込むよりも
技術的には容易になる。
> ソースの比較ができるからこそ(チェックする人が存在すれば)より安全にはなりえますが。
それは後の問題。
たいていは、make してインストールして起動し、Firewallなどで引っかかって
初めて気づく。
そしてソースから調べることができるというのだけが利点。
安全になると言うことは全くない。
バックドア混入を防ぐことに関してはオープンソースは強くない。
後で調べるときは有利。
今回は変なポートを使ったからすぐわかったのであって、これがもし、
本来使うポートを介して動作するバックドアだったら長期間気づかなかった
可能性の方が高いな。
たとえば 21番ポートを使ってFTPのコントロールコマンドを勝手に拡張
して操作できるようにバックドアが作られていたらと思うと、怖いよね。
悪意の改変者がそうしなかったのは、プログラマとしての技量が低く、
あらかじめ作り込んであったバックドアのソースを貼り付けただけだから
と思われる。
Re: (スコア:0)
えー、こんなコメントがすば洞モデになるの？
配布しているファイル自体を改竄されない、あるいは改竄されたとしても安全に検知できるように
していない時点で、ソース配布だろうがバイナリ配布だろうが一緒ですよ。
Re: (スコア:0)
あー、文章を読めないダメ人がいるなぁ。少し落ち着こうよ。
「混入しやすい」ってのはソースコードがあるから改竄したソースコードを配布しやすい、という意味？
それともコミッターとしてパッチを取り込ませやすい、という意味？
前者だとしたら、バイナリ配布だって改竄済みバイナリを配布すれば同じことになるから、
ソース配布とバイナリ配布の違いはないです。
後者だとしたら、コードレビューの不足が問題なだけですね。そもそもダメなプロジェクトなんでしょう。
オープンな開発体制だと無数のレビューアが存在する可能性が
Re: (スコア:0)
自分に言い聞かせてるのですね。よい傾向です。
バイナリで配布しているソフトの場合、アプリケーション証明書を
デジタル署名でつければOK。
誰でも生成できるfingerprintを改変が可能なところに貼ったり
するよりも信頼性は高い。
RSAがキーを盗まれるというケースも考えられはするが、
オープンソースに悪意の第三者がバックドアを仕込む確率よりは
極めて低いしな。
そんなにオプソがあらゆる点で優位だと無理矢理ひねり出さなくても、
オプソにはオプソなりに利点欠点があるんだよ。
利点、欠点はちゃんと理解して、弱いところ、強いとこ
Re: (スコア:0)
オープンソースでもプロプラでも一緒だ、と言ってるのに、「オプソが安全」としか読み取れていない時点で致命的。
Re: (スコア:0)
> オープンソースでも、配布はバイナリで用意し、アプリケーション証明書を
> 付けておけば安全性は上がる。
あれ？ 「オプソの方が混入しやすい」っていうのは，「ソースコードが公開されて
いると本来のソフトウェアとほとんど同じで，わずかな悪意のあるコードを混入
させたものを作成することが容易」という意味だと思っていたのだけど，違うみた
いね。
ソースコードが公開されていること自体によるものだから，バイナリでも配布した
ところで安全性は上がらないものね。
アプリケーション証明書も結局は電子署名なのだから，ソースコードでもバイナリ
でも付けることはできる。他のコメントに
Re: (スコア:0)
相関があること（オープンソースの方が混入事件が多い）と、因果関係があるかどうか（オープンソースだから混入されやすい）
は別でしょう。
悪意を持った開発者のいるオープンソースプロジェクトのソースをクローズドにしたって、信頼性は上がらないと思う。
むしろ、金をかけられるなら信頼性があがるってことじゃ？
オープンソースの良いところは、需要が少ないものであっても成立しうる部分だと思うのだが。
Re: (スコア:0)
ただ、ソース非公開で攻撃者がプログラムをコミットできるなんて状況があるわけもなく。
公式リリースの場合、ソースの公開非公開を問わず、公式サイドが信用可能かどうかだけに掛かってくる。
今回の場合vsftpdの管理者がザルだったという話で、プロプラでも人事採用がザルなら同じ事になる。
# クソ上司にキレて置き土産のバックドアってネタ話とか、クソ社員が自分用バックドア(エレコムとか)を仕込んだ例はあるでしょ？
そういった状況下では、検証可能性から言ってオープンソースの方が圧倒的に安全になる。プロジェクト参加者や趣味人が差分追いかけるからね。
オー
Re: (スコア:0)
あれだけ人数がいれば誰かが気がつくと思っていたら、誰も気がつかなかった。
なんてことは良くあると思うんですけどね。
なにしろバグ、それもセキュリティホールになるようなバグが発見に何年もかかったりするのですから。
Re: (スコア:0)
その点についてはプロプラの方が不利ですからね。
参加者が見落とすケースは両者共に同程度のリスクだけど、趣味人が担保可能な分は違う。
オプソのバージョンアップでソース差分追いかける馬鹿はチラホラ居るけど、プロプラのバージョンアップで逆アセしてまで差分追いかける馬鹿は滅多に居ない。って言うか、居たらキモイ。
んで、そういう馬鹿で熱心な趣味人が憑いてないソフトは同じ土俵になる。
プロジェクト参加者の質や信頼性がオプソとプロプラで違うのは、単純に淘汰圧の掛かり方の問題であって、ソース公開の有無に依存するものではないからなぁ･･･
# 無料配布ソフトをプロプラ扱いした場合(淘汰圧を同程度にする為)、完全に五十歩百歩。
Re: (スコア:0)
本当に困難なバグは、ソースを見ても気がつかないんですよ。
Re: (スコア:0)
バイナリがまるで別物だとしても、
ファイル名偽って配布できるじゃない。
混入にソースの有無は関係なさげ。
発見の速さは、
ウイルスチェックに引っかかるコードなら、
バイナリのほうが発見は早い。
未知のコードならソース差分の検証ができる方が早い。
# ソース公開の是非は論議しても無駄ぽい
Re: (スコア:0)
それは「混入」じゃないような気がします。
偽装とか、そういう別のレベルでの問題点でしょう（これはこれで別に対処が要るでしょう）。
だから、
と言うよりも、ソースが公開されているからこそ「混入」が有り得る、と考えたほうが良いように思います。
公開されたソースがあって、ビルドができる。
だからこそ容易に、元のソフトの100%の機能を持っていて、さらに+αの何かの機能を「混入」できることになる。
まぁ、バイナリレベルで何某かの機能を「混入」できる人もそれなりに居るだろうけど、まぁ、ソース
それよりbindのDoSのほうが重大問題 (スコア:0)
Re: (スコア:0)
これじゃないの？
https://www.isc.org/software/bind/advisories/cve-2011-2464 [isc.org]
今 9.8.0-P4 をビルド中。
他のオープンソースは (スコア:0)
オープンソースだと、善人のふりしてプロジェクトに入り込み、
バックドア仕掛けるとか、防ぐことできないだろ。
firefoxは安全なのか。全世界で何億台のpcに入ってそうだし。
Re:他のオープンソースは (スコア:2)
> オープンソースだと、善人のふりしてプロジェクトに入り込み、
> バックドア仕掛けるとか、防ぐことできないだろ。
善人のふりすると言ったって、バグ修正や機能追加でパッチを沢山送って、コミッター、リリースマネージャと昇格していくには、少なくとも２、３年はかかるような気がする。
＃その２、３年の間に FTP プロトコルは消滅すると予測。
ま、しょぼいプロジェクトなら可能だろうけど、使ってる人が少なかったらバックドアを仕掛ける価値があるのかどうか。
Re: (スコア:0)
> ＃その２、３年の間に FTP プロトコルは消滅すると予測。
しねーよ
Re:他のオープンソースは (スコア:1, おもしろおかしい)
Re: (スコア:0)
それ言い出したら選択肢はIEかoperaの二択に。
Re: (スコア:0)
Re:他のオープンソースは (スコア:2, 興味深い)
そんな時間と手間がかかってしかもバレればあっさり除去されるようなことしなくても、Skypeに接触して圧力かけて盗聴用バックドア作らせたなんてのもあったでしょ。圧力の方法が金で釣ったか、暴力で脅したか、話し合いで説得したかというのは気になるけど。
オープンソースは入り込んで仕込んでだまくらかすのには弱いが、脅しや金には案外強い。
Re: (スコア:0)
プロジェクトに対して、ではなく、古参の主要メンバー個人を標的にすれば、あっさり陥落すると思うが。
OpenBSDのバックドア疑惑とか、ありましたよね。
Re: (スコア:0)
買収に強いのは、未然に防ぐよりも、陥落後の対応ですよ。
古参の主導メンバーもそうですが、企業主導のも同様、パッチ採用の可否を判断する権限があり、しかも本人はレビューなしでやりたい放題なら仕込めるとは思います。
コミッタが投げた脆弱性修正が問題なさそうなのになぜかrejectになるとかで疑われやすいし、疑いが起きればバグトラッカーが炎上するし、みんながソースを見始める。本人が改善する気がなければ、フォークしてしまえばいい。もちろん関与の証拠が見つかればマスコミに吊るし上げできるし。そういった抵抗する開発者を政府が弾圧するとかでなければね。
Re:他のオープンソースは (スコア:2, すばらしい洞察)
プロプラ版「目が多ければ」だね。
Re: (スコア:0)
むしろ、プロジェクトの重要な部分に潜り込みやすいか、そうでないかが重要で、Firefoxぐらいだと相当難しい気がするんだけど。Microsoftに雇ってもらう方が簡単じゃないか？
Re: (スコア:0)
だから、防ぐことができないのは上等で、その先が問題。
Re:他のオープンソースは (スコア:1)
>目が多ければ対処も早い。
その目がそれを見ているか？
目は見たいものを見る傾向がある。
Re: (スコア:0)
Re: (スコア:0)
目が多いと言う期待だけで、ソフトウェアの品質には向上したり、セキュリティホールが減ったりはしない。もちろん、悪意で埋め込まれたコードへの対処が速くなったりもしない。
ユーザの視点からオープンソースで確実にプロプライエタリよりも優れていると言えるのは、ハードウェアやOSに対する縛りが少ないことぐらいじゃないかな。
Re: (スコア:0)
> オープンソースだと、善人のふりしてプロジェクトに入り込み、
> バックドア仕掛けるとか、防ぐことできないだろ。
プロプライエタリだったら防げるんですか？
ちょっと何言ってるかわかりません。
Re: (スコア:0)
難しいよね。
オープンソースなら、誰が関わってるか丸わかり＆ソースは公開なんで、
仕込む前段階は簡単だよね。
そういう事では？
どーやって仕込むかはまた別問題だが。
コードチェックの段階で見つけられないような、複雑な物仕込まれる可能性
ってどの程度なんだろ。
Re: (スコア:0)
> 少なくとも、その会社に入るなり、開発チームにつながるルートが無いと
> 難しいよね。
オープンソースプロジェクトのコードレビューより杜撰な審査で
コーダーを雇ってる例だって、いくらでもあるような気が……
Re: (スコア:0)
その点、オープンソースで人不足で困っているところだと、無償ボランティアとして入り込むのは（相対的に）容易いでしょう。