日々常々

ふつうのプログラマがあたりまえにしたいこと。

内部構造から学ぶPostgreSQL設計・運用計画の鉄則

改訂3版。定番なのかな?少し前にTwitterのTimeLineに流れてきたのをポチって忘れてたのが届きました。やはり物理本は良い……。

「基本編」「設計/計画編」「運用編」「チューニング編」の4パート、18章で構成されています。

はじめにに書かれているようにPostgreSQL自体が手軽に使えるようになっている昨今は、内部構造や運用ノウハウを得る機会自体が減っています。 だからと言って全く知らない状態で使っていて良いかと言われると、良いわけもなく。でも使えてしまう以上、各々の立場で「どこまで詳しくなる必要があるのか?」という悩みがあると思います。

何か設定しようとかトラブルに遭遇したとかで調べようと思えばネットに玉石混交ながらも情報はありますし、ドキュメントも豊富にあります。 とは言えFAQは一問一答だったりと知りたいことに対して表面的な対処で終わることも多く、短期で対処するには適切なのですが、「浅い知識と対応になっていないか?」などと不安になる人も多いんじゃないかなと。

知識がない状態だとドキュメントで使われている用語も一般用語かPostgreSQL特有の言葉なのかの区別もつきづらいです。 この本をざっと読むだけでもPostgreSQL関連で使われる言葉にアタリがつくようになると思います。 「自分はRDS for PostgreSQLを使うから要らない知識だ」と思っているなら早計で、私はRDSのドキュメントを読んで「よくわからないなー」とか「そんなもんかなー」と思っていた内容がある程度理解できるようになりました。

言葉だけでなく、データ型やバックアップ方式など、選択肢あるものの選び方とかも書かれています。固定長文字列は性能上のメリットがあるとかたまに聞いたりするけど、無いのねぇ。 単に違いやメリデメ並べるだけじゃなく、選択におけるフローチャートとか図も多くてわかりやすい。 バックアップの話は「最初にリカバリ要件を明確にします」と書いてたのも良いところ。バックアップしてたつもりがリストアできないとか、いざ対応しなきゃいけないときに(慌てないのは無理にしても)パニックにならないためにもこの辺りは抑えておかなきゃですよねと。

最近また物理本を買うようになって、置き場どうしたものかなと悩んでおります。

3月末のSpringFrameworkのRCEを紐解いてみる

https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement

Spring Shell がかわいそうなのでSpring4Shellって呼び方はしてほしくないなーと。でもCVEの番号なんて覚えれないので、通称は欲しい。この名前で広まっちゃったから検索に使ってるけど、、、

起こりうる問題とか実務ですべき対応とかはSpringの公式アナウンスを読んでください。 なんかおかわりもあるっぽいので、SpringBoot使ってるなら 2.6.6 -> 2.6.7 と更新してくことになりそ。

中身の話します。発生直後とかは攻撃の助けになっちゃうので言及は控えめにした方がいい気もするけど、そろそろいいかなって……攻撃者はもう情報持ってるだろうし。。

Springの対応内容

コミット で「なるほどねー」と言えるなら、以降は読む必要ありません。

この CachedIntrospectionResultsHistory を見ると、ひとつ前の変更は 2020-08-29 で2年弱触られておらず、過去10年で30コミット程度。そんな変更が活発なクラスでもないです。

動かして確認してみよう

CachedIntrospectionResults の変更箇所は private なコンストラクタで、使用箇所はパッケージプライベートな static メソッド forClass(Class) だけ。このメソッドは BeanUtilsBeanWrapperImpl で使用されます。 使いやすい BeanUtils を使用して試してみましょう。

BeanUtils と言われると「ああ、getter/setter呼んだりBeanのプロパティをがさっとコピーしたりするあれね」とか「 BeanUtils とか BeanUtil とかいろんなパッケージにあるよなー」とか思い当たる方も多いでしょう。

動作確認コード

今回問題になっていたリクエストは class.module.classLoader.resources.context... というものでした。

