memologue RSSフィード

書いている人

日記というよりは備忘録、ソフトウェア技術者の不定期メモ。あるいはバッドノウハウ集。プライベートで調査した細々した諸々のスナップショット。嘘が散りばめられています。ISO/IEC 14882(C++)とPOSIX, GCC, glibc, ELFの話ばかりで、WindowsやMacの話はありません。特に記載がなければLinux/x86とILP32が前提です。時間の経過と共に古い記事は埋もれてしまいます。検索エンジンから飛んできた場合は、ページ内検索をご利用いただくかgoogleキャッシュを閲覧してみてください。技術的な記事を書きためる場所として使っています。言及してもらえると喜びます。主要な記事の一覧を書いておきます:

にんきコンテンツ: [GCC] mainを一度も呼ばないばかりか蹂躙する / Binary2.0 Conference 2006 発表資料 / C++ で SICP / ついカッとなって実行バイナリにパッチ / hogetrace - 関数コールトレーサ

昔のPOSIX関係の記事: シグナルの送受に依存しない設計にしよう / シグナルハンドラで行ってよい処理を知ろう / マルチスレッドのプログラムでのforkはやめよう / スレッドの「非同期キャンセル」を行わない設計にしよう / スレッドの「遅延キャンセル」も出来る限り避けて通ろう / マルチスレッドプログラミングの「常識」を守ろう / C++でsynchronized methodを書くのは難しい / シグナルハンドラからのforkするのは安全か? / g++ の -fthreadsafe-statics ってオプション知ってます? / 非同期シグナルとanti-pattern / localtimeやstrtokは本当にスレッドセーフにできないのか / UNIXの規格について / マルチスレッドと共有変数 - volatile?なにそれ。 / type punning と strict aliasing / アセンブラで遊ぶ時に便利なgdb設定 / 最近の記事は一覧から

2006-06-25

[] 結局どうすりゃいいのさ (攻撃されないCFLAGS/LDFLAGS)


最近のエントリの総まとめ。適当なネットワークデーモンなどを手動でmakeする際におすすめのgccのオプション。ソフトウェアにbuffer overflowをはじめとするありがちな欠陥があった場合でも、攻撃者にプロセスを乗っ取られないよう、コンパイラやカーネルで精一杯防御するためのCFLAGSとLDFLAGS。とりあえずFedora5以降を想定しています。


# 2006/6現在で私が把握しているものです。どんどん変化(進化)しますのでご注意。特にFedoraは。。

# 自分でフォローしたい場合、Hardened Gentooのページや、Fedoraのここは役立つと思います

基本


上記のように、「多少遅くなってもセキュアなバイナリ希望」という場合、もともとのCFLAGS/LDFLAGSに加えて、

CFLAGS=-fstack-protector-all -O2 -fno-strict-aliasing -D_FORTIFY_SOURCE=2
LDFLAGS=-Wl,-z,now,-z,relro 

とするのがいいんじゃないでしょうか。さらに、ライブラリを作っているのではなく、実行ファイルを作っている場合は、

CFLAGS=-fPIE
LDFLAGS=-pie

も追加してください。実行ファイル作成の際、ライブラリのスタティックリンクはなるべくやめましょう(自分で調整できるなら)。

味付け


スタックの使いかたを巷のプログラムとはひと味違うものにしておくと、script kiddyの攻撃をかわせる可能性が高まります。たぶん。次の -mpreferred-stack-boundary オプションも付け加えましょう。

CFLAGS=-mpreferred-stack-boundary=5

なお、5のところは、12以下であればもっと大きな値でもよいです。ただしあまり大きくするとスタックをすごく*1消費しますので、せいぜい5から7程度にしておくのが無難でしょう。


さらに、元々のMakefileに -fomit-frame-pointer と書いてあったらこれを取り去り、書いていなければこれを書き加えるのも手です。return to libc attackは、フレームポインタの有無で攻撃の戦略が結構変わりますので、このフレームポインタ有無をデフォルトから反転させることで script kiddy の(ry


品質の悪そうなプログラムは使いたくない、というなら、

CFLAGS=-Wformat=2 -Wstrict-aliasing=2

でコンパイルして、あんまり多くの警告がでる場合は使用をやめるとよいでしょう。ただし、冤罪(GCCの誤警告)の可能性もありますのでご注意。

# ほんとは、 -fvolatile なる逆最適化オプションも紹介しようと思っていたのだが、このオプションはGCC3.4から存在しなくなっていた..

仕上げ


最後に、全ての実行ファイルと共有ライブラリに対して、次を実行します。最終品質検査です。

% readelf -l 実行ファイルorライブラリ | grep GNU_STACK | grep RWE
% readelf -d 実行ファイルorライブラリ | grep TEXTREL

もし、どちらかの行の実行で、あるいは両方で、なんらかの出力があったら、その 実行ファイルor共有ライブラリ は使うのを控え、別のソフトを探すとよいかもしれません。わかってそういうことをしている可能性もあるので絶対ダメというわけではないですが。


以上、Exec-Shield(NXとASLR)がonになっているのは前提とします。最近のディストリビューションならそうなっていることでしょう。

いたずら


ELF Kickersというツールに含まれている sstrip というコマンドでバイナリをstripしておくと、binutilsで解析できない(が実行はできる)バイナリになります。気安め程度ですが、objdumpやreadelfされるのが嫌なら検討するとよいかも。最近のbinutilsでは読めたりして。未確認です。elfutilsで読めるかどうかも未確認。

実行時


(あとで書く) export MALLOC_CHECK_=2

*1:O(N**2)で

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/yupo5656/20060625/p4