アカウント名:
パスワード:
最近怖くてオープンソースの物使いにくいマイナーなものは特に
しかも最近はビルド時勝手にオンラインで引っ張ってくるという凶悪さ
酷いとHTTPの平文でな。
平文で何が悪いって感じがする。
オプソかプロプラかを問わず、インストールしようとした時に自動的に「ソフトの依存するソフトの依存するソフトの…の依存するソフトを自動的にインストール」となって関係者の数が増えすぎる(==ポンコツ開発者が混じってる可能性が高まる)のが怖いんだよね
オンライン上のインストール用のシェルスクリプトのファイルをsudoで直で実行してインストール、という方法も頭おかしいと思うんだけど、結構使われてるよね・・・
ダウンロードしてsudoなり管理者権限のパッケージマネージャでインストールなりでもリスクは大差ないよ。あえて気にするならHTTPSかHTTPかを気にすべき。
supply chain attackを考えればOSSに限ったことではないです。
例えば最近ではASUSやCCleaner等の更新がマルウェア内蔵に置き換えられています。https://www.pandasecurity.com/mediacenter/mobile-news/supply-chain-asus/ [pandasecurity.com]
Chromeの機能拡張が買収された後にadwareを仕込まれた話等も枚挙に暇がありません。OSSだけが危険だというのは危険な考えです。
>最近はほとんど活動していなかったことからパスワードの安全性にも注意を払っていなかった
塩漬けアカウント的なのは、仕事じゃないから発生するでしょうなぁ…一定期間後にアカウント無効化かなぁ…
オープンソースと何も関係ない件Google Playに偽物アプリが公開されるのと何が違うの
Chrome拡張でもちらほら起きてるけどこういう悪さする連中防ぐのどうしたらいいんだろう
gemに署名付ける仕組みはあるみたいだけど今回のパッケージは署名付いてたのかな？アカウントハックされたぐらいだから，検証に使用する証明書も差し替えられちゃう感じ？
プログラミング系の独自パッケージ配布システムは，性善説により過ぎてるような気がする．第三者のレビューを通過して初めてpublishできるようなリポジトリがあっても良いかも．
いくつか対策もストーリー本文に書かれているけど、まずアカウントを乗っ取られやすい認証システムを見直す必要がある気がする。
パスワードを使い回すユーザーが出現するという脆弱性を修正できないか。
そろそろ「パスワードをユーザに決めさせてはいけない」というのが浸透して欲しい。
紛失した場合の回復手段を悪用されるだけなので無駄
Chromeに記憶させておけば紛失はしないでしょ
いやGoogleアカウントが消されたとかログイン出来なくなったとかだとアレだが
セブンペイの初期考察のような話だろ。紛失するかどうかしたかどうかは関係ない。
> Chromeに記憶させておけば紛失はしないでしょ
マシンが故障して、バックアップもなかったら紛失するよ。まあ RubyGem デベロッパーならバックアップくらいは期待してもいいかもしれないけど一般論としてはまったく期待できない。
パスワードが必要なら、それはサービス側で自動生成してユーザーに渡した方がいいってのは同感だけど、それがユーザーに受け入れられるかは不安がある。
いつものメアド使ったやつでええやん？
ソルトのように、ユーザー決定部分の他にサイト決定部分の連結文字列にすれば良いんだよね。
サイト決定部分がユーザーごとに別で、推測が難しいならいいけど、それだったら、パスワード全体をサイトが決めてもよくね？
サイト側で決めるんなら入力も面倒だし証明書認証でよくね？
# そして証明書が漏洩して振り出しに戻る
覚えられない→メモに書いておく→メモが流出というリスク。メモっとく部分（サイト毎に違う）＋覚えとく部分（全サイト同じ）にすれば良いか。
実際のところ、メモが流出して大事故になった例がどれほどあるというのか。昨今の流出事故を顧みると、もはやユーザーが自分でパスワードを設定できるといこと自体がセキュリティーホール。
オンラインのパスワード管理システムだとそれ自身が狙われるのでイケてないこともあるけど、ローカルのプレーンテキストだとマルウェア踏んだ状況ですら、機械的に盗まれる可能性はそこまで高くなさそうだしね。もうその時点でロガーとか仕込まれる方が現実的リスクになる。攻撃可能なのは物理アクセス可能な相手が主体で、ストレージ暗号化してマメにロックしてればショルダーハック警戒すれば事足りる。
ただ、事例ベースで話をするとパスをメモる時点で論外扱いされて、それによる副次被害が余程大きくないと話題にならず認知されないことも多い。
そろそろVirusTotalみたいにhttps://haveibeenpwned.com/とかGoogleが買い上げて、パスワード使いまわしさせないシステムとか作ってもいいと思うの。
ユーザーがパスワードを自分で決めれないようにすれば良いだけで、そんなものは不要だよ。
それができないからでしょ？
now.sh のようにパスワードなしでメールのみで認証しているサービスもありますね。
https://japan.zdnet.com/article/35141553/ [zdnet.com]> この攻撃を実行した人物は、1カ月以上前から活動していたが、その活動は発見されずにいた。
この人何を言っているのだろうか・・・
個別パッケージ vs 大型プロダクト内の1機能だとだいぶ違うし削除 vs 機能を維持しての修正も大分ちがうのに
# MSでも緊急リリースのときは1weekくらいででた実績はあること# こういうのは実際的な危険性の評価によると思うのだが、なに言ってるんだろう...
https://rubygems.org/gems/rest-client/versions [rubygems.org]
1.6.14 - August 21, 2019 (114KB)1.6.13 - August 14, 2019 (114KB) yanked1.6.12 - August 14, 2019 (113KB) yanked1.6.11 - August 14, 2019 (113KB) yanked1.6.10 - August 13, 2019 (11.5KB) yanked1.6.9 - June 10, 2015 (113KB)
8/13、8/14に悪意あるコードを含むリリースが行われてから、8/21に修正されるまで1週間もかかっている。旧バー
脆弱性とマルウェアを一緒に論じてどうする修正とテストが必要な脆弱性と、見つかればもとに戻すだけのマルウェアでは必要な時間が圧倒的に違うだろうに。
あからさまなマッチポンプだな
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
オープンソースはこういうとこに弱いよね (スコア:0, 興味深い)
最近怖くてオープンソースの物使いにくい
マイナーなものは特に
Re:オープンソースはこういうとこに弱いよね (スコア:4, すばらしい洞察)
しかも最近はビルド時勝手にオンラインで引っ張ってくるという凶悪さ
Re:オープンソースはこういうとこに弱いよね (スコア:1)
酷いとHTTPの平文でな。
Re:いや割と真剣に (スコア:0)
平文で何が悪いって感じがする。
Re: (スコア:0)
オプソかプロプラかを問わず、インストールしようとした時に自動的に「ソフトの依存するソフトの依存するソフトの…の依存するソフトを自動的にインストール」となって関係者の数が増えすぎる(==ポンコツ開発者が混じってる可能性が高まる)のが怖いんだよね
Re: (スコア:0)
オンライン上のインストール用のシェルスクリプトのファイルをsudoで直で実行してインストール、という方法も頭おかしいと思うんだけど、
結構使われてるよね・・・
Re: (スコア:0)
ダウンロードしてsudoなり管理者権限のパッケージマネージャでインストールなりでもリスクは大差ないよ。
あえて気にするならHTTPSかHTTPかを気にすべき。
オープンソースに限らない (スコア:1)
supply chain attackを考えればOSSに限ったことではないです。
例えば最近ではASUSやCCleaner等の更新がマルウェア内蔵に置き換えられています。
https://www.pandasecurity.com/mediacenter/mobile-news/supply-chain-asus/ [pandasecurity.com]
Chromeの機能拡張が買収された後にadwareを仕込まれた話等も枚挙に暇がありません。
OSSだけが危険だというのは危険な考えです。
Re: (スコア:0)
>最近はほとんど活動していなかったことからパスワードの安全性にも注意を払っていなかった
塩漬けアカウント的なのは、仕事じゃないから発生するでしょうなぁ…
一定期間後にアカウント無効化かなぁ…
Re: (スコア:0)
オープンソースと何も関係ない件
Google Playに偽物アプリが公開されるのと何が違うの
cpanとかの類 (スコア:0)
Chrome拡張でもちらほら起きてるけど
こういう悪さする連中防ぐのどうしたらいいんだろう
Re: (スコア:0)
gemに署名付ける仕組みはあるみたいだけど今回のパッケージは署名付いてたのかな？
アカウントハックされたぐらいだから，検証に使用する証明書も差し替えられちゃう感じ？
プログラミング系の独自パッケージ配布システムは，性善説により過ぎてるような気がする．
第三者のレビューを通過して初めてpublishできるようなリポジトリがあっても良いかも．
Re: (スコア:0)
いくつか対策もストーリー本文に書かれているけど、
まずアカウントを乗っ取られやすい認証システムを見直す必要がある気がする。
パスワードを使い回すユーザーが出現するという脆弱性を修正できないか。
パスワードの運用ルール (スコア:0)
そろそろ「パスワードをユーザに決めさせてはいけない」というのが浸透して欲しい。
Re: (スコア:0)
紛失した場合の回復手段を悪用されるだけなので無駄
Re: (スコア:0)
Chromeに記憶させておけば紛失はしないでしょ
いやGoogleアカウントが消されたとかログイン出来なくなったとかだとアレだが
Re: (スコア:0)
セブンペイの初期考察のような話だろ。
紛失するかどうかしたかどうかは関係ない。
Re: (スコア:0)
> Chromeに記憶させておけば紛失はしないでしょ
マシンが故障して、バックアップもなかったら紛失するよ。
まあ RubyGem デベロッパーならバックアップくらいは期待してもいいかもしれないけど
一般論としてはまったく期待できない。
パスワードが必要なら、それはサービス側で自動生成してユーザーに渡した方がいいってのは同感だけど、
それがユーザーに受け入れられるかは不安がある。
Re: (スコア:0)
いつものメアド使ったやつでええやん？
Re: (スコア:0)
ソルトのように、ユーザー決定部分の他にサイト決定部分の連結文字列にすれば良いんだよね。
Re: (スコア:0)
サイト決定部分がユーザーごとに別で、推測が難しいならいいけど、それだったら、パスワード全体をサイトが決めてもよくね？
Re: (スコア:0)
サイト側で決めるんなら入力も面倒だし証明書認証でよくね？
# そして証明書が漏洩して振り出しに戻る
Re: (スコア:0)
覚えられない→メモに書いておく→メモが流出というリスク。
メモっとく部分（サイト毎に違う）＋覚えとく部分（全サイト同じ）にすれば良いか。
Re: (スコア:0)
実際のところ、メモが流出して大事故になった例がどれほどあるというのか。
昨今の流出事故を顧みると、もはやユーザーが自分でパスワードを設定できるといこと自体がセキュリティーホール。
Re: (スコア:0)
オンラインのパスワード管理システムだとそれ自身が狙われるのでイケてないこともあるけど、
ローカルのプレーンテキストだとマルウェア踏んだ状況ですら、
機械的に盗まれる可能性はそこまで高くなさそうだしね。
もうその時点でロガーとか仕込まれる方が現実的リスクになる。
攻撃可能なのは物理アクセス可能な相手が主体で、
ストレージ暗号化してマメにロックしてればショルダーハック警戒すれば事足りる。
ただ、事例ベースで話をするとパスをメモる時点で論外扱いされて、
それによる副次被害が余程大きくないと話題にならず認知されないことも多い。
Re: (スコア:0)
そろそろVirusTotalみたいにhttps://haveibeenpwned.com/とかGoogleが買い上げて、パスワード使いまわしさせないシステムとか作ってもいいと思うの。
Re: (スコア:0)
ユーザーがパスワードを自分で決めれないようにすれば良いだけで、そんなものは不要だよ。
Re: (スコア:0)
それができないからでしょ？
Re: (スコア:0)
now.sh のようにパスワードなしでメールのみで認証しているサービスもありますね。
Re:はやすぎ (スコア:1)
https://japan.zdnet.com/article/35141553/ [zdnet.com]
> この攻撃を実行した人物は、1カ月以上前から活動していたが、その活動は発見されずにいた。
Re: (スコア:0)
この人何を言っているのだろうか・・・
Re: (スコア:0)
個別パッケージ vs 大型プロダクト内の1機能だとだいぶ違うし
削除 vs 機能を維持しての修正も大分ちがうのに
# MSでも緊急リリースのときは1weekくらいででた実績はあること
# こういうのは実際的な危険性の評価によると思うのだが、なに言ってるんだろう...
Re: (スコア:0)
https://rubygems.org/gems/rest-client/versions [rubygems.org]
1.6.14 - August 21, 2019 (114KB)
1.6.13 - August 14, 2019 (114KB) yanked
1.6.12 - August 14, 2019 (113KB) yanked
1.6.11 - August 14, 2019 (113KB) yanked
1.6.10 - August 13, 2019 (11.5KB) yanked
1.6.9 - June 10, 2015 (113KB)
8/13、8/14に悪意あるコードを含むリリースが行われてから、8/21に修正されるまで1週間もかかっている。旧バー
Re: (スコア:0)
脆弱性とマルウェアを一緒に論じてどうする
修正とテストが必要な脆弱性と、見つかればもとに戻すだけのマルウェアでは必要な時間が圧倒的に違うだろうに。
Re: (スコア:0)
あからさまなマッチポンプだな