SUIDとセキュリティ

まえがき 2001年6月に、 Sys Admin Magazine、2001年6月、第10巻、第6巻は、トーマス・アキンによる 「SUIDシェルスクリプトの危険性」 という記事を公開しました。 残念ながら、2007年の夏の終わりに、この雑誌は掲載されなくなりました 。 理由は不明ですが、雑誌のサイトも存在しなくなりました。より正確には、訪問者を別のサイトにリダイレクトしています。 サイトが単に「凍結」されており、蓄積されたすべての資料のアーカイブを保持していれば、ITプロフェッショナルにとって有用な実用的な情報の保管庫となることは間違いありません。 Webでは、問題の記事のわずかなコピーを見つけることができます 。 また、オリジナルの紙版を見つけたので、少しだけ追加して無料の翻訳を提示したいと思います。 この記事のいくつかの側面は、私にとってはちょっと馬鹿げているように（たとえば、一時ファイルを使用する）、一部は珍しいようです（著者が使用するシェル）。

シェルスクリプトでSUIDを使用する危険性

難易度：シンプル



いくつかの規則。 SUIDプログラム、SUIDアプリケーションは、（ 実行属性に加えて） setuid属性を持つ実行可能ファイルです。

SUIDスクリプト、SUIDスクリプト-同様に、run属性に加えてsetuid属性を持つシェルスクリプト。

Unixシステム-UnixまたはUnixライクなオペレーティングシステム。



この記事では、 完全な開示とエクスプロイトの作成の間の細い線をたどろうとします。 目標は、SUIDアプリケーションがどのように動作して、他の人がプログラムを書くときによくある間違いを避けるのを助けるかを説明することです。 この記事で提供されている例は、すべての危険を理解するのに役立つように十分に詳細に説明されていますが、悪意のある使用の場合に示されているとおりにすべてが機能するという保証はありません。



通常、Unixスクリプトおよびプログラムは、それらを実行したユーザーの権限で実行されます。 これが、一般ユーザーが/ etc / passwdファイルを直接編集してパスワードを変更できない理由です（Unixシステムはこのファイルにパスワードを保存しなくなりましたが、アカウント情報のみ- 約 ）。 / etc / passwdへの書き込み権限がなく、実行される単一のコマンドがこれを行うことはできません。 ただし、SUIDプログラムは通常のアクセス権をオーバーライドし、常にプログラム所有者の権限で実行されます。 したがって、ユーザーは/ usr / bin / passwdコマンドを使用してパスワードを変更できます。 プログラム/ usr / bin / passwdにはSUID属性があり、所有者としてrootユーザーがいます。 常にルートとして実行されます：

% ls -l `which passwd`

-rwsr-xr-x 1 root root 23688 Jan 6 2007 /usr/bin/passwd

初心者の管理者がSUID属性を発見すると、それを万能薬と見なし、すぐに作業を簡素化するためにプログラムとスクリプトに使用し始めます。 残念ながら、非常に頻繁に間違っています。



最近SUID属性に慣れた管理者と作業する場合、次のようなシナリオがよく見られます。

% ls change-pass

-rwsr-x--- 1 root helpdesk

37 Feb 26 16:35 change-pass



% cat change-pass

#!/bin/csh -b

set user = $1

passwd $user

この単純なスクリプトは、ヘルプデスク （ヘルプデスクグループ）がユーザーパスワードをリセットできるように設計されています。これは非常に一般的なタスクです。 SUID属性がスクリプトに割り当てられ、スーパーユーザーが所有者として設定されます。 ヘルプデスクメンバーは、このスクリプトを読んで実行できます。 ふるいのようなセキュリティホールでいっぱいです。 この記事では、そのうちの7つと、それらを回避するためのオプションについて検討します。



主な懸念は、Cシェルの使用です。 このシェルのスクリプトは、環境変数の操作に対して脆弱です。 これを利用するために、攻撃者は次のようにサポートアカウントを侵害し、スーパーユーザー特権を持つシェルを取得できます。

% env TERM='`cp /bin/sh /tmp/sh;chown root /tmp/sh;chmod 4755/tmp/sh`' change-pass

レッスン1-SUIDスクリプトにCシェルを使用しない

% cat change-pass

#!/bin/ksh

user=$1

passwd $user

Kornシェルを使用してスクリプトを書き換えると、Cシェル固有の問題を回避できますが、スクリプトはPATH環境変数の操作に対して脆弱です。 プログラムへの相対パスを使用すると、攻撃者は標準の/ usr / bin / passwdの代わりにアプリケーションを実行できます。

