2008年3月 – yohgaki's blog

MomongaLinux等、パッケージをビルドする際にstack smashing attackから防御するstack protectorオプションを使ってビルドしているバイナリであればリンク先の攻撃方法では攻撃できません。しかし、インクルード攻撃に脆弱であれば、他の脆弱性を利用してカナリア値を盗む事も可能なので安全とは言えません。いずれにせよAPCを利用している場合はバージョンアップする方が良いでしょう。

追記：
CVSを見てみました。

http://cvs.php.net/viewvc.cgi/pecl/apc/apc.c?r1=3.20&r2=3.21

fileinfoがスタック変数、strcpyでオーバーフローしてます… 教科書通りの解りやすい脆弱性です…

Security

「例えば、PHPを避ける」ってなぁにその曖昧な書き方？

3月 28, 2008 投稿者 yohgaki

この記事のタイトルは参照しているページのタイトルをそのまま使っています。

誤解を招く記事 – LAMPセキュリティを強化する4つの方法で、

実行できる最も重要な対策は、PHPを使わないことです。

と、理解できない対策を勧めています。セキュリティの事を解っていない素人が書いた事は、記事の内容と趣旨から明らかです。

しかし、IPAにも同じような事が書いてあったのですね。「例えば、PHPを避ける」ってなぁにその曖昧な書き方？で書かれています。去年から掲載されていたと思います。

IIS+ASPのアプリにダメダメなWebアプリが多いのも事実ですが、言語を問わずダメなプログラムだらけです。LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠では最近発見されたPythonベースのCMS、Ploneの脆弱性を紹介していますが、Java, Perlも同じです。

特に「LAMPセキュリティを強化する4つの方法」にPHPからPerl等に替えれば安全になるように勧めていますが、著者はPerlで作った恐ろしく穴だらけのCGIの数々を見たこともないのでしょう。探さなくてもそこら中にあるのですが…. フレームワークの利用は安全性向上に役立ちますが、フレームワークを使うだけでは安全になりません。JSFやRailsで作ったから、といって自動的に安全なWebアプリは作れません。

セキュリティを向上させるために他の言語に替えて再構築するリソースがあるなら、使っているプログラム（OS,Web,言語,フレームワーク,アプリ）きちんとバージョンアップをした上で、開発者が正しいセキュリティ知識を習得できるよう努力すべきです。

企業ならソースコードレベルの監査とコンサルティングを依頼した方が、言語を替えるよりよっぽど効果的で、コストも少なく効率的です。言語を替えても設計・ソースコードレベルでのセキュリティ監査はセキュリティ維持には欠かせません。

Computer, Development, Linux, Misc, Programming, Review, Windows