KUSANAGIの脆弱性(らしきもの)の悶々

KUSANAGIについて脆弱性(らしきもの)を発見しそれらを報告した過程にて少々思い悩むことがあったので記します。

:::note warn
あまり文章を書くことに慣れていないので不自然な文になっている可能性がありますがご了承ください。
:::


## KUSANAGIとは
![kusanagi.png](https://kusanagi.tokyo/wp-content/uploads/2024/01/kusanagi-tokyo.png)
> KUSANAGI はWordPressをはじめとするCMSを簡単に実行できるように
設計、チューニングされた仮想マシンで、
超高速のスピードと妥協のないセキュリティを実現します。

というようにウェブサーバーやデータベースなどのミドルウェアをチューニングして提供しているソフトウェアです。

標準のLAMP環境に比べてKUSANAGIでキャッシュを使用時には**2,330倍**高速とされています。

KUSANAGIの上位エディションではPageSpeedのスコアを上げることができる**WEXAL**などがあり、
ConoHa Wingやお名前ドットコム レンタルサーバーなど様々な場所で使用されています。

## 脆弱性(らしきもの)について
端的に言えば
1. kusanagiコマンドを使用してウェブサイトを追加した場合、
ドキュメントルート下に**任意の**ユーザーが任意のファイル・フォルダを作成できる
1. 1.を利用して**任意の**kusanagiコマンドを実行できる

というものとなっています。

kusanagiコマンドは実質的にはkusanagiコマンドを受け付けるデーモンとUnixソケットで通信するという役割を持っており、
それらをの仕様を利用して任意のコマンドを実行することができるということになります。

## 報告した後の時系列
### 2022年03月07日
脆弱性関連情報を提出し届け出情報受信メールが届く
### 2022年05月31日
届け出内容に関する質問が届き返信する
### 2022年06月23日
届出内容が脆弱性関連情報として受理される
### 2022年07月19日
届出受理証明書のメールが届く
![kusanagi-vuln.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3731649/ad00104e-0d9d-ed95-dea8-40029ebaf1ec.png)

:::note
余談ですがこれらの届出受理証明書は未だPPAP(パスワード付きZipファイル)を使っているようです…
:::
### 2022年08月23日
JPCERT/CCから製品開発者への連絡を開始
### 2022年10月28日
届出に関して相談の連絡が来る
### 2023年12月16日
届出に関して相談の連絡が来る
### 2024年03月01日
届出の取り扱いを終了するとの連絡が来る

## やりとりした内容の詳細
### 2022年10月28日のやり取りの内容

開発会社からは、
> 当該製品ドキュメントの「root だけでなく kusanagiユーザーでも実行可能」という記述について、
正確な情報ではないため訂正する

との連絡を受けたらしいです。

![違う、そうじゃない.jpg](https://i.imgur.com/vZybmfT.jpeg)
**いや、そうじゃないでしょ！**

**ドキュメントルートのパーミッションが777
≒どのユーザーもドキュメントルート以下にフォルダ、ファイルを設置可能
≒それらでファイルを置いてアクセスした場合www権限で実行可能
≒任意のkusanagiコマンドを実行可能**
なんですよ！
<br>
その後下記の項目について質問をしました。
1. kusanagiコマンドを利用してプロビジョニングした場合、ドキュメントルートの権限が**777**に設定されて、rootやwwwグループに所属していないユーザーがファイルを置くことができ実質的に**権限を保有していない**ユーザーがその権限で**任意の**処理を実行できる
1. 何らかの方法でウェブサイトよりスクリプト等のファイルをアップロードされた際に、
それらのユーザーがkusanagiコマンドを使えてしまう
1. 1を利用して**任意の**kusanagiコマンドが実行できる

### 2023年12月16日のやり取りの内容
1回目のやりとりから、開発会社から連絡が全く来ず1年強かかりました。

1.については
> 権限設定は当該バージョンにおいて意図して設定されたものであり、
権限を持たないユーザーが任意のファイルを設置できる状況は利用者自身の使いかたの問題であり、
当該製品の責任範囲ではない

2.については
> CMS やフレームワークの脆弱性などの外部的要因が原因でのアップロードによる実行は考えられるが、
必ずしも本件製品において対応すべき問題であるとは判断できない

3.については
> システム運用・保守に関する深い知識を持たないユーザーでも、
必要最低限の操作でウェブサイトの設定が行えるように実行権限をwwwグループ権限のユーザーに与えている。
コマンド以外の方法で作成されたドキュメントルートやデータベースについては、
当該のコマンドによる操作の対象外になる

との連絡を受けました。
2.についてはwww権限で実行できるkusanagiコマンドは非常に危ないし、
3.については深い知識を持たないユーザーが知らずに事象が起こるとなれば尚のこと危ないのではないかなと思いながら、
その後に下記のような質問をしました。
1. 権限は利用者の意思によって設定されたものではなくコマンドのプログラムによって設定される
1. コマンドを利用して作成されたドキュメントルートの権限不備を利用することによって、
root、wwwグループ以外でもkusanagiコマンドを実行できるというリスクがある

### 2024年03月01日のやり取りの内容
IPAから返信があり、
1.については
> 特定のフォルダに対するパーミッションの設定はプログラムによってなされるものであったとしても、
実際にウェブサイトとして公開を行う際、どのような設定に変更するか、しないかは利用者の判断によるものであり、
必ずしも製品によって担保されるべきものとは一概に判断できない

2.については
> ウェブサーバの管理者による判断という運営管理上の問題にも起因するものである

との見解でした。

またIPAも
> プロビジョニング後のデフォルトの状態において、
より制限されたパーミッション設定がなされていることが望ましく、
届出で報告したバージョンにおいても、そのような対応がなされるか、
あるいは、取扱説明書等において適切な案内がなされると良い。

といった内容もいただきましたが、
執筆時点では依然とKUSANAGIの運営会社はこれらのことを発表していないようです。

## 各自でできる対応
KUSANAGIで利用しているウェブサイトのドキュメントルートの権限をその他のユーザーに不必要に与えないようにする、これに限ります。

またkusanagiコマンドの仕様(**www権限で実行できる**)上、同ソフトウェアで運用されるウェブサイト上に何らかの脆弱性などで任意のファイルを上げられた場合、
kusanagiコマンドを使用して勝手にウェブサイトを追加されたり、削除されたりなどが行われる可能性は依然としてあるので導入を検討する際には気を付けた方がいいかと思います。

どうやらIPAからの返信によると最新バージョンでは調整されているようですが、
更新をしていなかったりする場合にはなされない場合があるので確認するのが一番かと思います。

## まとめ
KUSANAGIを初めて触ったときに、
泥臭い各種設定をコマンドにて一発で設定できたりキャッシュを利用して高速化できたりと感動していましたが、
セキュリティを謳っている製品だけにこのような開発会社の対応を見ると少し残念さを感じました。

今回は必ずしも脆弱性とは言えないとの判断にはなりましたが、
開発会社にはこれらのことを周知させて被害を最小限に抑えるように努力していただきたいものです。

https://fitudao.work/posts/354

https://zenn.dev/fitudao3788/articles/ab6240897bcf01