% export PATH='/tmp'

% echo "cp /bin/sh /tmp/sh;chown root /tmp/sh;chmod 4755/tmp/sh" > /tmp/passwd

% ./change-pass

PATH変数が変更され、change-passコマンドが/ usr / bin / passwdの代わりに/ tmp / passwdを呼び出すようになりました。

レッスン2-環境変数PATHを常に手動で設定し、絶対パスを使用する必要があります

% cat change-pass

#!/bin/ksh

PATH='/bin:/usr/bin'

user=$1

/usr/bin/passwd $user

これでPATHは安全になり、絶対パスが使用されますが、よく見ると、スクリプトがrootを含むすべてのユーザーのパスワードを変更できることがわかります。 スクリプトを使用してスーパーユーザーのパスワードを変更するサポートサービス（またはクラッカー）のユーザーを望まない。

レッスン3-関係するプログラムの作業を理解する必要があります

% cat change-pass

#!/bin/ksh

PATH='/bin:/usr/bin'

user=$1

rm /tmp/.user

echo "$user" > /tmp/.user

isroot='/usr/bin/grep -c root /tmp/.user'

[ "$isroot" -gt 0 ] && echo "You Can't change root's password!" && exit

/usr/bin/passwd $user

誰かがrootを引数として入力すると、スクリプトはその自由を終了します。 しかし、引数をまったく渡さないとどうなりますか？ passwdは、それぞれ引数なしで呼び出されます。 この場合、プログラムは現在のユーザー（起動を開始した）のパスワード、つまりrootを変更します（SUIDの開始直後にジョブを実行し、現在のユーザーをrootに変更したことを忘れないでください-）。 SUID属性を持つ実行可能ファイルのコンテキストでは、現在のユーザーは常にこのファイルの所有者になります。 したがって、change-passを呼び出して単一の引数を渡さずに、スーパーユーザーのパスワードをリセットすることはまだ可能です。 したがって、3番目のレッスンの改良-プログラムがスクリプト内でどのように機能するか、特に引数を処理する方法を理解します。

% cat change-pass

#!/bin/ksh

PATH='/bin:/usr/bin'

user=$1

[ -z $user ] && echo "Usage: change-pass username" && exit

rm /tmp/.user

echo "$user" > /tmp/.user

isroot='/usr/bin/grep -c root /tmp/.user'

[ "$isroot" -gt 0 ] && echo "You Can't change root's password!" && exit

/usr/bin/passwd $user

これで、誰もrootユーザーのパスワードを変更することはできなくなりますが、一時ファイルの使用には注意を払ってください（私は個人的にこの必要性を理解できません- 約 ）。 スクリプトは一時ファイルを削除し、パスワードをリセットする必要があるユーザーの名前を入力して作成し、最後にこのユーザーがルートかどうかを確認します。 攻撃者がファイルが削除され、新しいファイルがまだ作成されていない瞬間を非常に正確に測定し、空の/tmp/.userファイルを作成するとどうなりますか？ 上書きされますか？ たぶんはい、しかしたぶんそうではない...システム設定に依存 クラッカーによって作成された/tmp/.userが上書きされない場合、スクリプトのチェックに合格し、passwdはスーパーユーザーのパスワードの変更を提案します（引数がない場合- 約 ）。 このような攻撃を容易にするために、攻撃者は特別なプログラムを作成してアクティビティ（この場合は/tmp/.userファイルの外観）を追跡し、必要なファイルを置き換えることができます。

ご注意 これらのタイプの攻撃は、時間遅延に基づいています（以下、同様の例があります）。

レッスン4-一時ファイルを使用しない、または（使用する必要がある場合は）一時ファイルを他の書き込み可能な場所に置かない

% cat change-pass

#!/bin/ksh

PATH='/bin:/usr/bin'

user=$1

[ -z $user ] && echo "Usage: change-pass username" && exit

[ "$user" = root ] && echo "You can't change root's password!" && exit

/usr/bin/passwd $user

現在のバージョンでは、一時ファイルは使用されません（そのように- 約 ）が、攻撃者はセミコロン（区切り文字）を使用してトリックを使用できます。 「;」を使用すると、複数のコマンドを1行に記述して、順番に実行できます。 これを知って、クラッカーは次のように書くことができます：

% change-pass "user;cp /bin/sh /tmp/sh;chown root /tmp/sh;chmod 4755 /tmp/sh"

スクリプトはこの入力を受け入れて実行します。

