怖すぎ
十分な目があれば安全が確保できるというのがオープンソースというものだが、誰かが見てるからヨシの現場猫精神でフリーライドしまくってるのであまりあてにならない
「誰かがチェックしているはず」は、皆がそう思うと、誰もチェックしないことになる。共同責任は共同無責任となる。粗探しの目もセキュリティの観点からは必要ということ。
PHPの脆弱性では？と思ったらlibpqの脆弱性
UTF-8デコードが寛容すぎたのね。本来は同じ文字を複数のバイト表現で表記できてしまうのを避ける仕様があるんだけどバリデーションが弱くて「'」に別表現が可能になっていたと。これはそう簡単には気付けないですわ
"ただの「'」はエスケープ処理が入るものの、先頭にビットを追加して2バイト文字にするとエスケープ処理をスキップできてしまっていたというわけです。"
PDOの場合はどうだろうと調べたら、pdo_pgsqlはPQescapeStringConn()を呼び出しており、これが内部でPQescapeStringInternal()呼んでいるので、libpqをアップデートしないと影響がある。
なんつー原始的なバグだ
psql経由で流した時の脆弱性ってことかな。先頭ビットを変えるだけでいいなら、世の中のシステムの大半に脆弱性がありそうだけど
ポスグレレベルでもこんな障害残ってるんだなあ
ん？PHPとPostgreSQLのどっちに問題があったんだ？...ぶこめサンキュ♡
アメリカ財務省のシステムがPHPなのが意外。バグはlibpqのものみたいだからLL言語系は割と対象になるのかな？
ほおー 0xC027… よー考えるな。
古いシステムなのか？今はエスケープしてSQLを組み立てようとはしないよね？PHPは違うの？
えーこんなのあったのか。PQescapeStringInternal の問題で主に `src/interfaces/libpq/fe-exec.c` の修正で対応した模様。PHP側もそこは信頼して使ってたんだろうなあ
サニタイズ？
こういうのあるから、やっぱりO/Rマッパー使った方が良いんかなーって思っちゃう。バインド変数になるだろうし、というかこの手のPHPプログラム結構残ってそうだよね。4とか5あたりなんだろうか？
ありゃま
“攻撃者はSQLインジェクションによってPostgreSQLに付属する対話型インターフェースであるpsqlを自由に使用できるようになり、データベースへのアクセスだけでなくpsqlを経由して任意のシステムコマンドを入力可能に”
静的プレースホルダー(PreparedStatement)なら先に実行計画立てるからSQL Injectionは原理的に大丈夫 と思ってるんだけど、なんか気持ちは怖くなるね
脆弱性見つけても報告面倒だからしないってのもありなわけで、下手すると墓場まで持ってくかも知れない。bashのシェルショックの時も、これ一体どれだけ昔からあったんだ？と思ったし
プレースホルダを使えとIPAの安全なウェブサイトの作り方にも書いてある https://www.ipa.go.jp/security/vuln/websecurity/sql.html
9年以上も… 見つからなかったなんて！ びっくりにゃ！
この記事をおすすめしました
詳細な分析記事 https://attackerkb.com/topics/G5s8ZWAbYH/cve-2024-12356/rapid7-analysis
UTF-8の冗長性に起因するよくあるチェック漏れ。エスケープはたとえ公式提供でも筋悪だな
SQLインジェクションってアプリ側の問題では？と思ったらエスケープ用の関数にバグがあったという話？できる限りプレースホルダーを使おう。
巨大なソフトウェアはデバッグ大変なんだよ。
エスケープが信頼できないの分かる。でもクライアントサイドでprepared statementを実装してるライブラリたちも信用できない…
たいていのセキュリティー対策文書では「サニタイズはやばいからプレースホルダを使いなさい」と言われている。／UTFがらみか。ややこしいからな。
アプリの SQL injection は警戒するけど、DBMS 側は盲点だな。MBCS に不慣れな人が Unicode 対応のコード書くの怖い。
PostgreSQLにあるSQLインジェクションの脆弱性が9年以上発見されずアメリカ財務省への侵入に使用されてしまう
怖すぎ
十分な目があれば安全が確保できるというのがオープンソースというものだが、誰かが見てるからヨシの現場猫精神でフリーライドしまくってるのであまりあてにならない
「誰かがチェックしているはず」は、皆がそう思うと、誰もチェックしないことになる。共同責任は共同無責任となる。粗探しの目もセキュリティの観点からは必要ということ。
PHPの脆弱性では？と思ったらlibpqの脆弱性
UTF-8デコードが寛容すぎたのね。本来は同じ文字を複数のバイト表現で表記できてしまうのを避ける仕様があるんだけどバリデーションが弱くて「'」に別表現が可能になっていたと。これはそう簡単には気付けないですわ
"ただの「'」はエスケープ処理が入るものの、先頭にビットを追加して2バイト文字にするとエスケープ処理をスキップできてしまっていたというわけです。"
PDOの場合はどうだろうと調べたら、pdo_pgsqlはPQescapeStringConn()を呼び出しており、これが内部でPQescapeStringInternal()呼んでいるので、libpqをアップデートしないと影響がある。
なんつー原始的なバグだ
psql経由で流した時の脆弱性ってことかな。先頭ビットを変えるだけでいいなら、世の中のシステムの大半に脆弱性がありそうだけど
ポスグレレベルでもこんな障害残ってるんだなあ
ん？PHPとPostgreSQLのどっちに問題があったんだ？...ぶこめサンキュ♡
アメリカ財務省のシステムがPHPなのが意外。バグはlibpqのものみたいだからLL言語系は割と対象になるのかな？
ほおー 0xC027… よー考えるな。
古いシステムなのか？今はエスケープしてSQLを組み立てようとはしないよね？PHPは違うの？
えーこんなのあったのか。PQescapeStringInternal の問題で主に `src/interfaces/libpq/fe-exec.c` の修正で対応した模様。PHP側もそこは信頼して使ってたんだろうなあ
サニタイズ？
こういうのあるから、やっぱりO/Rマッパー使った方が良いんかなーって思っちゃう。バインド変数になるだろうし、というかこの手のPHPプログラム結構残ってそうだよね。4とか5あたりなんだろうか？
ありゃま
“攻撃者はSQLインジェクションによってPostgreSQLに付属する対話型インターフェースであるpsqlを自由に使用できるようになり、データベースへのアクセスだけでなくpsqlを経由して任意のシステムコマンドを入力可能に”
静的プレースホルダー(PreparedStatement)なら先に実行計画立てるからSQL Injectionは原理的に大丈夫 と思ってるんだけど、なんか気持ちは怖くなるね
脆弱性見つけても報告面倒だからしないってのもありなわけで、下手すると墓場まで持ってくかも知れない。bashのシェルショックの時も、これ一体どれだけ昔からあったんだ？と思ったし
プレースホルダを使えとIPAの安全なウェブサイトの作り方にも書いてある https://www.ipa.go.jp/security/vuln/websecurity/sql.html
9年以上も… 見つからなかったなんて！ びっくりにゃ！
この記事をおすすめしました
詳細な分析記事 https://attackerkb.com/topics/G5s8ZWAbYH/cve-2024-12356/rapid7-analysis
UTF-8の冗長性に起因するよくあるチェック漏れ。エスケープはたとえ公式提供でも筋悪だな
SQLインジェクションってアプリ側の問題では？と思ったらエスケープ用の関数にバグがあったという話？できる限りプレースホルダーを使おう。
巨大なソフトウェアはデバッグ大変なんだよ。
エスケープが信頼できないの分かる。でもクライアントサイドでprepared statementを実装してるライブラリたちも信用できない…
たいていのセキュリティー対策文書では「サニタイズはやばいからプレースホルダを使いなさい」と言われている。／UTFがらみか。ややこしいからな。
アプリの SQL injection は警戒するけど、DBMS 側は盲点だな。MBCS に不慣れな人が Unicode 対応のコード書くの怖い。