Security

C/C++ の将来性その 2

ちゃっぴ (tyappi@wankuma.com) — Mon, 01 Sep 2008 04:11:00 GMT

多くの人から指摘されましたが、C/C++ はここ数十年では絶対に無くならないと思います。というのは絶対に必須な用途があるからです。

ただ、現在ではそういった用途以外でも利用されていることが多いのではないでしょうか？

正直、そういった用途では C/C++ の未来は暗いと思います。

C/C++がもたらす問題こういった問題があるので。

では、C/C++ の未来は暗いか？自分が発言した内容と矛盾しているようですが、一部のできる人にとって道は明るいかもしれません。

利用者は現在より一層減るでしょうけど、C/C++ programmer の価値は一層高まると思います。限定的な用途となりますが、C/C++ の問題点が一般的に認識されればど素人に扱わせるなんてこと無くなるでしょうから。
# 半ば以上、期待が含まれていることは否めませんが。

それから、必要も無いのに C/C++ で coding することもできれば避けるべきではないかと思います。今後一層 C/C++ programmer で問題なく coding できる人は減るでしょうから、保守で問題を生じる可能性がより一層高まると思われます。同時に費用面で問題が生じるでしょうし。

今後一層 C/C++ を扱う開発は減ってくる流れは強ますでしょう。そういう意味では、C/C++ は大衆受けする機能を盛り込むのではなく、一般的な開発者では扱えない機能をどんどん盛り込むことにこそ未来があるんじゃないかと思います。

Security を意識した発注をするためにはどうしたらいいんだろう？

ちゃっぴ (tyappi@wankuma.com) — Mon, 01 Sep 2008 02:23:00 GMT

第01回まっちゃ４４５勉強会でも話題に上ったことですが、security を一定以上に保つためには発注時から secuirty 要件を盛り込む必要がありますね。一般に公開されているものとしては下記があります。

JNSA セキュアシステム開発ガイドライン

でもね、正直ここまで意識した RFP って現状では厳しいと思うんですよ。ぶっちゃけ、発注する側ここら辺の問題全く理解していないことも多いですし。理解しなきゃいけないという人もいますが、正直厳しいと思うんですよね。

個人的には当然やった方がいいと思いますが、そうなると RFP に定義された実装はともかくとして、試験をちゃんと行う必要があり、費用面で折り合わない場合も多いと思います。

現実問題としては、security 要件を全く盛り込まない RFP も多いわけで、そういう意味でもとりあえず security 要件をどんなものであろうと盛り込むのが現実的じゃないかと思ったり。

C/C++ の将来性

ちゃっぴ (tyappi@wankuma.com) — Sun, 31 Aug 2008 23:16:00 GMT

わんくま同盟横浜勉強会 #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 以外の設計等で脆弱性を局所化することを説明している書籍は少ないのでぜひ一読すべき。
# ただし、個人的にはちょっと問題に思える部分があるので鵜呑みにしない方がいいと思われます。もっとも、それを差し引いても概念を理解するためには非常に役立ちます。

場所を変更するなら ACL までちゃんと意識しよう！

ちゃっぴ (tyappi@wankuma.com) — Sun, 31 Aug 2008 21:36:00 GMT

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 も一致するように設定する方法も記述してもらいたいものです。

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

まっちゃ４４５に参加してみた

ちゃっぴ (tyappi@wankuma.com) — Sun, 24 Aug 2008 23:54:00 GMT

いろいろあって、だいぶ久し振りの entry になりました。

まっちゃ４４５こちらに参加してきました。

趣味で security 扱っているオイラと違い本職の人が結構いて大変ためになりました。

で、その専門家も現状の security には危機感を覚えているようで、最近では application level の脆弱性が多いこともあり、開発者と discussion したいという意見が多かったです。

ということで、10/4 にまっちゃ１３９とわんくまの合同勉強会があるらしい。

オイラもなんとか調整して参加したいと思っていますので、みなさん参加しましょう！

一般家庭向けの thin client のすすめ

ちゃっぴ (tyappi@wankuma.com) — Mon, 07 Jul 2008 00:22:00 GMT

ネタ元

そういえばちゃんと blog に書いていなかった気がするので、この際書いておきます。

企業内ではそれなりに普及してきている thin client ですけど、家庭向けのものは聞かないですね。でも、これ家庭向けにもぜひ提供してほしいと思っています。その理由を説明したいと思うんですが、その前に下記を考えてほしい。

PC を使いこなしている人って PC を扱っている人の中でどのくらいいますか？正直多めに見積もっても数割程度だと思います。それ以外の人はどのような user なのでしょうか？

私の周りを見回しても PC は持っているけど Web と E-Mail しか主に利用しないという人が結構います。もうちょっと使える人だと game をやったり、動画見たり、画像編集したり、そんなことするでしょう。

で、これらの user に共通することなんですが、PC を特定用途にしか使っていないんです。ぶっちゃけた話、一年通しても 10 程度の application しか利用しない user が約半数程度占めるんじゃないかと思っています。

そういう user は当然普段利用している作業が滞りなくできればそれでいいんです。拡張性が無いとか、別の application が利用できないとか、そういったものは気にしません。当然、security がどうだこうだというのは事が起きてからじゃない気にしませんね。

