いけむランド

はてダからやってきました

CVE-2023-28709 についてざっくり調べた

Java Security

とりあえず何も考えずにアップデートしておけば、いいっちゃいいんだけど、しれっとやっても影響はないのかを一応調べた。

security.sios.jp

CVE-2023-24998 の修正が不完全でした。HTTPコネクタ設定がデフォルトではなく、クエリ文字列パラメータを使用して maxParameterCount に到達できるように設定されていて、クエリ文字列列に正確に maxParameterCount パラメータを指定するようなリクエストが送信された場合、アップロードされたリクエスト部分の制限が迂回されて DoS が発生する可能性があります。

そもそも CVE-2023-24998 がわからないため、↑の記事のリンクから辿る。

security.sios.jp

1.5 より前の Apache Commons FileUpload では、処理を行う際のリクエスト数に制限を設けるオプションがなかったため、悪意のあるアップロードにより DoS を引き起こす可能性があります。 Apache Tomcat では、Jakarta Servlet 仕様で定義されたファイルアップロード機能のために Apache Commons FileUpload の名前を変えたコピーパッケージを使用しています。Apache Tomcat は従って、Apache Commons FileUpload 脆弱性の影響を受けます。

Apache Tomcat® - Apache Tomcat 11 vulnerabilities に修正の commit があるため、その中身を見てみる。

github.com

以下、読んでみた自分の理解。

  • java/org/apache/catalina/connector/Request.java
    • 変数 maxParameterCount にパラメータ数の上限を取り出す。
    • maxParameterCount が 0 以上の場合はファイルアップロード数の上限 (upload.fileCountMax) を maxParameterCount - 実際のリクエストのパラメータ数 とする。
  • java/org/apache/tomcat/util/http/fileupload/FileUploadBase.java
    • ファイルアップロード数の上限を保持するフィールド fileCountMax を追加する。値が -1 の場合は上限なしを意味する。
    • parseRequest 内のループでアップロードされたファイル数を数え上げ、それが fileCountMax に到達したら例外を投げることでアップロード数を制限しているものと思われる。
      • ファイル数は 0 スタートであるため、fileCountMax が -1 の場合は例外を投げる if 文に入ることはないため、これにより上限なしを実現していそう。
  • webapps/docs/config/http.xml
    • 設定ファイルの maxParameterCount の対象にアップロードファイル数を含むようにした旨のコメントに書き換わっている。

これを踏まえて、CVE-2023-28709 での修正を見てみる。

github.com

CVE の説明と NVD の Weakness Enumeration のところに off-by-one エラーと書いてあるのを見て、例外発生時に実際のパラメータ数よりも 1 多い状態になるから、Request.java で upload.fileCountMax に -1 が入ってしまうパターンが起こることに気づくのにけっこう時間がかかってしまった。

というか、こういうのを見つけられる人は普段、どういうコードの読み方をしてるんだ...。