MariaDBに「USAGEだけ」で管理者を乗っ取れる脆弱性 認証情報を書き換えるその手口：権限チェックの隙を突く

MariaDBに、ほとんど権限を持たない認証済みユーザーが、既存の管理者アカウントの認証情報を書き換えられる脆弱性が見つかった。なぜ権限チェックをすり抜け、管理者として接続できてしまったのだろうか。

[＠IT]

　オープンソースのデータベース管理システム「MariaDB」に、ほとんど権限を持たない認証済みユーザーが、既存の管理者アカウントの認証情報を書き換えられる脆弱（ぜいじゃく）性が見つかった。

　細工した「GRANT PROXY」文を実行することで、本来必要な権限確認をすり抜け、管理者として接続できる可能性がある。なぜ、低権限ユーザーがここまでの操作を実行できてしまったのか。その原因は、MariaDB内部の認証情報を確認する処理と保存する処理の食い違いにあった。

「USAGEだけ」で管理者アカウントを乗っ取れる？

　問題の脆弱性は、セキュリティ研究者のAssetnote氏が発見し、MariaDBの「HackerOne」プログラムを通じて報告したものだ。

　この報告では、低い権限しか持たない認証済みユーザーが「GRANT PROXY」を悪用し、既存の管理者アカウントの認証情報を書き換えられることが示された。PoC（概念実証）はMariaDB 12.3.2と、リポジトリの13.1.0ビルドで再現された。

　検証では、「USAGE ON *.*」だけを付与した一般ユーザーと、全権限にGRANT OPTIONを持つ管理者を用意。一般ユーザーから細工したGRANT PROXY文を実行すると処理が成功し、その後、攻撃者が指定した新しいパスワードで管理者アカウントに接続できた。

　重要なのは、単純に「一般ユーザーが管理者権限を取得した」わけではない点だ。既存の管理者アカウントそのものを残したまま、その認証情報だけを書き換えるため、管理者に元から付与されていた権限も維持される。

　攻撃者は、管理者の権限を新たに付与してもらうのではなく、既存の管理者アカウントのパスワードを自分が知っているものに変更し、そのアカウントでログインできるという。

　問題は、USAGE ON *.*しか与えられていないユーザーでも、GRANT PROXY文のgrantee節に複数の認証方式を指定することで発生する。先頭の認証方式を空にし、後続の認証方式に任意のパスワードを設定すると、本来必要な権限確認を通らずに既存ユーザーの認証情報を書き換えられる。

　ただし、対象となるuser@hostはあらかじめ存在している必要があり、攻撃者が後から接続する際の指定も、その対象と一致しなければならない。

　さらに、この攻撃には「ALTER USER」や「CREATE USER」の権限、「mysql」スキーマへのアクセス権、既存のPROXY権限も必要ないと報告されている。

　背景には、MariaDBのGRANT PROXYが汎用（はんよう）の「grant_list」文法を利用し、「grantee」側で「IDENTIFIED BY」や複数の認証方式を扱えることがある。また、MariaDBでは自分自身のIDを対象にPROXY権限を付与する処理が認められているため、USAGEしか持たないユーザーでも認証情報の更新処理まで到達できる。

「確認する処理」と「保存する処理」が食い違った

　なぜ、USAGEしか持たないユーザーによる認証情報の書き換えが成立したのか。報告で示された原因は、認証情報を扱う処理の間に存在した実装上の食い違いだ。

　認証情報を変更していいかどうかを確認する処理では、「copy_and_check_auth」が「LEX_USER::has_auth」の結果を基に「check_alter_user」を呼び出すかどうかを判断する。

　ここで問題になるのが「has_auth」の動作だ。この処理は複数存在する認証ノードのうち、先頭の認証ノードだけを確認する。細工したGRANT PROXY文で先頭の認証方式を空にすると、認証情報が指定されていないと判断され、必要な権限確認が省略される。

　一方、実際にユーザー情報を保存する「replace_user_table」では、認証ノードを先頭だけでなく順番に処理する。つまり、権限確認の段階では「認証情報はない」と判断される一方、保存の段階では後続の認証方式まで処理される。

　この違いを利用すると、先頭の空の認証ノードによって権限チェックを回避しながら、後続の認証ノードに指定した攻撃者任意のパスワードを既存の管理者アカウントに設定できる。

　チェックする側は先頭しか見ない。しかし保存する側は後続の情報まで処理する。　この処理の不一致が、低権限ユーザーによる認証情報の書き換えを可能にした。

　しかも書き換え後も既存管理者が持っていた権限は失われない。攻撃者は自分が設定したパスワードを使って管理者アカウントとして接続し、元から付与されていたDBA権限を利用できる。

　報告された再現例では、管理者として接続した後に現在のユーザーと権限を確認し、新しいデータベースの作成にも成功している。

　このため、悪用された場合の影響は単なる認証情報の変更にとどまらない。データベースの読み書きやユーザーの作成、権限の付与、サーバ設定の変更など、管理者権限を前提とする操作につながる可能性がある。さらに、データの破壊やサービス妨害など、DBサーバ全体への影響に発展することも考えられる。

　今回の問題が示すのは、低権限ユーザーにどの権限を与えているかだけではない。権限チェックを実装していても、そのチェックと実際のデータ更新処理で扱う情報が一致していなければ、想定外の権限操作につながり得るということだ。