/usr/bin/passwd user;cp /bin/sh /tmp/sh;chown root /tmp/sh;chmod 4755 /tmp/sh

これらの各コマンドが実行され、シェルにスーパーユーザー特権が与えられます。 このような問題を防ぐには、ユーザー入力にセミコロンまたはその他のメタ文字が含まれていないことを確認する必要があります。

% cat change-pass

#!/bin/ksh

PATH='/bin:/usr/bin'

user=${1##*[ \\$/;()|\>\<& ]}

[ -z $user ] && echo "Usage: change-pass username" && exit

[ "$user" = root ] && "You can't change root's password!" && exit

/usr/bin/passwd $user

これで、スペース文字、\、$、/、;、（、）、|、>、<、＆、およびタブが入力から削除されます。

レッスン5-すべてのユーザー入力を信頼およびチェックせず、メタ文字を除外します

もう1つの一般的な脆弱性は、 内部フィールド分離（IFS ）コマンドシェルに関連しています。 IFSは、コマンドを区切る文字を定義します。 通常、これはスペース、タブ、または改行文字です。 スクリプトは、フルパス/ usr / bin / passwdを使用してプログラムを呼び出します。 IFSを「/」コマンドに置き換える

% export IFS='/'

スクリプトが/ usr / bin / passwdを呼び出さず、代わりにusr、bin、passwdを順番に実行します。 これで、攻撃者はusrというスクリプトを作成して、root権限でシェルを作成でき、SUIDスクリプトがそれを実行します。

レッスン6-常にIFSを手動で定義する

% cat change-pass

#!/bin/ksh

PATH='/bin:/usr/bin'

IFS=' '

user=${1##*[ \\$/;()|\>\<& ]}

[ -z $user ] && echo "Usage: change-pass username" && exit

[ "$user" = root ] && "You can't change root's password!" && exit

/usr/bin/passwd $user

残念ながら、私たちはまだ安全ではありません。 シェルチームのシナリオには、「人種」の出現に対する固有の条件があります。これは、高品質のスクリプトを記述することでさえ克服することはできません。 問題は、スクリプトが2段階で実行されることです。 最初に、システムは別のシェルインスタンスを起動します。 次に、新しいプロセスがスクリプトファイルの内容を読み取り、実行します。 4番目のレッスンで一時ファイルを使用する状況と同様に、攻撃者は時間遅延を悪用し、新しいシェルを作成してからスクリプトを読み取るまでの瞬間を利用できます。 SUIDスクリプトへのシンボリックリンクを作成する

% cd /tmp

% ln -s change-pass rootme

参照によるスクリプトの呼び出しと内容の迅速な置換

% ./rootme &

% rm rootme && echo "cp /bin/sh /tmp/sh;chown root /tmp/sh;chmod 4755 /tmp/sh" > rootme

rootとして何でも実行できます。 この手法を使用すると、成功の可能性は非常に低くなりますが、成功の可能性を高め、プロセスを自動化するのに役立つ手法とプログラムがあります。 この種の攻撃から身を守るには2つの方法があります。 1つ目は、SUIDシェルスクリプトを使用しないことです。 2つ目は、一部のシステム（Solarisなど）が所有しています。これは、開いているスクリプトファイルの記述子をコマンドシェルに渡すことで「レース」状態の発生を防ぎ、SUIDスクリプトファイルを再検出して読み取る必要がありません。

レッスン7-SUIDスクリプトを使用しない

すべての作業が完了した後でも、安全なSUIDシェルスクリプトを記述することはほとんど不可能です（これはほとんどのシステムでは不可能です）。 上記の問題により、一部のシステム（Linuxなど）では、コマンドスクリプトにSUID属性をインストールすることを推奨していません。 SUID機能を取得するには、Cラッパー、Perlスクリプト、またはsudoのようなプログラムの3つの安全な方法があります。 安全なプログラミングの初心者は、sudoまたはPerlプログラムを使用する必要があります。 Suidperlには、この記事で説明したプログラマー向けのエラー保護メカニズムが組み込まれています。 SUID属性を使用した安全なプログラミングの詳細については、書籍Practical UNIX＆Internet Security（O'Reilly＆Associates）または記事Writing Writing Safe Setuid Programsを参照してください。



あとがき。 SUIDを使用するためのプロトタイプラッパー：

#include <stdio.h>

#include <stdlib.h>

#include <sys/types.h>

#include <unistd.h>



int main()

{

//

setuid(0); // id ( root, )

//setgid(0); // (id )

system("/path/to/script.sh"); //

return 0;

}