アカウント名:
パスワード:
OSのパッケージング管理下に無いものが/usr/binとかに入っていると誤動作の元。
純正バイナリは/usr以下,サードパーティは/usr/local以下に入れるというのは,UNIX(?)における原始的で古典的なパッケージ管理法だと思います
今時のUNIX(?)ならパッケージ管理システムが必ず用意されていて例えば debian 系だったらfind /usr/bin -type f | xargs dpkg -S > /dev/nullredhat系だったらfind /usr/bin -type f | xargs rpm -qf > /dev/nullBSD系だったらportでごにょごにょを実行するだけで,簡単にパッケージング管理下にないファイルの一覧が見れますそして一覧をチェックして,不要なファイルが見つかった場合は, xargs sudo rm で消すだけです
一方,WindowsやOS Xではこのような機能が十分には整備されていません.だからこそ,/usr以下を書き込み禁止にする,という古典的な方法をとるしか術が無いのかも知れません
へー、UNIXってすすんでるねー。
で、"find /usr/bin -type f | xargs dpkg -S > /dev/null"なる先進的な呪文は、既存のファイルと同じ名前のバイナリにマルウェアを仕込むという古典的な攻撃をどうやって回避または探知してくれるのでしょうか?
1) あなたの書いたこの先進的なコマンドは新しいバイナリの出現しか探知出来ず、既存のバイナリを改竄する攻撃には無力。よってほぼ無意味。せめてdebsums(1)くらい使いましょう。2) そうやって改善しても、このコマンドはどうやっても攻撃を受けた後の事後探知しか出来ないので、最初から攻撃を防止する/usr/bin書き込み禁止に劣る。3) さらに言うと、find, xargs, dpkgはすべてその呪文で確認を取っていない/lib/libc.so.*に依存しているし、特にdpkgは/var/lib/dpkg/以下のファイルに依存している。/libやそれに準ずるディレクトリを呪文に加えるのは可能だけど、/varはそもそもの存在意義からして、改変禁止にすることは不可能。よって、race conditionを起こさなくてもこのコマンドでは探知不可能な攻撃を/usr/binに仕掛けることが出来てしまう。
一方、今回のOS Xの手法では物理的にコンソールに座っていないと攻撃が出来ない。(リモートからrootを取っても無理)どう考えてもセキュリティ上はそっちの方が上。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
他のOSにも導入して欲しい (スコア:0)
OSのパッケージング管理下に無いものが/usr/binとかに入っていると誤動作の元。
Re: (スコア:5, 参考になる)
純正バイナリは/usr以下,サードパーティは/usr/local以下に入れるというのは,
UNIX(?)における原始的で古典的なパッケージ管理法だと思います
今時のUNIX(?)ならパッケージ管理システムが必ず用意されていて
例えば debian 系だったら
find /usr/bin -type f | xargs dpkg -S > /dev/null
redhat系だったら
find /usr/bin -type f | xargs rpm -qf > /dev/null
BSD系だったら
portでごにょごにょ
を実行するだけで,簡単にパッケージング管理下にないファイルの一覧が見れます
そして一覧をチェックして,不要なファイルが見つかった場合は, xargs sudo rm で消すだけです
一方,WindowsやOS Xではこのような機能が十分には整備されていません.
だからこそ,/usr以下を書き込み禁止にする,という古典的な方法をとるしか術が無いのかも知れません
Re:他のOSにも導入して欲しい (スコア:0)
一方,WindowsやOS Xではこのような機能が十分には整備されていません.
だからこそ,/usr以下を書き込み禁止にする,という古典的な方法をとるしか術が無いのかも知れません
へー、UNIXってすすんでるねー。
で、"find /usr/bin -type f | xargs dpkg -S > /dev/null"なる先進的な呪文は、既存のファイルと同じ名前のバイナリにマルウェアを仕込むという古典的な攻撃をどうやって回避または探知してくれるのでしょうか?
1) あなたの書いたこの先進的なコマンドは新しいバイナリの出現しか探知出来ず、既存のバイナリを改竄する攻撃には無力。よってほぼ無意味。せめてdebsums(1)くらい使いましょう。
2) そうやって改善しても、このコマンドはどうやっても攻撃を受けた後の事後探知しか出来ないので、最初から攻撃を防止する/usr/bin書き込み禁止に劣る。
3) さらに言うと、find, xargs, dpkgはすべてその呪文で確認を取っていない/lib/libc.so.*に依存しているし、特にdpkgは/var/lib/dpkg/以下のファイルに依存している。/libやそれに準ずるディレクトリを呪文に加えるのは可能だけど、/varはそもそもの存在意義からして、改変禁止にすることは不可能。よって、race conditionを起こさなくてもこのコマンドでは探知不可能な攻撃を/usr/binに仕掛けることが出来てしまう。
一方、今回のOS Xの手法では物理的にコンソールに座っていないと攻撃が出来ない。(リモートからrootを取っても無理)どう考えてもセキュリティ上はそっちの方が上。