パスワードを忘れた? アカウント作成
15634319 story
Java

「白紙」の万能署名が作れるJavaの脆弱性「Psychic Signatures」 48

ストーリー by headless
満点 部門より
Oracle が 4 月のアップデートで修正した Java SE と GraalVM Enterprise Edition の脆弱性 (CVE-2022-21449) について、発見した ForgeRock の Neil Madden 氏が英 BBC の SF ドラマ「ドクター・フー」に登場する「サイキックペーパー」にちなんだ「Psychic Signatures」と名付けている (Madden 氏のブログ記事Ars Technica の記事The Register の記事)。

ドクター・フーのサイキックペーパーは白紙のカードだが、相手に見せたい任意の内容を表示できるというもの。一方、Psychic Signatures 脆弱性は楕円曲線デジタル署名アルゴリズム (ECDSA) 署名検証の脆弱性により、攻撃者が「白紙」の署名を使用して容易に認証をバイパスできるというものだ。

具体的には ECDSA 署名を構成する 2 つの値 (r、s) はいずれも 0 であってはならないが、影響を受けるバージョンの Java が実装する署名検証ではこれらの値が 0 でないことを確認しない。そのため、攻撃者は両方の値を 0 にした署名を作ることで、任意のメッセージと任意の公開鍵に対する有効な署名として利用できる。

