アカウント名:
パスワード:
攻撃者によると、Freedom Hosting II上でサイトを開設した上で、自身に割り当てられたディレクトリ内にルートディレクトリへのシンボリックリンクを作成したという。これだけでそのサーバー上でホスティングされているすべてのデータに対して読み取り権限が得られたとのこと。
なぜこれですべてのデータに対して読み取り権限が得られたのかがサッパリわからん……。
仮にそのFreedom Hosting IIがnginxで運用されていたとして、uidがwww、gidがwww-dataで動作しており。自身のuidはhogehoge、gidはusersっだったとしよう。
どこにどんなハードリンク張ろうと、シンボリックリンク張ろうと、通常のアクセスでは自身のuid/gidで許される以外の場所へのアクセスは
もともと、ルートディレクトリ等の読み取り権限があったのではないでしょうか？その他のユーザー読み取りまで制限しているファイルやフォルダが少ないのではないでしょう
700なルートディレクトリとかユーザーお断りかいな
# root権限でデーモンを起動しフォークroot権限にしてすべてを受け入れようか
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
なにそのunix extensionsオン状態のSambaを広く世間に公開しちゃった的挙動 (スコア:0)
攻撃者によると、Freedom Hosting II上でサイトを開設した上で、自身に割り当てられたディレクトリ内にルートディレクトリへのシンボリックリンクを作成したという。これだけでそのサーバー上でホスティングされているすべてのデータに対して読み取り権限が得られたとのこと。
なぜこれですべてのデータに対して読み取り権限が得られたのかがサッパリわからん……。
仮にそのFreedom Hosting IIがnginxで運用されていたとして、uidがwww、gidがwww-dataで動作しており。
自身のuidはhogehoge、gidはusersっだったとしよう。
どこにどんなハードリンク張ろうと、シンボリックリンク張ろうと、通常のアクセスでは自身のuid/gidで許される以外の場所へのアクセスは
Re:なにそのunix extensionsオン状態のSambaを広く世間に公開しちゃった的挙動 (スコア:0)
もともと、ルートディレクトリ等の読み取り権限があったのではないでしょうか？
その他のユーザー読み取りまで制限しているファイルやフォルダが少ないのではないでしょう
Re: (スコア:0)
700なルートディレクトリとかユーザーお断りかいな
# root権限でデーモンを起動しフォークroot権限にしてすべてを受け入れようか