BeanUtils はJavaBeansを扱うもので、 java.beans.PropertyDescriptor が使われています。 PropertyDescriptor はリフレクションで少し踏み込んだことをしたことがなければ見たこともないかもしれませんが、別に知らなくても問題ありません。「あーJavaBeansのパッケージにプロパティをいじるクラスがあるんだなぁ」くらいで十分すぎると思います。興味あったら触ってみるのもいいと思いますが。

JavaBeansについては以下のエントリを見ておくと心穏やかに生きられると思います。

irof.hateblo.jp

さて、やってみましょう。

  1. BeanUtils を(介して対象の CachedIntrospectionResults を)使ってプロパティ名に対する PropertyDescriptor を取得
  2. PropertyDescriptor#getReadMethod() で getterを取得
  3. getterを使ってインスタンスを取得
  4. インスタンスに対して1に戻って繰り返し
import org.springframework.beans.BeanUtils;
import java.beans.PropertyDescriptor;
import java.lang.reflect.Method;

public class CVE202222965Test {

    public static void main(String... args) throws Exception {
        Object instance = new CVE202222965Test();

        for (String propertyName : "class.module.classLoader.definedPackages".split("\\.")) {
            System.out.println("-- " + propertyName);
            PropertyDescriptor propertyDescriptor = BeanUtils.getPropertyDescriptor(instance.getClass(), propertyName);
            System.out.printf("%s に対する %s のPropertyDescriptor: %s%n", instance.getClass(), propertyName, propertyDescriptor);
            if (propertyDescriptor == null) {
                System.out.println("とれなかった(セーフ)");
                return;
            }

            Method readMethod = propertyDescriptor.getReadMethod();
            instance = readMethod.invoke(instance);
            System.out.println("PropertyDescriptorで取れた値: <<" + instance + ">>");
            if (instance == null) {
                System.out.println("とれなかった(セーフ)");
                return;
            }
        }
        System.out.println("ClassLoaderから取れちゃった: " + instance);
    }
}

Java9以降で該当するバージョンの spring-beans を使うと最後まで行きます。こんな感じ。

