頻発するOSSの脆弱性問題
今年（2017年）は上半期に起きたStruts2の脆弱性を突く攻撃が情報漏えいなどの大きな被害を出したが、近年では2014年がOSSの脆弱性問題が多発した年として皆さんの記憶に残っているだろう。
2014年は、まず4月にSSL/TLSライブラリで最も多く利用されているであろうOpenSSLに深刻な脆弱性が見つかった。これはSSLの仕様にある「Heartbeat」という機能の実装での不具合に起因している。攻撃者は、この脆弱性を突くとOpenSSLが用いられている各種サーバでのプロセス内のメモリの一部を読み取ることができるようになる。このメモリには、直前までの利用者のユーザー名やパスワード、HTTPS通信時のCookie、そしてサーバ側の秘密鍵が入っている可能性がある。
脆弱性「HeartBleed」のアイコン
この脆弱性はその悪用の容易さから非常に深刻な脆弱性と位置付けられた。脆弱性自体にも「HeartBleed」と名称が付けられ、心臓から血が流れるロゴのようなイラストまで作成された。そして、この「HeartBleed」への対応を訴える大規模キャンペーンが行われたのだ。実はHeartBleedへの対応自体は非常に単純で、OpenSSLを最新版に更新するだけでよかった。しかし、サーバ環境のバージョンアップにはさまざまな事前検証が必要とされるなどの事情があり、対応は遅れた。その結果、思いのほか被害が大きくなってしまったのだ。
さらに、HeartBleedと前後してDNSの仕様上の欠陥が公表された。この欠陥は、それ以前にも問題視されたDNSキャッシュサーバへの“毒入れ”攻撃（DNSキャッシュポイズニング攻撃）が、さらに深刻な形で実行される脆弱性だった。このDNSの欠陥（脆弱性）もOpenSSLと同様にBINDというOSSのものであった。
そして今年（2017年）は、2014年の時と同様にStruts2の大きな脆弱性が発見された。この脆弱性はパッチの適用で対応できるものだったが、脆弱性が既にサポートされていないStruts1にもあることが判明して問題を複雑化させた。なぜなら、国内SIerがこのStruts1の環境を好んで多くのシステムを構築していたため、攻撃を受ける対象が非常に多かったからだ。
これは、もちろんエンドユーザーと合意の上という場合も多いだろうが、SIerがサポートの無い状況であること知っていながら、稼動させていたということだ。サポートが無ければ通常、脆弱性を修正するパッチも出ることはまずない。すぐにシステムをStruts2にバージョンアップをしてもそれまでと同様に動作するとは限らない。国内のシステム運用管理者が絶望的な気持ちに陥ったのは想像に難くない。ただし、幸いにもStruts2向けに開発された緩和策がStruts1にも有効であることが判明したため、その終息は比較的早かった。
しかしながら、筆者はこの事件がその後のOSSへの印象が変わる大きなターニングポイントになってしまったと感じている。
