バッファオーバーフロー脆弱性実験用サンプル

実験をする際には，必ず自身の閉じた環境内で行ってください． 他人の管理するサーバやＰＣに対して行わないでください．

同等のことを他人の管理するサーバやＰＣに対して行うと， 不正アクセス禁止法などに問われる可能性があります． (善意の検証目的でもＮＧです)

• bof-sample-1.1.zip (2016/10/11)
  • 安全のため，sinetd, stelnetd のデフォルト起動時に， ローカルホスト宛の接続しか受け付けないように変更
  • 全プログラムを一括ビルドするためのMakefileを追加
  • calendar.c を改良
    • ユーザ名チェックとパスワードチェックの関数名を修正
    • command_exec()内のコマンドチェック理由をコメントで明記
    • テスト用に残ってしまった関数のサンプル(test_exec())を追加
  • exploit用のMakefileで，ホスト環境とターゲット環境を分離する
  • プラットホーム名をCentOS6.6→Linux，FreeBSD8.3→FreeBSDに変更
  • 各ツールのMakefileにinstall/uninstallターゲットを追加し， インストール先をトップのbinディレクトリに設定することで， ツール類をまとめてビルドし集約できるようにする．
  • calendar.cを各漢字コードに変換したテキストを追加する．
  • 解析情報のディレクトリ(analyze)を新規作成し，readelf/objdump/hexdumpに よる解析結果を添付する．
  • バージョンアップ時にソースコード変更無しの実行ファイルは変化が無いよう に，展開ディレクトリからバージョン番号を無くす．
    • 実行ファイルにはビルド時のディレクトリ情報がフルパスで埋め込まれる． このためbof-sample-X.Xのようなバージョン番号があると，ビルド後の 実行ファイルに変化が起きてしまう．
    • GDBでデバッグする際には，実行ファイルのディレクトリ情報から Ｃ言語ソースコードの位置を知る．このため展開ディレクトリ名が変化した 場合，実行ファイルも再生成しないと，GDBでのデバッグ時にソースコードを 追えない．
    • でもバージョンアップする際に，Ｃ言語ソースコードに変更は無いのに いちいちビルドしなおさなきゃならないのは面倒．プログラムの論理に変更が 無ければExploitデータは作り直さなくていいはずだが，そのチェックも面倒．
    • 対策としてディレクトリ名からバージョン番号を無くして， バージョンアップしても展開ディレクトリ名が変化しないようにする．

• bof-sample-1.0.zip (2016/10/05)