-- class
class cve.CVE202222965Test に対する class のPropertyDescriptor: org.springframework.beans.GenericTypeAwarePropertyDescriptor[name=class]
PropertyDescriptorで取れた値: <<class cve.CVE202222965Test>>
-- module
class java.lang.Class に対する module のPropertyDescriptor: org.springframework.beans.GenericTypeAwarePropertyDescriptor[name=module]
PropertyDescriptorで取れた値: <<unnamed module @30cb5b99>>
-- classLoader
class java.lang.Module に対する classLoader のPropertyDescriptor: org.springframework.beans.GenericTypeAwarePropertyDescriptor[name=classLoader]
PropertyDescriptorで取れた値: <<jdk.internal.loader.ClassLoaders$AppClassLoader@42110406>>
-- definedPackages
class jdk.internal.loader.ClassLoaders$AppClassLoader に対する definedPackages のPropertyDescriptor: org.springframework.beans.GenericTypeAwarePropertyDescriptor[name=definedPackages]
PropertyDescriptorで取れた値: <<[Ljava.lang.Package;@548e7350>>
ClassLoaderが取れちゃった: [Ljava.lang.Package;@548e7350

Java8以前はgetModuleメソッドがないので取れないし、対応後のspring-beansはmoduleが取れないようになってます。もちろんclassLoaderも取れない。

"class.module.classLoader.definedPackages" の最後の definedPackagesClassLoader の持っている public なgetterならなんでも良いです。 PropertyDescriptor 経由のアクセスなので乱暴なメソッド呼び出しはできませんが、今回の脆弱性DataBinder なのでsetterを呼び出しちゃう。で、setter経由でTomcatのあいつを狙ったらいけちゃう、と言うのが示されちゃった内容。 探し回ったらTomcat以外でもなんやかんや見つかるでしょうね。

こんな感じでTomcatにwar作ってデプロイしたりDataBinderを使ったりしなくても、事象の原因部分だけは動かせます。

直感的にはとにかく ClassLoader に手が届くのが気持ち悪いのですが、これ "class.module.classLoaderclass.classLoader だと だいぶ昔(2010-03)から取れない んですよね。 今回の対応前から ("classLoader".equals(pd.getName())continue してるので、元々 CachedIntrospectionResultsClassLoader を扱わせるつもりはなかったわけで。

動きを変えて遊んでみる

  • プロパティのたどりかたをクラスを読みながら変える
    • "class.module.classLoader.definedPackages" をいじってみてどこまで手が届くんだっけ?とやってみる。
  • 起点のクラスを変える
    • たとえば new CVE202222965Test() としてるのを new Object() とか、クラスローダーが違うクラスを使ってみる。
  • setterを呼んでみる
    • getReadMethod してるとこで getWriteMethod 呼べばsetterがあれば取れます。値をねじ込めます。
    • インスタンスメソッドなら値を突っ込む対象のインスタンスがなかったらあまり役に立たないんですが、手に入ったインスタンス経由で static なsetter風メソッドとかに手が届いちゃったら、ね。

……攻撃者がやってることなんですが、こう言うことしてるとJSLとかフレームワークとかの構造が少し見えるようになってくるんじゃないかなと。遊びで得られる知見ってどこで役に立つかわかりませんが、なんらかの糧にはなります。

思うところ

別段 ClassLoader に手が届いたからと言って、 ClassLoader の機能を使ってるわけではないです。初期情報を見た時は「 ClassLoader に無理矢理クラスを読み込ませてるのかな?」と思ったりしましたが、濡れ衣でした。「任意のコードを実行できるプロパティに手が届いてしまうケースが見つかった」ですかね。

今回の方法はgetterを辿ってsetterを呼び出せるなら何にでも適用できるもので、 ClassLoader は踏み台にされただけ。 ClassLoader は多くのインスタンスに手が届きやすいのでよく狙われるんですけども。

じゃぁ問題はどこにあるんだって言うと、意識的に実装してないプロパティにアクセスできるところなんじゃないかなぁ。 具体的には getClass() メソッドで Classクラスのインスタンスが取れる点。要するにすべてのインスタンスObject を実装するがゆえに Object のメソッドをすべて持っている(けれどそれが意識から漏れがち)というところが。 Object のメソッドって業務コードではだいたい直接は使わないんですよね。 toString equals hashCode あたりは意識するものの、別段 Object のメソッドである必要はないと言うか。他のメソッドはもっと意識されてないでしょうし。そういえば Java9でdeprecatedになっていた finalize がJava18の JEP 421: Deprecate Finalization for Removal で削除に一歩進みましたね。さすがに finalize くらいになると削除に対してもすごく慎重な進め方をしている模様。

話を戻して、 BeanUtils を使う場面で Object クラスのメソッドを呼び出したいと思うことはない、と言うかシンプルに考えれば対象クラスに実装していないsetter/getterを呼び出したいとは思っていなさそうなんですが、現実問題としてBeanと呼ばれるものは共通プロパティを基底Beanと呼ばれるものに定義してたりするので、ユーティリティとしては親クラスも辿って呼び出す必要はあるんですよねぇ。

対応内容を見てると「なんで getClass() の呼び出し自体止めないんだろ」とか思うところですが、 Class クラス自体を使用されたら大穴は空いたままだし、 class プロパティはなんだかんだで使われてるんだろうなぁ。。

そういえば InitBinderのフィールド指定

@InitBinder でdisallowFieldを指定する」がバージョンアップするまでの対応として挙げられています。「そんな機能知らなかった」と言う話を聞いたりしたので、haljikさんのこちらを紹介。

意図しない改竄に対して安全

「動けばいい」なら面倒なだけなんですが、こういうこと起こるとホワイトリスト方式って強いなぁと……

まとめると

と言うことで、変更内容は以下。

  • 変更前
    • Class クラスのプロパティ名 classLoaderprotectionDomain は扱わせない。(ブラックリスト
  • 変更後
    • Class クラスで扱えるプロパティは name で終わるものだけ。 (ホワイトリストに近いルール)
    • すべてのクラスで ClassLoaderProtectionDomainインスタンスは扱わせない。

だいぶ厳しくなってます。 Java9で生えた getModule メソッドが public でなかったり get から始まっていなければ、と言う感じでしょうか。私がメンテナなら「まじかー……」とか言ってると思います。 普段よく触っているコードならともかく、ほとんど更新しないコードですしね。

ともかく、今後は BeanUtilsClassLoader なプロパティと Class クラスのほとんどのプロパティは無視されるようになります。 万一使っていたら「バージョンアップしたら動かなくなった」とかなります。 そんなもの BeanUtils でやるんじゃないよ、って思うけど。踏まないこと祈ってる。

GradleWrapperの追加や更新の手順

  • Gradle 7.3.2

Gradleを使っているプロダクトだと、基本的にGradleWrapperを使うと思います。 プロジェクト作成時に最新のGradleを使うかと思いますが、Gradleの更新でたまにビルド時間短縮とかもあるんで、新機能使わなくてもWrapperも更新していきたいところです。

なお 公式のユーザーガイド に書かれている内容です。

short answer

私がやってるのは、追加も更新も「 gradle wrapper を叩く」だけです。

以下は説明。

前提

SDKMAN! でGradleをインストールしています。

sdk install gradle

なお、手元のGradleのバージョンアップも一緒です。install で新しいのがあったらインストールしてくれる。

sdk install gradle

普通は sdk upgrade gradle なんだろうけど、upgradeを忘れたり「updateとどっちだっけ?」とかなるので、雑にinstallしてたりします。覚えるコマンドが少ないのはいい・・・

windows環境でどうするかは知らない。

なるほど。

GradleWrapperがあたりまえなので手元にGradleをインストールすることも少ないかもしれません。 私は一からプロジェクトを作ることも多いので入れてます。

GradleWrapperの追加

gradle wrapper

GradleWrapperがないGradleプロジェクトではこれで追加。build.gradlewrapper タスクを書いておく必要とかはないです。(昔は要ったんだっけ。忘れた。)

……なんだけど、だいたいプロジェクト作成時に入ってたりする。 すくなくとも Spring InitializrでGradle選んだり、gradle init で作るとGradleWrapperは勝手についてきます。 なので、追加のためにgradle wrapper 叩くことは案外なかったりする。

更新

本題。一番やる頻度は高いんだろうけど、「どうするんだっけ?」ってなるやつです。

先頭で書いたように 公式のユーザーガイドにUpgrading the Gradle Wrapperと言うズバリな項目 があるんですが、この項目に Example: Upgrading the Wrapper version の見出しでこう言うの書いてるんですよね。

$ ./gradlew wrapper --gradle-version 7.3.2

BUILD SUCCESSFUL in 4s
1 actionable task: 1 executed

これが罠。「Example」であって「これ一発で更新できるよ!」って言うものじゃないんです。前段の説明に書いてるんだけど、英語読まずに コマンドだけ実行しちゃう人が結構多いので、このブログ書いてます。

推奨される方法は「追加と同じことをしよう」です。すなわち実行するコマンドは以下になります。

gradle wrapper

……最新のGradleが手元にあるならば。

gradle-wrapper.propertiesdistributionUrl を書き換える」や「 gradlew--gradle-versionを指定してwrapperタスクを実行する」は、この方法を取れないときの次善策です。

動作はしますが、これらの手順の後は ./gradlew wrapper (バージョン指定なしでよい) を実行しましょう。 なんだか面倒臭いですが、wrapper タスクでの gradlewgradlew.batgradle-wrapper.jar の更新は、実行したGradleのバージョンでなされます。なので--gradle-versionを指定しても置き替わらないんですよね。

更新手順まとめ

手元にGradleがある場合は、手元のGradleを最新にして gradle wrapper を叩けばOKです。

手元にGradleがない場合は以下のいずれかになります。

  • ./gradlew wrapper --gradle-version {目的のバージョン} を叩いて、 ./gradlew wrapper を叩く。
  • --gradle-version と言うオプションを忘れてたら gradle-wrapper.properties のURLを書き換えて、 ./gradlew wrapper を叩く。

どの手順でも「wrapper タスクを新しいGradleで叩く」は変わりありません。

更新したのをコミットするときに gradlew, gradlew.bat が更新されてなかったら、「更新できてないんじゃ?」と疑ってみるのがいいと思います。バージョンアップのたびになんか変わってますので。(今後変わらないことあるかもだけど)