Tipsとアイデア
- structどうする?
clang/lib/Sema/SemaExpr.cpp: DiagnoseUnusedOfDecl
でunusedがついているのに利用されている変数に対してwarningを出すはずなのだが出さない、どうして? →コンパイル時ではなくエディタでエラーを出してくれてた- structどうする?
- Wasmではinallocaが実装されてないのか、やりたい
- うーんデバッガ便利だなあ、一度腰を据えていろいろ整えてみたい(知識・環境の両面で
- Hot, Coldで温度調節
- static?
- BitcodeReader.cpp:3447 何がおもろいねん
- lldでリンクするとシンボルがないってgdbで言われる、どうしてだろう?
moveAfter
で落ちるときはたいていそのBasicBlockか追加先のBasicBlockにParent Functionを設定し忘れているとき- assert追加?
isKnownSentinel
で落ちるときはたいていそれまでのBasicBlockの処理を間違えている(無限ループとかね)- LLDBとGDBのシンボルの読み込みの速さの違いはどこにある?遅延ローダ?
- breakpoint設定するときにlldbは止まる気がする
- LLDBでAI->MultiCanarySize != 0のときだけ止めたいのだが… breakpoint
expr
がうまくつかえない
Can't assign name to void values
(適当)は名前に""
を指定しておけば解決std::vector<Value*> x
をArrayRef<Value*> a(x)
のようにしてArrayRefに変換できるremoveFromParent
→”unlink”するが削除しない(ので↓のようにnullなUseが発生してエラーになる)-
code:ll
- entry:
- … (br label %aaaaが削除された)
- aaaa: ; preds = %MultiCanaryStub5, <null operand!>
- …
- entry:
-
命令を消したいのであれば代わりに
eraseFromParent
を使うべき
-
- dump()するとC++とLLVM IRの対応がわかる
- alloca = ユーザの入力が入るバッファ、とは言えないよなあ
- そういう依存関係的なのを抽出したら最小限にできるかも
- LOAD_STACK_GUARD x86向けに実装してみたい
- Tail call optimization = Sibling call optimization = 末端再帰最適化
- RPOT = Reverse Post-Order Traverse
- LLT: Low Level Type
- ValueとInstructionの違いをうまく説明するような、そういう文章
- 複数のCanaryで書き換えられた部分を集めて何が入れられたか推測するみたいな
- メモリ見れば済む話だ…
- とりあえず単体で置換できるか考えてみようかなあ
- スタートアップ(実行時〜)とリンカ(〜実行時)の壁が大きい
- ビーコン
- DDoS
- randomizationだけではなくデコイを導入する
- セグメントの動的な暗号化
- 情報を分離することを考えてみる
- 動的にfopenなどの引数を監視して、書き換えるとか
- LLVM IRのセキュリティ機構
- ニセの脆弱性をつくる
- 無駄な関数でcamoflage → control flow obfuscationとしてすでにある
- fuzzing邪魔したい
- ハイパーバイザなど他の機構でしていることをtoolchainに持ってこれないか?
- 既知の攻撃か、未知の攻撃か どっちを防ぐか考える
- これから有名になりそうな攻撃
- はぴのさんのCWEまとめ
- C++, 独自セクション, 例外
- 「pwnやれ」
- 既存のセキュリティ機能を別の所で実装してみる
- stack protector, .dataへのcanary, decoy?
- ASLR
- ret2dl-resolve
- ◯: もともとここで実装されている
- ×: ここでは無理そう
- 空欄: 未検討
カーネル(dyn. loader/linker) | スタートアップ | リンカ | コンパイラ | エミュレータ | libc | ||
---|---|---|---|---|---|---|---|
ASLR | ◯ | gp使えばできそう or 再配置テーブルを書き換え | × | × | × | × | |
PIE | ◯ | ASLRをstack/heap以外にも拡張すればよい | × | ◯ | × | × | |
RELRO | ◯(メモリをread-onlyにする) [1] [^1] | × | ◯ | × | 8 | ||
NX bit, DEP, W^X | ◯ (or CPU) | × | ◯ (-z [no]execstack) | × | × | × | 10 |
Canary, SSP | [^2] | [^4] ◯ | × | 6 ◯ | 7 | ◯ | 9 |
Fortify | [^3] | × | × | ◯ 11 | × | [^5] | |
ASCII Armor | ◯ | × | × | × | × | × |
- 1: GOT, PLTを書き換えてあげればリンカ必要ない気がする
- 2: https://www.iri-tokyo.jp/uploaded/attachment/721.pdf まるごとスタックをコピーして2つを比較している, デュアルスタックを実装する
- 3: 極端な話バイナリのパターンを見て
call printf@plt
みたいな命令を見つけて書き換えたらなんでもできる気がする - 4: initのときに関数を書き換えてあげればできそう(シンボルとか残ってない?)、ただスタートアップが動くときは.textは書き換え不能なのでRELRO(GOTを書き換えてからread-only)にするような仕組みをローダに置く必要があり面倒
- 5:
__strcpy_chk_
の処理内容をみる限り、コンパイラでどうこうしなくてもstrcpy自体をセキュアにすればいいじゃんと思うのだけれど… - 6: -pgオプションで関数開始時に呼ばれる関数を作れる(終了時はどうするか?) / [デュアルスタック] もうひとつのスタックポインタをどこに置くかが課題.
- 7: 関数呼び出し(call?)をフックして処理すればできる / [デュアルスタック]call/ret時は別のスタックにアドレスを積む
- 8: 「普段から書き込み禁止にしておいて、dynamic linkerがGOTをいじる瞬間だけdynamic linkerが自ら、mprotect(2)で書き込み許可を出す方法もありますが、これはmprotectの呼び出し回数が多くなってしまい、非常にコストがかかる(実行が遅くなる)そうで、現実的ではないそうです。」 http://d.hatena.ne.jp/yupo5656/20060618/p1
- 9: ・canary値/canaryが保存される場所を呼び出しごとに変えたい ・canaryは関数に1つで足りるのか?→もし増やすならFORTIFYの実装方法が参考になりそう
- 10: あんまり関係ないけど、実際に書き込まれた場所を別途細かく(byte単位?)記憶しておいて、そこは実行させないとか
-
11: アセンブラを直接書き換える必要があるので、ここじゃないとダメだかなあ
- マトリックスによる発想
Backlinks
SecHack365
SecHack365は学生(と社会人)が、1年間指導を受けながらセキュリティに関連したり関連しなかったりするテーマで何かをつくる長期ハッカソン。無料で、交通費も全部出る。筆者は2018年度に、「ライブラリ・リンカ・ローダ・コンパイラetcを連携させたセキュリティ機能の開発」というテーマで参加した。