これらの user は問題でしょうか？個人的には仕方ないと思います。この層にもちゃんとした security 教育が必要という人もいますが、それはちょっと違うんじゃないかと。最低限の level でいいんじゃないですか？ID と password の重要性を認識し、他人に教えないようにする程度で問題ないかと。

ではどうしたらよいか？

その一つの解決策が一般家庭向けの thin client だと思います。では thin client の利点としてどのようなものがあるでしょうか？

管理を管理者へ一任することができる
よほど M な人でもない限り、管理なんて面倒なことしたくないでしょう。それを管理者へ一任することで面倒な管理作業から user は解放されます。また、同時に security level を一定上に保つことも容易ですね。

Thin client を利用することによって発生する欠点も当然生じます。それは下記。

制限を受ける
Thin client で一元管理を行うのですから、個々の user 毎に support を提供するのはそれだけ費用がかかります。したがって、どこかで線を引かねばなりません。結果として user は現在よりも多くの制限を受けます。

さて、このような利点・欠点がありますが、今回対象としている層ではどちらが上回っているでしょうか？Application は限られたものしか利用しないというなら、どう考えても利点の方が上回っているでしょう。

でもね、そういった service はほぼ無いんです。なんででしょうね。

Adobe Reader 8.1.2 Security Update 1

ちゃっぴ (tyappi@wankuma.com) — Tue, 24 Jun 2008 23:08:00 GMT

Security Update available for Adobe Reader and Acrobat 8.1.2

JavaScript 絡みの致命的な脆弱性が見つかったそうな。。。回避策は patch 適用です。

ただ、この security patch には注意。Install 後、[プログラムの追加と削除] で「この更新は、削除できません。」と表示されます。

Registry には下記のように uninstaller あるように見えるんだけど。

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{6846389C-BAC0-4374-808E-B120F86AF5D7}
UninstallString: MsiExec.exe /X{6846389C-BAC0-4374-808E-B120F86AF5D7}

さて、試してみるかｗｗｗ

試してみた。できないみたい。

確認 dialog 後に「この操作は現在インストールされている製品に対してのみ有効です。」だってさ。

この security patch よほどあわてて出したんじゃないかと思われるので、気をつけたほうがいいかも。

PGM (Pragmatic General Multicast)

ちゃっぴ (tyappi@wankuma.com) — Wed, 11 Jun 2008 13:06:00 GMT

Pragmatic General Multicast (PGM) の脆弱性により、サービス拒否が起こる (950762)

で出てきた PGM これ何なの？ってことでちょっと調査してみる。

へぇ～、multicast で再送とかできるようにする protocol なんだ。

で、KB950762 で置き換えられる "rmcast.sys" を調べてみたら Windows Server 2003 はともかくとして、MSMQ install されていない場合には脆弱性の影響を受けないと書いてある Windows XP でもこの driver いるんですけど。いる場所は下記。

%systemroot%\system32\drivers\

OS	Service Pack	Version
Windows XP	SP2	5.1.2600.2951
Windows XP	SP3	5.1.2600.5512

MSMQ install しないと使われないから問題ないということですかねぇ。。。

[追記]

Windows XP SP2 で検出されたよ！

すべての software に電子署名必須にしてほしい

ちゃっぴ (tyappi@wankuma.com) — Sat, 17 May 2008 01:14:00 GMT

何度か書いた記憶があるんですが。。。

有効な電子署名が無い software は defulat 実行禁止にしたほうが良いのではないでしょうか？

現状、ほとんどの malware は電子署名なぞ当然していません。というのは、Malware を実行させるのにそんなもの必要ないというのがその理由になりますね。

では、なぜ電子署名が必要なのでしょう？

電子署名を行うことによって完璧とは言えませんが、ある程度の traceability (追跡性) を確保することができます。もっとも、traceability の確保は証明書の発行をどれだけ厳しく行うかに依存していますが、有効な電子署名を行わないのが当たり前な状態より遥かにマシな状態を作り出すことができるでしょう。

ただ、一つ大きな問題があります。現状では software に署名するために必要な code signing 証明書が有償であることです。Software を有償で販売しているなら当然 code signing 証明書を購入すべきですが、無償で公開している software はその費用どこから捻出するか問題ですね。

これに関しては解決策があります。Code signing 証明書を無償で取得できるようにしてしまえばいいのです。ただし、これをやってしまうと code signing 証明書の信頼性が低下してしまいますね。これは大問題です。でも、この問題の解決策も存在します。証明書に階級を設ければいいんです。

ただ、現状では code signing 証明書に階級はありません。しかし、EV SSL のような実例もあるわけでして、既存の X.509 と互換性がある形式でも証明書の階級を作りだすことは技術的に可能です。現状では正直実施していないだけだと思っています。

証明書を無償発行することによって生じる費用が問題になると思う人もいると思います。ですが、これはより階級が高い証明書を有償販売することにより、吸収可能ではないでしょうか？個人的には、このような business model は十分に成り立つと思っています。

すべての software に電子署名を義務付ければ、少なくとも現状よりは相当マシな状態が作り出せると思います。公的な証明書を発行している機関はこのような方式を取り入れてはいだだけないでしょうか？

BitLocker に関する情報

ちゃっぴ (tyappi@wankuma.com) — Wed, 14 May 2008 04:21:00 GMT

できるだけあさってみた。

すんげ～情報量