![Java Java](https://srad.jp/static/topics/java_64.png)
「白紙」の万能署名が作れる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 と評価しているとのことだ。
ドクター・フーのサイキックペーパーは白紙のカードだが、相手に見せたい任意の内容を表示できるというもの。一方、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 と評価しているとのことだ。
タイトルにもやもや (スコア:1)
白紙の万能署名が作れる脆弱性ではなく、白紙手形が作れる脆弱性か、空署名を受け入れてしまう脆弱性というべきなのでは
原文だと"blank piece of paper"や"blank signature"という表現が出てくるけど、この2つを合体させたらダメでしょう
「白紙の証明書」でも意味は通るけど、影響範囲がJWT、SAML、OIDC IDトークン、WebAuthn 認証メッセージと証明書に限らないので網羅性に欠ける
Re:タイトルにもやもや (スコア:2, すばらしい洞察)
空署名を受け入れてしまう脆弱性ですな。
ちなみに脆弱性のあったメソッドのあるクラスはsun.security.ec.ECDSAOperations。
https://github.com/openjdk/jdk17u/commit/2d4103a3d929e05edca98e7703e08... [github.com]
OpenJDK 8以前はまだこのメソッドが存在せず、同様の処理はあるものの今回対策されたのと同じ処理になってるので問題ない。
Oracle Java 8に脆弱性があることを考えるとOracleがやらかしたように思える。
Re:タイトルにもやもや (スコア:1)
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で直さなくていいのかな・・・・
Re: (スコア:0)
もうややこしくてユーザーレベルじゃ対処しようがないよね
・使っているソフトウェアがどのバージョンを使用しているか
・そのバージョンが脆弱性を抱えているか
・オートアップデートで解消されるのか個別に手動が必要なのか
最新のJavaはGithubから手動で更新とかいちいちやってられんよみたいな
ライセンスも考えるとAndroidSDK入れてJAVA_HOME指定にしてsdkmanager --updateを定期実行させるとかかなぁ
# ぶっちゃけアプリ制作者も追いきれているのか疑問
Re: (スコア:0)
よくバグ仕込むしsunよりfix遅いからまったり待っとけばいいよ
Re: (スコア:0)
アドバイザリーが修正されて、Oracle Java 7/8/11は影響を受けるバージョンから外されたよ。
邪推すると、サポート中のバージョンを機械的に書き並べていただけじゃないかな
よかった (スコア:1)
今の職場で使ってるJavaのバージョンがずっと古いやつだから関係なくて。
Re: (スコア:0)
それは別の問題があるのでは?
Re: (スコア:0)
7,8,11であれば、いずれもLTSなのでExtended Support期間内 [oracle.com] ですよ (7は今年7月で終わっちゃいますが) 。
Re: (スコア:0)
Java8でいいや、ってなるよね。
あと5年ぐらいしたら2030年問題とか言われるかもだけど。
Re: (スコア:0)
#4238196が使っているやつが7,8,11とは思えない。
例え7,8,11でもパッチが当たっているとは思えない。
log4jもver1使ってるような職場ですよ、きっと。
Re: (スコア:0)
ver1ならかえって問題なかったのでは(別の脆弱性があるけど)
「俺はCとは違う」病を発症した意識高い系言語 (スコア:0, オフトピック)
もういらんだろ
Re:「俺はCとは違う」病を発症した意識高い系言語 (スコア:1)
そういやJava陣営は「Cとの互換性が要らなければ、ビャーネはC++ではなくJavaを作っただろう」とか喧伝してて、ビャーネは「なわけねーだろ。俺があんなもん作るかよ(意訳)」と返してたっけ
Re: (スコア:0)
言語の問題じゃないだろ
Re: (スコア:0)
意識高い「系」ではなくて実際に意識は高かった。
ただし、もう役目を終えた。
過去の栄光をこれ以上汚さずに安らかに眠れ。
Re: (スコア:0)
なんでいきなりRustをディスりだすのか
Re: (スコア:0)
代わりは何が良い?使ったことないけど、kotlinか?
Re: (スコア:0)
これってVMの脆弱性だから、kotlinも当然アウトなんだけど…
Re:「俺はCとは違う」病を発症した意識高い系言語 (スコア:1)
いやいや、ただの標準ライブラリ部分でしょ。VMって言ったらおかしい。
kotlin でもアウトなのはその通りだけど。
Re: (スコア:0)
Re: (スコア:0)
C#でいいよもう
Re: (スコア:0)
中の人もMSの推しもTypeScriptに移って久しいのにC#ですか…
# Javaディスは「意識高い系」の得意技だよね
Re: (スコア:0)
ヘルスバーグの顔がきらい
すげーな。
当然、自分がそう陰口を叩かれても許容するんだよな?
いや、仮に自分が許容しても、許される表現じゃないわ。
Re: (スコア:0)
別ACだけど、むしろ好き・嫌いで言われる方が許容しやすくないかい?嫌いなんじゃしょうがないねえ、って。
実際、好き・嫌いは誰でも持ちうる感情だろうし。
あと、少なくとも、「~の顔は公序良俗に違反するからダメ」とかよりははるかに良い。
Re: (スコア:0)
C#のsyntaxや用語が嫌いってどの言語もダメってことか。
Re: (スコア:0)
少なくともJavaは駄目だわな
まーたJavaか (スコア:0)
コイツいっつもお漏らししてんな
Re: (スコア:0)
Java自体の問題なのか、特定のJava実装の問題なのかによっても違うな
Re: (スコア:0)
今回の脆弱性だとOracle JDKはOpenJDKよりかなり広い範囲のバージョンが脆弱だったな
Re: (スコア:0)
セーフなやつを教えてくれw
マイナーな物はニュースにならないだけで、どの言語、環境でも致命的な問題は常に見つかっているよ。
Re:まーたJavaか (スコア:2)
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自体の脆弱性に紛れている感ありますよね・・・。
Re: (スコア:0)
それだけじゃない。
Java製フレームワークって脆弱性を作り込みやすい危うい設計のものが多い印象。
例えを単純化すると、ユーザー入力を受け入れる口にそのまま生のSQLを流し込める作りというか。
Re:まーたJavaか (スコア:2, 興味深い)
Struts2が脆弱性連発してSpringに移行する流れがあったけど、SpringもELでgetterにアクセスし放題な構造はまったく同じなのでは? と思っていたら案の定だった。
https://www.scutum.jp/information/waf_tech_blog/2022/04/waf-blog-082.html [scutum.jp]
Re: (スコア:0)
"Bean" 規約が良くなかった。
publci field が開放されてる物であり、getter/setter でアクセス出来る物は隠蔽されてる物、
としてFWが設計されていれば getClass() 経由でのアレコレは無かった。
もうちょっと遡るとOOPでカプセル化の過剰なアゲが良く無かった。
Re: (スコア:0)
con.ecec(“delete“+hoge+...なんてことくらいどの言語の標準APIでもできるでしょ。標準APIというか各言語のDB操作関連APIの仕様か。
Re: (スコア:0)
.NET Frameworkは更新してくれるが.NETCore以降はしてくれないよ。
さらに言えば自己完結型でビルドするとビルドし直さないと修正は反映されない。
Re: (スコア:0)
(インストールの仕方よっては?)Windows Updateで入ってくるよ
最近だとKB5013437(.NET 6)/KB5013354(.NET 5)/KB5013353(.NET Core 3.1)
Re: (スコア:0)
Windows Updateではなく、Microsoft Updateで入ってくるんじゃないかな
「.NET 5.0」「.NET Core 2.1/3.1」が“Microsoft Update”経由で更新可能に [impress.co.jp]
Re: (スコア:0)
Javaも自己完結型押しなんだよね。
JREの単体配布やめちゃた。
Re: (スコア:0)
型押しとか言うから自己完結でエンボス加工される革があるのかと思ったじゃないか。
Re: (スコア:0)
正しくは自己完結型推しだな
Re: (スコア:0)
今回の件についてはOracleとOpenJDKが自前で実装していたからという点が挙げられる。C#というか.NET Coreだと、OpenSSLかWindows APIを使うので、.NETの脆弱性としてこういうのが出てくる可能性は非常に低い。
もちろん、代わりにOpenSSLの脆弱性の影響を受けるトレードオフ。
Re: (スコア:0)
MS一社提供だと「実装が仕様です。使う側がチェックしないのが悪い」も出来るし
Re: (スコア:0)
それな。
人間が設計、実装しているうちは撲滅は不可能よ
Re: (スコア:0)
AIさんのAIさんによるAIさんのための言語が出てくれば解決するって事か!?
Re: (スコア:0)
ちょっと意味の方向性は違うけど
シンギュラリティってそんな感じだしな
(解決ではないけど、人が考える必要は無くなる)