アカウント名:
パスワード:
まず、自ベンダーで無害に思えたlogoのスクリプトであっても、マクロ実行の一種では有るのだから「LibreLogoの実行もデフォルトではブロックしましょう。」と誰か突っ込む奴はいなかったんだろうか。しかも、イベントハンドラーが有効になっていたのがより悪い。コミット時にセキュリティ関連をレビューする人は居なかったのだろうか。
更に、LibreLogoといった「オマケ」機能を、デフォルト有効化するのは止めましょう。そいつは、ライバルのMSが過去にやった悪しき風習で、セキュリティホールの元だぞ。最低でも、拡張機能マネージャー等エンドユーザーが簡単に殺せるようにすべきです。
現状、アンインストールでしか簡単にLibreLogoを止められないような気がしますけど、これだと管理者権限が必要になったりしてダメだと思います。about:config的な奴で止められるよ!では要求スキルが高すぎてダメです。
LibreOfficeチームは、我が子可愛さにデフォルト有効を止められない、変な親心でも持ってるんだろうか。セキュリティホールはセキュリティホールなんだから、ちゃんと解決するまでLibreLogoを削除するとか、文書を開いた後、毎回明示的に有効化しない限り使用できない位の対策を取っても良いと思うのだけど。
長いことLibreOffice使ってるけどインストール時の設定は最初にカスタム設定したのを引き継いでいたから「インストーラに含まれているけど標準設定ではインストールされないコンポーネント」だと思ってたわ
そもそも、LibreLogoの実行でPythonの生スクリプトが動くのがいかんのだよね?
LibreLogoの言語仕様がいまいちわからんのだが、ドキュメント外に影響を及ぼすものでは無いのだろう。であればLibreOfficeの「マクロ」レベルのスクリプト制御は不要としてもいい。「Logoプログラムの実行」をクリックしないと実行できないのなら、想定外の起動の懸念要素はほぼ無いだろう。
しかし…そんなバグ入るかというか、直さ/せないもんなのかってのがどうもわからん。
そう、その通り。LibreLogoがPythonで実装されているからなのか、任意のPythonスクリプトが動いてしまうのが問題。Logoが任意のPythonスクリプトが動作するという言語しようなら仕方ないかもしれない。でも、だったらVBAマクロのように毎回許可を求めたりするコントロール機能は必要になる。でも、現時点ではそんな機能は無い。
しかも、不味い事にLibreLogoは隠し文字(display:none的なもの)も普通に実行する。つまり、無害なLogoスクリプトを表示し、悪意あるPythonスクリプトを隠し文字にしたODF文書を配布してしまえば良い。そうすれば、ターゲットは、無害なLogoスクリプトを実行したつもりで、悪意あるスクリプトも実行してくれる。といった、かなりヤバイ状況なのに、呑気にLibreLogoの穴をそのままにしてる訳です。
実は既に悪用されてるかもね。
LibreLogoがどれくらい古くからあるのか知らんけど、昔のファイルフォーマットはセキュリティ何それおいしいのみたいな感じで平然と任意の外部コマンド実行ができたりすることがあるので(Windows HelpとかPDFとか)「ドキュメント外に影響を及ぼすものでは無い」とかんたんに言い切れないのかもしれない
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
セキュリティモデルが破綻してたんだから、当然。 (スコア:0)
まず、自ベンダーで無害に思えたlogoのスクリプトであっても、
マクロ実行の一種では有るのだから「LibreLogoの実行もデフォルトではブロックしましょう。」と誰か突っ込む奴はいなかったんだろうか。
しかも、イベントハンドラーが有効になっていたのがより悪い。
コミット時にセキュリティ関連をレビューする人は居なかったのだろうか。
更に、LibreLogoといった「オマケ」機能を、デフォルト有効化するのは止めましょう。
そいつは、ライバルのMSが過去にやった悪しき風習で、セキュリティホールの元だぞ。
最低でも、拡張機能マネージャー等エンドユーザーが簡単に殺せるようにすべきです。
現状、アンインストールでしか簡単にLibreLogoを止められないような気がしますけど、
これだと管理者権限が必要になったりしてダメだと思います。
about:config的な奴で止められるよ!では要求スキルが高すぎてダメです。
LibreOfficeチームは、我が子可愛さにデフォルト有効を止められない、変な親心でも持ってるんだろうか。
セキュリティホールはセキュリティホールなんだから、ちゃんと解決するまでLibreLogoを削除するとか、
文書を開いた後、毎回明示的に有効化しない限り使用できない位の対策を取っても良いと思うのだけど。
Re: (スコア:0)
長いことLibreOffice使ってるけどインストール時の設定は最初にカスタム設定したのを引き継いでいたから「インストーラに含まれているけど標準設定ではインストールされないコンポーネント」だと思ってたわ
微妙だな (スコア:0)
そもそも、LibreLogoの実行でPythonの生スクリプトが動くのがいかんのだよね?
LibreLogoの言語仕様がいまいちわからんのだが、ドキュメント外に影響を及ぼすものでは無いのだろう。
であればLibreOfficeの「マクロ」レベルのスクリプト制御は不要としてもいい。
「Logoプログラムの実行」をクリックしないと実行できないのなら、想定外の起動の懸念要素はほぼ無いだろう。
しかし…そんなバグ入るかというか、直さ/せないもんなのかってのがどうもわからん。
Re:微妙だな (スコア:1)
そう、その通り。
LibreLogoがPythonで実装されているからなのか、任意のPythonスクリプトが動いてしまうのが問題。
Logoが任意のPythonスクリプトが動作するという言語しようなら仕方ないかもしれない。
でも、だったらVBAマクロのように毎回許可を求めたりするコントロール機能は必要になる。
でも、現時点ではそんな機能は無い。
しかも、不味い事にLibreLogoは隠し文字(display:none的なもの)も普通に実行する。
つまり、無害なLogoスクリプトを表示し、悪意あるPythonスクリプトを隠し文字にしたODF文書を配布してしまえば良い。
そうすれば、ターゲットは、無害なLogoスクリプトを実行したつもりで、悪意あるスクリプトも実行してくれる。
といった、かなりヤバイ状況なのに、呑気にLibreLogoの穴をそのままにしてる訳です。
実は既に悪用されてるかもね。
Re: (スコア:0)
LibreLogoがどれくらい古くからあるのか知らんけど、昔のファイルフォーマットはセキュリティ何それおいしいのみたいな感じで平然と任意の外部コマンド実行ができたりすることがあるので(Windows HelpとかPDFとか)「ドキュメント外に影響を及ぼすものでは無い」とかんたんに言い切れないのかもしれない