ちゃっぴの監禁部屋

わんくま同盟 横浜勉強会 #1 で話題に上ったこと。

ちゃんと理解していないオイラが書くのもなんですが、やっぱり将来性がないと思う。
# 御大すみません。

多くの人が C/C++ は複雑すぎるというのが理由としてあげていましたが、もっと深刻な問題として security の問題があると思います。

多くの人がご存じのとおり、C/C++ で coding すると buffer overflow の問題を避けて通れません。このことを完璧に理解して、かつ対策を完璧に実践できるのであれば問題はありませんが、この手の問題に完璧はありません。

このことは現時点で最も脆弱性に気を使っていると思われる Microsoft でも脆弱性が無くならないことが証明していると思われます。

知らない人も結構いるでしょうけど、Microsoft は Trustworthy Computing の一環として SDL: Security Development Lifecycle を取り入れていますので、現状では security に関して一歩先に進んでいます。それでも、ご存知のとおり深刻な脆弱性は無くなっていません。
# Check-in するときに security に問題のある code を弾くことをやっているのはすごいですね。
# ぜひ、一般でも扱えるように展開してもらいたいものです。

私は基本的に software を開発する立場ではなく、software を扱う立場ですが、意識の差はあるにしろ少しでも脆弱性が少ない software を扱いたいというのは software を扱う者の共通した願望でしょう。

ということで、performance や機能の問題で C/C++ が必須とされる場合を除き、C#, VB, JAVA 等の memory 管理を自動で勝手にやってくれる言語で書いて欲しいと思っています。

ぶっちゃけ、C/C++ で全く脆弱性の存在しない code を書くのは非常に難しいです。ということで、C/C++ で書くのは本当にどうしようもない場合に限って欲しいなぁというのが願望です。

間違っても、programmer 一年目のど素人とかには絶対に手を出して欲しくないです。扱うなら下記を熟読し、完璧に理解した上で数年みっちり修業し、しかるべき code review を実施した上で release して欲しいものです。

C/C++ 扱う上で気にしなければならない security の問題点が説明されています。また、software の内部動作を理解する上でも役に立つでしょう。

Windows platform を扱うなら絶対に読んで欲しい本。Coding の問題点を指摘する書籍は他にもいろいろありますが、coding 以外の設計等で脆弱性を局所化することを説明している書籍は少ないのでぜひ一読すべき。
# ただし、個人的にはちょっと問題に思える部分があるので鵜呑みにしない方がいいと思われます。もっとも、それを差し引いても概念を理解するためには非常に役立ちます。

Default を変更することによって発生する脆弱性

以前、 上記のような entry を書いたんですが、全く浸透していないようなのでもう一回書きます。

よくある tips の一つとして IIS で利用される virtual directory の場所を変更するというのがあります。

確かに、既定の %SYSTEMDRIVE% 配下にある Inetpub 以下を別の drive に変更することによって下記利点が得られます。

• Directory traversal attack による影響の軽減
• Disk full に対する影響の軽減
• Disk fragmentation の影響の軽減

ですが、何も考えずに移動を行うと下記問題が発生します。

• Default と違う ACL が適用されることによる脆弱性の発生
• Default と違う ACL が適用されることによる動作の問題

Windows 2000 の場合、%SYSTEMDRIVE% 以外の drive は既定で everyone full control となっているため脆弱性の影響は甚大ですね。Windows XP 以降は drive root の ACL が強化されているので幾分マシ。ただし、まともに動かない可能性が出てきちゃいますね。

ではどうしたらよいか？

ACL も一緒に移せばいいんです。UNIX とかを扱う場合 copy する場合には permission を必ず確認するというのが当たり前なんですが、Windows 環境下だと気にしない人が多くて正直困ります。

具体的な方法としては Windows Server 2003 以前であれば "xcopy.exe" に /X を指定して ACL ごと copy するというのがお手軽ですね。Windows Vista 以降では "robocopy.exe" /COPY:DATSOU を利用すべきですね。

ただし、対象として指定した folder のみ ACL が複製され、上位は ACL が複製されないところに気をつけなければいけません。

これを解消するには、面倒ですけど上位の ACL を継承していない folder を割り出し、その folder に対して ACL を複製する必要があります。

この作業には "cacls.exe" が利用できます。Windows Server 2003 以降の "cacls.exe" には /s option が加わりました。/s のみを指定した場合、対象の SDDL を返します。

D:\Users\busby>cacls.exe "C:\inetpub" /s
C:\inetpub "D:PAI(A;;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;OICIIO;GA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;;FA;;;SY)(A;OICIIO;GA;;;SY)(A;;FA;;;BA)(A;OICIIO;GA;;;BA)(A;;0x1200a9;;;BU)(A;OICIIO;GXGR;;;BU)(A;;FA;;;SY)(A;OICIIO;GA;;;CO)"

こちらで得られた SDDL を /s: の後に付けることで、確実に ACL を複製できます。

Windows Vista 以降では "icacls.exe" の /save, /restore が利用できますね。Windows XP 以前では残念ながら標準ではうまい方法がありません。"SubInAcl.exe" を利用しないとダメですね。

自分で標準で設定されている ACL よりもより適切な ACL を付与できるなら別ですが、なかなかそこまで理解している人は少ないでしょう。実際、Windows Server 2003 以降の ACL はものすごく考え抜かれていて、標準の状態でまず問題がありません。ただし、Windows XP 以前だと結構穴が見つかるので、Windows Server 2003 以降の ACL を参考に手動で設定したほうがよいでしょう。

ということで、標準で設定された場所を移すのであれば、本来 ACL も意識しなければならないんです。よく高速化の tips や security の tips として標準から変更する手順が記事にありますが、この手の記事で ACL を意識しなさいと書いてあるものはほぼ見かけたことがありません。個人的には、この手の記事は正直脆弱性を助長しているとしか思えません。

ただ、変更することによって生じる利点も確かにありますから、その手の記事を書くのであれば、同時に ACL も一致するように設定する方法も記述してもらいたいものです。

もし、場所の変更のみ記述しているどうしようもない記事を見かけた場合には、脆弱性を助長していると報告してあげてください。