Binary2.0 Conference 2006 発表資料 - memologue
b2con 2006の発表資料を置きました。 "Hello, binary world!" (PDF, アニメなし) ご来場頂いた皆様、主催者の皆様、どうもありがとうございました。わたし自身もとても楽しめました。IRCの様子が会場でも見られたのはよかったと思います*1。他のスピーカーの皆さんの発表資料はこちら。 (追記) 会場でDan Kogaiさんに質問いただいた、__attribute__の括弧が二重なのは何故？という件なんですが、y-hamigakiさんが解説を書いてくださっています。ありがとうございます。なるほど。 *1:会場設営時に、shudoさんが機転をきかせてスクリーンを設置してくださったようです
BF2ELF - memologue
先日書いた、適当にELFなバイナリを吐くプログラムに関して、ある人に「スタックを使うためにはプログラムヘッダに何か書かないといけないのか？と聞かれました」。えーっと、不要です*1。カーネルが勝手に確保してくれます。確保量というか最大サイズは、setrlimit(2)でというか、ulimitコマンドで調整してください。普段と同じです。ELFのエントリポイントに制御が移動した時点で%espが適切な値になってます。 ちゃんとスタックが使えることを示す例として、何かサンプルでもあったほうがよいと思いますので、適当ですがbrainfuckのコンパイラを置いときます。movl $1, (%esp); するだけの例じゃあんまりですので(そのほうがいい?)。bfの","命令と"."命令がx86のcall命令に置き換えられるんで、そこでスタック使います。なお、bfの実用的な（？）、ELFコンパイラはここ(.
補足3: .dtors overwrite をちゃんとformat string bugでやってみるか (別名 -D_FORTIFY_SOURCE=2 のすすめ) - memologue
これの続きです。 GOT overwrite でも .dtors overwrite でもなんでもいいんですけど、main関数で直接メモリを4バイト書き換えるのではなくて、ちゃんと(?) format string bug を悪用した書き換えを試してみます。リハビリです。format string bug の解説は、ここが秀逸だと思います(特に4章以降)。条件は前と同じで、 NXあり ASLRあり RELROなし PIEなし です。まず、次のような関数(vuln)を準備します。 static void vuln(const char* s) { printf(s); // <-- exploitable }で、この関数をまずは次のように呼んでみます。 vuln("0x%08x\n" "0x%08x\n" "0x%08x\n" "0x%08x\n" "0x%08x\n");printf関数に
補足2: .dtors overwrite について - memologue
これの続き。 前に書いたGOT overwriteとほぼ同じ手口なんですが、.dtorsセクションに登録されている（関数の）アドレスを書き換えて、お好きな関数を呼ぶという攻撃方法があります。.dtor overwrite とか呼ばれてます。この手口を、 NXあり ASLRあり RELROなし PIEなし という条件下で試してみます。 #include <stdio.h> #include <stdlib.h> __attribute__((destructor)) static void dtor_fn() { puts("good bye!"); } static void my_dtor_fn(void) { puts("HEHE"); } int main(int argc, char** argv) { if (argc > 1) { unsigned int* got_addr
補足: ld -z relro でどこがreadonlyになるのか (とelfutilsについて) - memologue
前に書いたrelro記事の補足です。ld -z relro すると (.got 以外は) どこがreadonlyになるのか、について。 これは、readelf -S でセクション一覧を表示して、/proc//maps の出力とセクションのアドレスを見比べる方法で知ることができますが、elfutilsを使えばもっと簡単です。elfutilsの説明は、http://people.redhat.com/drepper/ の左側、"ELF" のところをクリックしていただき、"elfutils" という記事を探して読んでもらえばわかりますが、要するにUlrich Drepperさんの手による、binutilsのreplacementですね。ELFに特化している分、出力がより親切だったり読みやすかったりします。Fedoraには標準で含まれています。見当たらなければ、 # yum install elf
結局どうすりゃいいのさ (攻撃されないCFLAGS/LDFLAGS) - memologue
最近のエントリの総まとめ。適当なネットワークデーモンなどを手動でmakeする際におすすめのgccのオプション。ソフトウェアにbuffer overflowをはじめとするありがちな欠陥があった場合でも、攻撃者にプロセスを乗っ取られないよう、コンパイラやカーネルで精一杯防御するためのCFLAGSとLDFLAGS。とりあえずFedora5以降を想定しています。 # 2006/6現在で私が把握しているものです。どんどん変化(進化)しますのでご注意。特にFedoraは。。 # 自分でフォローしたい場合、Hardened Gentooのページや、Fedoraのここは役立つと思います 基本 上記のように、「多少遅くなってもセキュアなバイナリ希望」という場合、もともとのCFLAGS/LDFLAGSに加えて、 CFLAGS=-fstack-protector-all -O2 -fno-strict-alia
ld -z relro で GOT overwrite attack から身を守る - memologue
GOT overwrite? "GOT overwrite" という、(ここでは特にLinuxの)プログラムに対する攻撃方法があります。攻撃が成功すると、そのプロセスの権限での任意コード実行等、深刻な被害を受けます。最近のGNU ld(リンカ)のオプションを用いると、この攻撃から身を守ることができるそうですので、紹介します。 最初にまとめ （こまかいことはあとで） GOT overwrite から身を守るには、gccでプログラムをリンクするときに、 -Wl,-z,now,-z,relro をつけるだけです。起動時間が遅くなるというトレードオフがありますが、GOTがreadonlyになります。GOTがreadonlyなら、GOT overwrite attack を受けたときに、プロセスがSEGVしてくれますので、安全性が高まります。プロセスのメモリマップを確認すると、きちんと w が落ちて
memologue - Java の ConTest っぽいものを、glibcの新機能(LD_AUDIT)を使って Linux + C/C++ で実現してみる
たまには何か書きます。C/C++のマルチスレッドなプログラムのユニットテストでバグを効率的に見つけるためのライブラリ?の作成について。 IBM dWのConTest はてなブックマークを眺めていたら、「ConTestを使用したマルチスレッド・ユニットのテスト - 並列テストが困難な理由とConTestの活用」というIBM developerWorksの記事が話題になっていました。 「(Javaの) 並列プログラム上での単体テストの問題点を解決する補助的なテスト手法」だそうで、例としてあがっているのは次のようなケースです。 名前を印刷するのに３つのスレッドを用意する それぞれ、「姓」「スペース」「名」を印刷する ３つのスレッドは同期を取っていない。つまりバグがある しかし、単体テストを行っても、ほぼ毎回、「姓」「スペース」「名」という正しい順序で（スレッドが実行）されてしまい、バグを検出でき
x86での分岐処理の高速化 (__builtin_expect) - memologue
if/then/else hint? (http://gcc.gnu.org/ml/gcc/2004-01/msg00496.html) というgccのMLに投稿された質問より。質問者いわく、 if (<condition>) <fastpath>; else <slowpath>;というコードがあり、conditionは滅多に偽にならないんだそうだ。そういうときに、吐き出すオブジェクトコードを少しでも効率的なものにできるか？というのが質問の趣旨。 回答として２通りの手法が示されており、それぞれ __builtin_expect()で分岐方向のヒントをソースコード中で静的に与える方法 -fprofile-arcs したバイナリで出力したプロファイル結果(.daファイル)を利用して -fbranch-probabilities で分岐頻度のフィードバックを行う方法 である。 Pentium4
g++ exception handling - memologue
Code Project という有名サイトに、VC++の例外処理方法に関する記事があります (http://www.codeproject.com/cpp/Exceptionhandler.asp) が、そこにg++の例外処理方法を解説したコメントがありました。 ざっくりと次のような事を言っています(翻訳してるわけではないので詳しくは英文読んでください)。 g++は、VC++とはちょっと違うやりかたで例外処理を実装している。g++の場合、実際に例外がthrowされない限りは、try/throw/catchを使ったコードを書いてもランタイムのコストはかからない。 foo()がbar()を呼んでいて、bar()が例外を投げるとせよ。このとき、foo()はスタックに戻りアドレス*1を置いてからbar()を呼ぶ。この戻りアドレスを仮にXとする。 このときコンパイラは、 (X, 掃除コードのアドレス
2004-10-11
2chのマルチスレッドスレッドで興味深い議論があった。見ていただければわかるが、「C++でdouble checked locking(DCL)は安全か」という話題を、CPU毎に検討している。各CPUのmemory modelの話に立ち入った、楽しい議論だ。特に、リンクされている Double-Checked Locking, Threads, Compiler Optimizations, and More http://www.nwcpp.org/Downloads/2004/DCLP_notes.pdf なるScott Mayersさんのペーパーがイケてると思う。最近書かれたばっかり。ここを読んでいなかったら当分知ることはなかっただろうな。ラッキー。 というわけで本題も興味深いのだが、とりあえずスレッドの中でいくつか示された「DCLに代わる高速なシングルトンの実装方法」が実際どの程度
UNIX上でのC++ソフトウェア設計の定石 (4) - memologue
鉄則4: スレッドの「非同期キャンセル」を行わない設計にしよう スレッドの非同期キャンセルとは： あるスレッドが別のスレッドを即座に強制終了すること 単に「設計が楽だから」「シンプルになるから」という理由でスレッドの非同期キャンセルを使うのはやめよう 一見楽そうに、シンプルそうに見えるだけ。様々な問題を引き起こす可能性が。問題の詳細を把握しないまま、スレッドの非同期キャンセルを行う設計にしないこと！ pthread規格では、あるスレッドの処理を別のスレッドが強制的に中断することが許可されています。これを、スレッドのキャンセルと呼びます。 スレッドのキャンセルには次の二種類があります。 方式１： 非同期キャンセル(PTHREAD_CANCEL_ASYNCHRONOUS) キャンセルは即座に行われる 方式２： 遅延キャンセル(PTHREAD_CANCEL_DEFERRED) キャンセルは、スレ
UNIX上でのC++ソフトウェア設計の定石 (3) - memologue
鉄則3: マルチスレッドのプログラムでのforkはやめよう マルチスレッドのプログラムで、「自スレッド以外のスレッドが存在している状態」でfork*1を行うと、さまざまな問題を引き起こす可能性があります。「問題」の典型例としては、子プロセスのデッドロックが挙げられます。問題の詳細を把握しないまま、マルチスレッドのプログラムで不用意にforkするのはやめましょう！ 何が起きるか 実例から見てみましょう。次のコードを実行すると、子プロセスは実行開始直後のdoit() 呼び出し時、高い確率でデッドロックします。 void* doit(void*) { static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; pthread_mutex_lock(&mutex); struct timespec ts = {10, 0}; nanoslee
UNIX上でのC++ソフトウェア設計の定石 (1) - memologue
UNIXは、Windowsなどの“開発者に優しい”OSと比較すると、シグナルやスレッドの利用に関して制限事項が多いですが、それを知らずにアーキテクチャ設計および実装を行ってしまうケースが散見されます。これは、再現困難なバグの温床となるでしょう。 そこで、罠に嵌らないための「鉄則」を何回かに分けて書いてみようと思います。 鉄則1: シグナルの送受に依存しない設計にしよう 他プロセスおよび自プロセスに対し、非同期シグナルを配送して処理の流れを変える設計はやめよう 非同期シグナルとは、SIGUSR1・SIGUSR2・SIGINT・SIGTERM などの、killシステムコールによって生成・配送されるシグナルのこと 単に無視(SIG_IGN)するのは問題なし スレッドとシグナルの併用もやめよう 動作の予測が困難、デバッグが困難 説明： 同期シグナルとは、SIGSEGV,SIGBUS,SIGPIPE
アセンブラで遊ぶ時に便利なgdb設定 - memologue
アセンブラで遊ぶ時に便利な ~/.gdbinit を紹介します。まず ~/.gdbinit を次のように記述してください。 # # ~/.gdbinit # # .so を shlib コマンドで手動で読み込む # set auto-solib-add 0 # スレッド生成時のSIG32でブレークしない handle SIG32 nostop # ニモニック構文の選択 # set disassembly-flavor intel set disassembly-flavor att # フラグレジスタの可読化関数 define pf printf "eflags: %s%s%s%s%s%s%s%s%s (= 0x%08u)\n",\ $eflags & 2048 ? "O":"-",\ $eflags & 1024 ? "D":"-",\ $eflags & 512 ? "I":"-",\
memologue - g++ でのスタック使用量の動的解析
Linux Memory Overcommitment の話とも関係するが、組み込み機器向けのプログラムを設計・実装する際は、たとえターゲットがMMU/仮想記憶を利用できるモノであるとしても、使用するスタック量の見積もりくらいはしておきたいと思っている。 UNIXではsetrlimit(2)で、スタック使用量をunlimitedにしてしまえば、スタック使用量の自主制限にひっかかってsegvすることはなくなる。ちなみに ulimit -s での制限は、Linuxであってもstrictに効く。しかし、物理的な限界は確実に存在するわけで、スタックのある領域にアクセスした時に物理ページに空きがなければ、プロセスはSIGSEGVで死ぬかSIGKILLで殺されてしまう。 C言語で書かれたプログラムであれば、再帰や関数ポインタさえ上手に処理(コーディング標準で制限など)できれば、コードを静的に解析して最
GNU Nana - memologue
GNU nana: improved support for assertion checking and logging in GNU C/C++ という、C/C++のデバッグライブラリがある。開発は1999年以降止まっている模様だが、「達人プログラマ」でも紹介されている、ユニークな考え方のライブラリです。日本語の解説はないようなので、少し書いてみよう。 GNU Nana 概要 GNU Nana は、 C/C++のassert関数を置換するためのソフトウェアである。 標準のassert関数や、プログラマがプロジェクトの度に書き起こす類似の関数(以下、表明関数とでもしましょう)は、次のような欠点を持つ。 ２つのバイナリが出来てしまう: 表明関数を有効にしたデバッグ版バイナリと、無効にしたリリース版バイナリ。 表明関数はコードを肥大させる(条件文や、エラーメッセージや etc...) 表明に
type punning と strict aliasing - memologue
/.JのGCC-3.4リリースの話題を追っていたら、GCC3では-O2で-fstrict-aliasingが有効だから注意せよというポスト(http://slashdot.jp/comments.pl?sid=175355&cid=537217)があった。 strict aliasing については、Radium Software Developmentさんが詳しい。これは気にしておいたほうがよさそうだ。GCCの -fstrict-aliasing の説明は次。 コンパイルされている言語に適用可能な別名規則（aliasing rule）のうち最も厳密なものをコンパイラが前提することを許します。これによって、 C（およびC++）では式の型に基く最適化を動作させることになります。例えば、ある型のオブジェクトが別の型のオブジェクトと同一アドレスに位置することは、それら2つの型がほとんど同一でない
マルチスレッドと共有変数 (続き) -- およびvolatile修飾の必要性 - memologue
複数のスレッドで変数を共有し、さらにその変数に対してread/writeの両方のオペレーションが行われるとき、その変数の操作は、上で書いたとおり、 read/writeともにmutexで保護するべき volatile修飾だけで済ませるのはNG mutexで保護するならvolatile修飾は不要 です。その根拠を、規格を引きながら見てみましょう。 The Open Group Base Specifications Issue 6 の 4.10 Memory Synchronization には、 Applications shall ensure that access to any memory location by more than one thread of control (threads or processes) is restricted such that no thr
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
return into libc アタックについて - memologue