Oracle では影響を受けるバージョンを Java SE: 17.0.2 / 18、GraalVM Enterprise Edition 21.3.1 / 22.0.0.2 としているが、サポートの終了した Java SE 15 /16 にも脆弱性は存在する。OpenJDK では影響を受けるバージョンを 15 / 17 / 18 としている。なお、この脆弱性の CVSS スコアを Oracle が 7.5 と評価するのに対し、ForgeRock では満点の 10.0 と評価しているとのことだ。
  • by Anonymous Coward on 2022年04月23日 18時19分 (#4238191)

    白紙の万能署名が作れる脆弱性ではなく、白紙手形が作れる脆弱性か、空署名を受け入れてしまう脆弱性というべきなのでは
    原文だと"blank piece of paper"や"blank signature"という表現が出てくるけど、この2つを合体させたらダメでしょう
    「白紙の証明書」でも意味は通るけど、影響範囲がJWT、SAML、OIDC IDトークン、WebAuthn 認証メッセージと証明書に限らないので網羅性に欠ける

    ここに返信
    • Re:タイトルにもやもや (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2022年04月23日 19時24分 (#4238236)

      空署名を受け入れてしまう脆弱性ですな。

      ちなみに脆弱性のあったメソッドのあるクラスはsun.security.ec.ECDSAOperations。
      https://github.com/openjdk/jdk17u/commit/2d4103a3d929e05edca98e7703e08... [github.com]
      OpenJDK 8以前はまだこのメソッドが存在せず、同様の処理はあるものの今回対策されたのと同じ処理になってるので問題ない。
      Oracle Java 8に脆弱性があることを考えるとOracleがやらかしたように思える。

      • by Anonymous Coward on 2022年04月24日 8時19分 (#4238394)

        LTSとしてサポートされている範囲だと、OpenJDK 7,11にもverifySignedDigest()は無いですね。

        OpenJDK 7の同クラスのソース: https://github.com/openjdk/jdk7u/blob/master/jdk/src/share/classes/sun... [github.com]
        OpenJDK 8の同クラスのソース: https://github.com/openjdk/jdk8u/blob/master/jdk/src/share/classes/sun... [github.com]
        OpenJDK 11の同クラスのソース: https://github.com/openjdk/jdk11u/blob/master/src/jdk.crypto.ec/share/... [github.com]

        ただ、同じコミットでDSA.javaも直していますが、こっちは古いJDKで直さなくていいのかな・・・・

        • by Anonymous Coward

          もうややこしくてユーザーレベルじゃ対処しようがないよね
          ・使っているソフトウェアがどのバージョンを使用しているか
          ・そのバージョンが脆弱性を抱えているか
          ・オートアップデートで解消されるのか個別に手動が必要なのか

          最新のJavaはGithubから手動で更新とかいちいちやってられんよみたいな
          ライセンスも考えるとAndroidSDK入れてJAVA_HOME指定にしてsdkmanager --updateを定期実行させるとかかなぁ

          # ぶっちゃけアプリ制作者も追いきれているのか疑問

      • by Anonymous Coward

        よくバグ仕込むしsunよりfix遅いからまったり待っとけばいいよ

      • by Anonymous Coward

        アドバイザリーが修正されて、Oracle Java 7/8/11は影響を受けるバージョンから外されたよ。
        邪推すると、サポート中のバージョンを機械的に書き並べていただけじゃないかな

  • by Anonymous Coward on 2022年04月23日 18時29分 (#4238196)

    今の職場で使ってるJavaのバージョンがずっと古いやつだから関係なくて。

    ここに返信
    • by Anonymous Coward

      それは別の問題があるのでは?

      • by Anonymous Coward

        7,8,11であれば、いずれもLTSなのでExtended Support期間内 [oracle.com] ですよ (7は今年7月で終わっちゃいますが) 。

        • by Anonymous Coward

          Java8でいいや、ってなるよね。
          あと5年ぐらいしたら2030年問題とか言われるかもだけど。

        • by Anonymous Coward

          #4238196が使っているやつが7,8,11とは思えない。
          例え7,8,11でもパッチが当たっているとは思えない。
          log4jもver1使ってるような職場ですよ、きっと。

          • by Anonymous Coward

            ver1ならかえって問題なかったのでは(別の脆弱性があるけど)

  • by Anonymous Coward on 2022年04月23日 18時00分 (#4238180)

    もういらんだろ

    ここに返信
    • by Anonymous Coward on 2022年04月23日 18時32分 (#4238198)

      そういやJava陣営は「Cとの互換性が要らなければ、ビャーネはC++ではなくJavaを作っただろう」とか喧伝してて、ビャーネは「なわけねーだろ。俺があんなもん作るかよ(意訳)」と返してたっけ

    • by Anonymous Coward

      言語の問題じゃないだろ

    • by Anonymous Coward

      意識高い「系」ではなくて実際に意識は高かった。
      ただし、もう役目を終えた。
      過去の栄光をこれ以上汚さずに安らかに眠れ。

    • by Anonymous Coward

      なんでいきなりRustをディスりだすのか

    • by Anonymous Coward

      代わりは何が良い?使ったことないけど、kotlinか?

      • by Anonymous Coward

        これってVMの脆弱性だから、kotlinも当然アウトなんだけど…

      • by Anonymous Coward

        C#でいいよもう

        • by Anonymous Coward

          中の人もMSの推しもTypeScriptに移って久しいのにC#ですか…

          # Javaディスは「意識高い系」の得意技だよね

  • by Anonymous Coward on 2022年04月23日 21時04分 (#4238278)

    コイツいっつもお漏らししてんな

    ここに返信
    • by Anonymous Coward

      Java自体の問題なのか、特定のJava実装の問題なのかによっても違うな

      • by Anonymous Coward

        今回の脆弱性だとOracle JDKはOpenJDKよりかなり広い範囲のバージョンが脆弱だったな

    • by Anonymous Coward

      セーフなやつを教えてくれw
      マイナーな物はニュースにならないだけで、どの言語、環境でも致命的な問題は常に見つかっているよ。

      • by ikotom (20155) on 2022年04月24日 6時36分 (#4238375)

        Javaの場合は言語(SDK/ライブラリ)の問題とVMという実行環境の問題がセットになってますから目立つんでしょうね。

        他言語でも、たとえば C/C++であれば glibc の脆弱性が今年はじめに見つかっていますが
        これはWin環境(MSコンパイラ)では影響ありませんから
        C/C++ そのものの脆弱性とは認識されないところがあります。
        https://www.security-next.com/133636 [security-next.com]

        あるいは C# だとVMがある点でJavaと似た感じですが、
        実行環境の脆弱性は Windows update で勝手に対策してくれてる感あって
        Windows自体の脆弱性に紛れている感ありますよね・・・。

        • by Anonymous Coward

          それだけじゃない。
          Java製フレームワークって脆弱性を作り込みやすい危うい設計のものが多い印象。
          例えを単純化すると、ユーザー入力を受け入れる口にそのまま生のSQLを流し込める作りというか。

          • by Anonymous Coward on 2022年04月24日 12時02分 (#4238454)

            Struts2が脆弱性連発してSpringに移行する流れがあったけど、SpringもELでgetterにアクセスし放題な構造はまったく同じなのでは? と思っていたら案の定だった。
            https://www.scutum.jp/information/waf_tech_blog/2022/04/waf-blog-082.html [scutum.jp]

            今回はSpringのCVE-2022-22965について、それが12年前の脆弱性が蘇ったものであるという点などについて技術的な解説をしてみました。個人的にはStruts2と同じく、外部からgetterやsetterをかなり自由に呼べてしまうという根本的な設計思想そのものが非常に危険だと考えており、自分や自社の開発でSpringを利用することはありえないと考えています。

            あるクラスがgetterやsetterで「公開」しているのは基本的にJavaプログラム内のアクセスの話であり、HTTP経由でインターネットの向こう側からプロパティをセットしてくれ、と考えているわけではありません。TomcatのAccessLogValveを開発した人は間違いなくそう考えているだろうと思います。長いJavaの(特にエンタープライズ寄りの)開発の歴史においてJava Beansという概念があり、その流れからこのようなプロパティアクセスがウェブフレームワークに入り込んだのだろうと推測しますが、普通に常識的に冷静に考えてセキュリティ的にあり得ないのではというのが個人的な見解です。

            • by Anonymous Coward

              "Bean" 規約が良くなかった。
              publci field が開放されてる物であり、getter/setter でアクセス出来る物は隠蔽されてる物、
              としてFWが設計されていれば getClass() 経由でのアレコレは無かった。

              もうちょっと遡るとOOPでカプセル化の過剰なアゲが良く無かった。

          • by Anonymous Coward

            con.ecec(“delete“+hoge+...なんてことくらいどの言語の標準APIでもできるでしょ。標準APIというか各言語のDB操作関連APIの仕様か。

        • by Anonymous Coward

          .NET Frameworkは更新してくれるが.NETCore以降はしてくれないよ。
          さらに言えば自己完結型でビルドするとビルドし直さないと修正は反映されない。

          • by Anonymous Coward

            (インストールの仕方よっては?)Windows Updateで入ってくるよ
            最近だとKB5013437(.NET 6)/KB5013354(.NET 5)/KB5013353(.NET Core 3.1)

            • by Anonymous Coward

              Windows Updateではなく、Microsoft Updateで入ってくるんじゃないかな
              「.NET 5.0」「.NET Core 2.1/3.1」が“Microsoft Update”経由で更新可能に [impress.co.jp]

               なお、“Microsoft Update”は“Windows Update”とは異なるので注意。「.NET」「.NET Core」は「.NET Framework」と異なり、Windows OSとは独立した製品だ。そのため、更新プログラムの詳細オプションで[Windows の更新時に他の Microsoft 製品の更新プログラムを受

          • by Anonymous Coward

            Javaも自己完結型押しなんだよね。
            JREの単体配布やめちゃた。

            • by Anonymous Coward

              型押しとか言うから自己完結でエンボス加工される革があるのかと思ったじゃないか。

              • by Anonymous Coward

                正しくは自己完結型推しだな

        • by Anonymous Coward

          今回の件についてはOracleとOpenJDKが自前で実装していたからという点が挙げられる。C#というか.NET Coreだと、OpenSSLかWindows APIを使うので、.NETの脆弱性としてこういうのが出てくる可能性は非常に低い。

          もちろん、代わりにOpenSSLの脆弱性の影響を受けるトレードオフ。

        • by Anonymous Coward

          MS一社提供だと「実装が仕様です。使う側がチェックしないのが悪い」も出来るし

      • by Anonymous Coward

        それな。
        人間が設計、実装しているうちは撲滅は不可能よ

        • by Anonymous Coward

          AIさんのAIさんによるAIさんのための言語が出てくれば解決するって事か!?

          • by Anonymous Coward

            ちょっと意味の方向性は違うけど
            シンギュラリティってそんな感じだしな
            (解決ではないけど、人が考える必要は無くなる)

typodupeerror

Stableって古いって意味だっけ? -- Debian初級

読み込み中...