アカウント名:
パスワード:
攻撃者によると、Freedom Hosting II上でサイトを開設した上で、自身に割り当てられたディレクトリ内にルートディレクトリへのシンボリックリンクを作成したという。これだけでそのサーバー上でホスティングされているすべてのデータに対して読み取り権限が得られたとのこと。
なぜこれですべてのデータに対して読み取り権限が得られたのかがサッパリわからん……。
仮にそのFreedom Hosting IIがnginxで運用されていたとして、uidがwww、gidがwww-dataで動作しており。自身のuidはhogehoge、gidはusersっだったとしよう。
どこにどんなハードリンク張ろうと、シンボリックリンク張ろうと、通常のアクセスでは自身のuid/gidで許される以外の場所へのアクセスは、cannot open directory '/ほげほげ/': Permission deniedで即落とされるだろうし。nginxを完全に乗っ取ったとしてもnginxのuid/gidを越えてアクセスはできずそれは変わらないだろ。するとFreedom Hosting IIはroot権限で動作するなにかで公開していて、それの脆弱性を突かれたってことなんだろうか。
# root権限で動いてるようなもんで外部とお話したらアカンよ。# つうかこれSambaでしょ。脆弱性がまんまじゃん。
644とか755とかデフォルトで600や700になってるディストリってあったけ？シンボリック貼ったら普通に”読める”だが所有者、グループ、一般なので
# 一般ユーザーがシンボリック元を所有権ないとこにも指定できるのがあかんという暗黙の穴
httpdがwww/www-dataで動いてた場合、ユーザフォルダ上のwwwディレクトリを表示させるためにはパーミッションXX5である必要がある。※この場合、CGI経由の盗み読みはsuexec＋同一グループ読み込み不可(705など)で防ぐ
おそらく、うっかりfollowsymlinksを禁止していなかったんだろう。悪意あるユーザのwwwディレクトリに"/"や他ユーザのhomeへのsymlinkを作られるとwww/www-dataからは読み取り放題になってしまう。
よくある話。
nginxは知らんけど、Apatchで言うところのオプションにFollowSymLinks (シンボリックリンク先もアクセスする) 入れちゃってましたテヘペロ、とかの落ちな気がする。ユーザからは見えないようにパーミッションに気を使ったけど、サーバプロセスから見えちゃいます的な。
もともと、ルートディレクトリ等の読み取り権限があったのではないでしょうか？その他のユーザー読み取りまで制限しているファイルやフォルダが少ないのではないでしょう
700なルートディレクトリとかユーザーお断りかいな
# root権限でデーモンを起動しフォークroot権限にしてすべてを受け入れようか
いや、あれやこれやの「コンテンツ」が、ある1つのuidで読めたってことじゃないですかね。マシンにあるすべてのファイルが読めた、という意味ではなくて。
シンボリックリンクを作ることで読めるってのがよくわからない…。もともとパスさえわかれば読める状態だったとか?
どうも中途半端な感が。OSのアクセス制御ではなく、アプリで何かしょぼい制御をしていたのではないでしょうか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
なにそのunix extensionsオン状態のSambaを広く世間に公開しちゃった的挙動 (スコア:0)
攻撃者によると、Freedom Hosting II上でサイトを開設した上で、自身に割り当てられたディレクトリ内にルートディレクトリへのシンボリックリンクを作成したという。これだけでそのサーバー上でホスティングされているすべてのデータに対して読み取り権限が得られたとのこと。
なぜこれですべてのデータに対して読み取り権限が得られたのかがサッパリわからん……。
仮にそのFreedom Hosting IIがnginxで運用されていたとして、uidがwww、gidがwww-dataで動作しており。
自身のuidはhogehoge、gidはusersっだったとしよう。
どこにどんなハードリンク張ろうと、シンボリックリンク張ろうと、通常のアクセスでは自身のuid/gidで許される以外の場所へのアクセスは、cannot open directory '/ほげほげ/': Permission deniedで即落とされるだろうし。
nginxを完全に乗っ取ったとしてもnginxのuid/gidを越えてアクセスはできずそれは変わらないだろ。
するとFreedom Hosting IIはroot権限で動作するなにかで公開していて、それの脆弱性を突かれたってことなんだろうか。
# root権限で動いてるようなもんで外部とお話したらアカンよ。
# つうかこれSambaでしょ。脆弱性がまんまじゃん。
Re:なにそのunix extensionsオン状態のSambaを広く世間に公開しちゃった的挙動 (スコア:1)
644とか755とか
デフォルトで600や700になってるディストリってあったけ？
シンボリック貼ったら普通に”読める”だが
所有者、グループ、一般なので
# 一般ユーザーがシンボリック元を所有権ないとこにも指定できるのがあかんという暗黙の穴
Re:なにそのunix extensionsオン状態のSambaを広く世間に公開しちゃった的挙動 (スコア:1)
httpdがwww/www-dataで動いてた場合、ユーザフォルダ上の
wwwディレクトリを表示させるためにはパーミッションXX5である必要がある。
※この場合、CGI経由の盗み読みはsuexec＋同一グループ読み込み不可(705など)で防ぐ
おそらく、うっかりfollowsymlinksを禁止していなかったんだろう。
悪意あるユーザのwwwディレクトリに"/"や他ユーザのhomeへのsymlinkを作られると
www/www-dataからは読み取り放題になってしまう。
よくある話。
Re: (スコア:0)
nginxは知らんけど、Apatchで言うところのオプションに
FollowSymLinks (シンボリックリンク先もアクセスする) 入れちゃってましたテヘペロ、
とかの落ちな気がする。
ユーザからは見えないようにパーミッションに気を使ったけど、
サーバプロセスから見えちゃいます的な。
Re: (スコア:0)
もともと、ルートディレクトリ等の読み取り権限があったのではないでしょうか？
その他のユーザー読み取りまで制限しているファイルやフォルダが少ないのではないでしょう
Re: (スコア:0)
700なルートディレクトリとかユーザーお断りかいな
# root権限でデーモンを起動しフォークroot権限にしてすべてを受け入れようか
Re: (スコア:0)
いや、あれやこれやの「コンテンツ」が、ある1つのuidで読めたってことじゃないですかね。
マシンにあるすべてのファイルが読めた、という意味ではなくて。
シンボリックリンクを作ることで読めるってのがよくわからない…。もともとパスさえわかれば読める状態だったとか?
どうも中途半端な感が。OSのアクセス制御ではなく、アプリで何かしょぼい制御をしていたのではないでしょうか。