アカウント名:
パスワード:
普通に考えて、ロギングライブラリとして求められる機能ではないように思うのだが、開発者にもともと脆弱性を仕込む意図があったのでは無いかと勘ぐってしまうな
例えば、異常検知やユーザーの異常行動の解析のためログの吐く先がDBの場合に、Appender インタフェースを使った JDBCAppenderがよく使われますが、そこでJNDIが使われてたりします。ご参考まで:https://logging.apache.org/log4j/2.x/manual/appenders.html
これに限らず、サービス化されている機能を介してログや設定を取ったり、ログを吐き出すのに、JNDIを使うことはまあ一般的です。
といっても、今回の脆弱性が、URI書式異常時の例外をトラップするもスルーし、しかも、”This is OK.”とかコメントを書いときながら、異常URIをそのままJNDI接続処理に回してた、修正はreturn文を1行追加するだけ、ってー感じの、ちょっと恥ずかしくなる類のミスなので、勘繰りたくもなりますよね…。
"This is OK."のコードは今回の脆弱性の修正過程で一時的に入ったもので、今回の脆弱性の原因じゃないですよ。
こちら [github.io] に詳細な説明がありますが、ログ出力時に動作環境に関する様々な情報を出力したい、という要件から作られたものですから、意図的ではなかったと思いますよ。
Java 等のフレームワークやライブラリは、大規模システム向けに設計されたと考えると大体合点がいく。ロギングライブラリとしての機能が高度であるほど、設定ファイル(XML)の変更だけでロギングを柔軟に変更できる。主眼点は、ビジネスロジックへの影響を与えずに、柔軟性を確保すること。そうすることで、保守性や運用性が高まる。
発想自体はまとも、概念設計(アイディア)としても妥当、でも、現実の開発と運用に適用するとなると難易度が高くなっているだけにしか思えない。大規模システム(複雑な構成のシステム)での適用でないと恩恵を感じられないのがふつう
メッセージパターンではなく、ログメッセージ自体をさらに展開したい需要がどれほどあるかというと……
#4168363 :> ログ出力時に動作環境に関する様々な情報を出力したい、という要件から作られたものですからにしても自分できちんと文字列を作ってやれば良いわけで。
とはいえ最初は「設定の他のところでも展開してるし」程度のノリでメッセージも展開するようにしたのかもしれません。2.7あたりで{nolookups}オプションを追加した人は薄々問題に気付いていたかも。
ログ出力のために文字列作るぐらいなら、ログ出力しない場合にログ出力関連ブロックをばっさり削るなんてことはしないわけで。ログ出力しない場合の少しの無駄も許せないという人も多いんですよ。それこそ条件判断でさえ。さらに実行環境を取得して文字列を作成して出力レベルが違うから破棄なんて無駄の極み。
この絵文字、老眼には厳しいよ。文字なら普通に読める。
単に年食って保守的になり、新しい文化に否定的になってるだけな気がする
コメント #4168583 [srad.jp] は新しい文化とは正反対のいわゆるおじさん構文 [wikipedia.org]なのでは。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
短慮かも知れないが (スコア:0)
普通に考えて、ロギングライブラリとして求められる機能ではないように思うのだが、
開発者にもともと脆弱性を仕込む意図があったのでは無いかと勘ぐってしまうな
Re:短慮かも知れないが (スコア:1)
例えば、
異常検知やユーザーの異常行動の解析のためログの吐く先がDBの場合に、
Appender インタフェースを使った JDBCAppenderがよく使われますが、
そこでJNDIが使われてたりします。
ご参考まで:https://logging.apache.org/log4j/2.x/manual/appenders.html
これに限らず、
サービス化されている機能を介してログや設定を取ったり、ログを吐き出すのに、
JNDIを使うことはまあ一般的です。
といっても、
今回の脆弱性が、URI書式異常時の例外をトラップするもスルーし、
しかも、”This is OK.”とかコメントを書いときながら、
異常URIをそのままJNDI接続処理に回してた、
修正はreturn文を1行追加するだけ、
ってー感じの、
ちょっと恥ずかしくなる類のミスなので、勘繰りたくもなりますよね…。
Re: (スコア:0)
"This is OK."のコードは今回の脆弱性の修正過程で一時的に入ったもので、今回の脆弱性の原因じゃないですよ。
Re: (スコア:0)
こちら [github.io] に詳細な説明がありますが、ログ出力時に動作環境に関する様々な情報を出力したい、という要件から作られたものですから、意図的ではなかったと思いますよ。
Re: (スコア:0)
Java 等のフレームワークやライブラリは、大規模システム向けに設計されたと考えると大体合点がいく。
ロギングライブラリとしての機能が高度であるほど、設定ファイル(XML)の変更だけでロギングを柔軟に変更できる。主眼点は、ビジネスロジックへの影響を与えずに、柔軟性を確保すること。そうすることで、保守性や運用性が高まる。
発想自体はまとも、概念設計(アイディア)としても妥当、でも、現実の開発と運用に適用するとなると難易度が高くなっているだけにしか思えない。大規模システム(複雑な構成のシステム)での適用でないと恩恵を感じられないのがふつう
Re: (スコア:0)
メッセージパターンではなく、ログメッセージ自体をさらに展開したい需要がどれほどあるかというと……
#4168363 :
> ログ出力時に動作環境に関する様々な情報を出力したい、という要件から作られたものですから
にしても自分できちんと文字列を作ってやれば良いわけで。
とはいえ最初は「設定の他のところでも展開してるし」程度のノリでメッセージも展開するようにしたのかもしれません。
2.7あたりで{nolookups}オプションを追加した人は薄々問題に気付いていたかも。
Re: (スコア:0)
ログ出力のために文字列作るぐらいなら、ログ出力しない場合にログ出力関連ブロックをばっさり削るなんてことはしないわけで。
ログ出力しない場合の少しの無駄も許せないという人も多いんですよ。それこそ条件判断でさえ。
さらに実行環境を取得して文字列を作成して出力レベルが違うから破棄なんて無駄の極み。
Re: (スコア:0)
この絵文字、老眼には厳しいよ。文字なら普通に読める。
Re: (スコア:0)
単に年食って保守的になり、新しい文化に否定的になってるだけな気がする
コメント #4168583 [srad.jp] は新しい文化とは正反対の
いわゆるおじさん構文 [wikipedia.org]なのでは。