ChromeとNVIDIAのドライバで不具合、閲覧していたサイトがゲームのロード画面に表示されてしまうバグ 59
ストーリー by hylom
興味深い 部門より
興味深い 部門より
あるAnonymous Coward 曰く、
トロント大学の学生Evan Andersen氏によると、Google Chromeのシークレットモードでアダルトサイトを見ていても、NVIDIAのドライバのバグが原因でバレてしまうことがあるそうだ。同氏によると、アダルトサイトを見た後にPC向けの人気ゲーム「Diablo III」を起動したところ、ロード画面に直前に見ていたサイトのスナップショットが表示されたそうだ。原因はNVIDIAのドライバとChromeの両方にあるという（SOFTPEDIA、charliehorse55、NETWORKWORLD、Slashdot）。
GPUは開いてるアプリケーションにメモリを割り当てる。アプリケーションを終了すると空いたメモリはGPUの共有メモリプールに再追加され、別のアプリケーションで使用できるようになる。このときChromeはメモリバッファを削除しておらず、NVIDIAのGPUドライバも割り当てられたメモリをクリアしていなかった。このため前述の現象が起きたという。
Evan Andersen氏は2年前にもNVIDIAとGoogleにこの問題を指摘していたが、修正はできなかったとしている。
仮想環境からホストの情報を盗むのにも使える (スコア:5, 参考になる)
GPUのVRAMの情報リークは割と有名な問題でして、例えば、VirtualBoxの中の仮想環境から、ホスト環境の情報を盗みとるために使われています。
The Palinopsia Bug
https://hsmr.cc/palinopsia/ [hsmr.cc]
Macだけでなく、LinuxやWindowsでも、この脆弱性を使うことができます。
INFORMATION DISCLOSURE VULNERABILITY IN VRAM
http://www.websecuritywatch.com/information-disclosure-vulnerability-i... [websecuritywatch.com]
>During testing, the following 4 cards proved to be susceptible to this
method:
>1. Linux using the open source radeon driver for AMD/ATI cards
>2. Linux usig the open source nouveau-driver for nVidia-cards
>3. Linux using the closed source nVidia-driver
>4. Windows using the closed source AMD/ATI catalyst driver
簡単に再現できる実証コードもあります。
> The Code available here:
> https://hsmr.cc/palinopsia/main.cpp [hsmr.cc]
> uses the SDL2 library.
こちらの環境でも、再現できました。
Chrome (スコア:3, おもしろおかしい)
ユーザーの情報を収集、共有するウェブサイト
ユーザーがアクセスしたページをトラッキングするインターネット サービス プロバイダや雇用主
無料ダウンロードなどと一緒にインストールされ、キーストロークを記録する不正ソフトウェア
スパイ、諜報活動
背後にいる人
NVIDIA
これで解決
Re: (スコア:0)
何言ってんだコイツ……？
というか、記事の題読んでるか？
脳内で、どう諜報活動と結び付いたんだ？
Re:Chrome (スコア:1)
「シークレットモード chrome 注意書き」などで画像検索してください。
Re: (スコア:0)
NVIDIAだけではなく、後から開いた任意のアプリが未初期化の領域を参照することによってシークレットモードの画面を読み出せてまいますよね。
それを記事から読みとれていないから的外れなジョークになってて、なにいってんだコイツ…となるわけです。
Re: (スコア:0)
chrome使ってるならわかるジョークじゃないのか？
シークレットモード開くと出てくる注意だろ････
Re: (スコア:0)
???
iOSのSafariでも (スコア:3)
iOSのSafariでも以前見たサイトが一瞬ですが表示されることがありますね。
個人情報が漏れる可能性がありセキュリティ上問題とされていますが、iOS7のころから報告は上がっているのに、いまだ改善されませんね。
ただの初期化バグ (スコア:0)
としか思えないが、修正するのがそんなに難しいのだろうか？
Re:ただの初期化バグ (スコア:2, 参考になる)
「うちはちゃんと初期化してる。Appleが悪い。Windowsでは発生しないし」とNvidia
http://venturebeat.com/2016/01/13/nvidia-blames-apple-for-bug-that-exp... [venturebeat.com]
記事中の追記によると、RedditにはAMDのグラフィックカードでも発生するって報告もあるのだそう
Re: (スコア:0)
なんだよ、Macだけかよ
つーか、なんでタレこみにはMacと書いてないんだよ
Re:ただの初期化バグ (スコア:2)
難しい場合も有る。
VRAM的な場所に書込む関数を呼んでも、元のVRAM的な場所の領域を書換えるとは限らないわけで。
例えば、システムメモリにキャッシュしていたり、別のVRAM的な場所の領域に書込んで暇な時にすり替えたりなんていう実装をしているかもしらない。
Re: (スコア:0)
単純にGoogleが修正を拒否している (スコア:2, 参考になる)
Softpediaの元記事 [softpedia.com]とタレコミではかなりニュアンスが変わっていて、元記事でははっきりとGoogleを批判している。
Mr. Andersen submitted bugs to both these companies two years ago, and both failed to fix the issue. Even worse, as Mr. Andersen explains, Google marked his bug report as a "won't fix" because "Google Chrome Incognito Mode is apparently not designed to protect you against other users on the same computer."
If true, this explanation comes in direct opposition to how Google currently describes Incognito Mode, a feature introduced to "browse the Internet in private without Chrome saving the sites you visit."
"This is a serious problem. It breaks the operating system’s user boundaries by allowing non-root users to spy on each other," Mr. Andersen explained. "It doesn’t need to be specifically exploited to harm users - it can happen purely by accident."
雑に要約すると、「Googleは不可解な理由で修正を拒否しているが、まったく理解しがたいことだ」って書いてある。
それが、なぜかタレコミではGoogle批判のニュアンスが書き換えられ、その結果として、議論は分散してGoogleへの批判は目立たなくなっている。
この種の不思議なGoogleびいきはすらどのタレコミでは実は頻繁に発生しているので、ちょっと注意してみるとよろし。
failの誤訳ですかね (スコア:1)
元のブログ記事の「Mr. Andersen submitted bugs to both these companies two years ago, and both failed to fix the issue.」という文章に対して、
タレコミでは「Evan Andersen氏は2年前にもNVIDIAとGoogleにこの問題を指摘していたが、修正はできなかったとしている。」と訳していますが、
英語の「fail」には「失敗する」という意味のほかに、「（「すべきこと」を目的語にとって）～しない」という意味もあって、
後に続く文章でGoogleが修正しないという意思決定を行っていることが書いてあるので、後者の意味が適切であることがわかります。
（辞書には「He often fails to keep his word」（彼は約束を守らないことがよくある）の例文が上がっています）
「Andersen氏は2年前にNVIDIAとGoogleにこのバグを報告したが、両社とも未だに修正していない。さらに悪いことに、Googleは彼のバグ報告を「won't fix」に分類している。」
意識的なGoogleびいきかどうかわかりませんが、この誤訳に加えて、ブログ記事の三分の一を占めるGoogleへの批判を全削除しているために、
あたかもNVIDIAやGoogleでは修正が困難な不具合であるかのように議論が誘導されている結果になっていることは否めませんね。
Re: (スコア:0)
まぁ、Appleですし。
というのは冗談として、デスクトップ描画の辺りにバグが有って修正したら遅くなるか、動かなくなるプログラムとかいっぱいあるので検証に時間が掛かっています。
といった辺りですか。
ボスが来た (スコア:0)
USB接続のスイッチもあるのね
Diablo IIIは？ (スコア:0)
これ、一番問題なのはDiablo IIIなのでは？
確保したメモリをクリアせずに使っているってことですよね？
ドライバ（か、あるいはDirect3D？）は解放されたメモリをクリアしておくべきだし、
Chromeみたいなセンシティブな情報を扱うアプリはメモリ解放前にクリアしたほうがいいのは確か。
でも、Diablo IIIが使用前にメモリをクリアしないのはバグだよね。
Re: (スコア:0)
みんながみんな何べんも同じことをするってのも非効率極まりない
OSだろうがドライバだろうがライブラリだろうが、外部のソフトウェアの挙動なんて、ほぼ信頼のみで
成り立ってる部分だから疑いだしたらキリがないし、そんな高コストな考え方が正解だとも思えない
Re: (スコア:0)
いちばん問題なのは情報を漏らしてるChromeのほうなのでは？
シークレットモードとかいっててそれじゃ話にならない。
なんでそこでDiabloが責められるのか意味不明。
Re:Diablo IIIは？ (スコア:1)
だよね。
原因がOSかドライバかゲームにあったにせよ、セキュリティだとか進行不能でないちょっとした表示の乱れ程度の優先度低そうなバグの話で、
絶対的に優先度高いのは情報漏えい側だよね。
今やコピー機だって使用後はメモリ消去するというのに
Re: (スコア:0)
漏れてはいけない絶対領域。。。
記憶に焼き付くのも致し方なし
Re: (スコア:0)
もしかすると、ドライバに返却しないでOS(Windowsで言うDWMとか)が色々な所で使いまわしている可能性もあるかと。
その場合、アプリ側やドライバ側では対処しようがない。
Re: (スコア:0)
メモリクリアは高コストなのでGPUドライバが一々消さないのは当然。
Chromeはシークレットモード時にはちゃんと消すべきだとは思うが、
不正終了とかも考えると保証できないのであてにすべきではない。
ディアブロがフレームバッファをクリアしないのがタコなのには同意。
だが、Chromeのシークレットモードの都合までは知ったこっちゃないよね。
結局ユーザーがシークレットモードを過信せず自衛するしかないのでは。
Re: (スコア:0)
Chromeの終了の時点でカーネル(OSとドライバ)が使用メモリをゼロクリアするべきですよ。
一般的なメモリでは、当然そうなってます。VRAMがどうなってるかまでは知りません。
Re: (スコア:0)
一般的なメモリでは、当然そうなってます。
あなたの書くプログラムでは確保したメモリや変数領域はOSが初期化してくれるのを前提としてるわけですね？
どこの世界の「一般的」なのか後学の為に教えて下さい。
Re:Diablo IIIは？ (スコア:1)
例えば、Windowsでの物理メモリ管理の説明が、PDC10: Mysteries of Windows Memory Management Revealed: Part Two [msdn.com]にあります。
開放されたページはFree Page Listに繋がれて、暇な時やページが必要な時にZero Page ThreadがゼロクリアしてZero Page Listに繋ぎ、再度必要になるとZero Page Listから取ってプロセスに渡されます。
Re: (スコア:0)
「Chromeの終了の時点で」は「Diablo IIIがメモリ確保する時点で」の間違いでした。初期化されるというソースは以下に。
http://www.atmarkit.co.jp/flinux/rensai/watch2009/watch11b.html [atmarkit.co.jp]
>mmap()やbrk()などのメモリ確保システムコールには、manページに書かれていない重要なお約束があります。
>それは「確保されたページはゼロ初期化してからユーザー空間に返さないといけない」ということです。
>カーネルは、自分が使わないページにどんなゴミが入っていても気にしないし、ユーザー空間アプリもmalloc()の戻りアドレスがゼロ初期化されていることなん
Re: (スコア:0)
「OSがちゃんとクリアしておくのが当然で、そうしておけば情報流出は防げた」
「（確保したメモリが初期化されているという）仕様外の動作を前提にプログラムを書くのか？」
これ、かみ合ってるようで全然かみ合ってない話だよねー。
Re: (スコア:0)
> この関数によって割り当てられたメモリは、0 に初期化されます。
ちゃんと仕様内の動作やないけ…
Re: (スコア:0)
malloc(3) と勘違いしてない？
brk(2), sbrk(2) でメモリを増やす方に確保したら、その領域は 0 で埋まっていることが保証されている。これ [opengroup.org] の 92ページ目(p.64) の Description をみたら良い。
malloc には mmap(2) を使う実装もあるが、これに渡す file descriptor は、普通 /dev/zero をopen したものを渡す、つまり、最初に使うメモリは 0 で埋められている。
ただし、malloc は一度 OS から確保したメモリを(free(3) されたら)再利用する場合もあるから、その場合は 0 で埋められているとは限らない。
Re: (スコア:0)
さすがに汎用機でも、OSから渡されたメモリーは初期化されてたと思う。
プロセス内で使いまわされる領域の話とはまた別ですよ。
Re: (スコア:0)
そのVRAMの問題なのに…。
セキュアなデータを解放前に消去するのは常識でしょ。
Re: (スコア:0)
バグに関しては、クリアするしないにしろ、仕様書よんでない言い訳ではないのか？
どっちの仕様が妥当かは、ＯＳやドライバーが
クリアしない派は、メモリクリアコストって書いてるけど
クリアすべき派は、「当然」なので理由が書いていませんが
無知な私に、具体的に教えて頂けませんか？
Re:Diablo IIIは？ (スコア:1)
＞クリアすべき派は、「当然」なので理由が書いていませんが
簡単に結論を書けば、「当然ではない」ということになるかと思います。
あと、ページ単位でのメモリ確保と、ヒープメモリの確保、そしてVRAMの確保では、それぞれ意味が異なり「どうすべきか」も異なってきます。
更に、OSのポリシーによっても変わりうることですから（規格として決まっている部分については別）、それらを一緒くたに語っている時点で間違えているわけです。
付け加えると、VRAMのメモリクリアは、システムメモリ（メインメモリ）のメモリクリアとはコストが異なります。
（例えば、GPUパイプラインを停止させてしまうかもしれません。VRAM確保のたびにコレが発生すると極端なパフォーマンス低下の可能性があります）
ですから、セキュアな処理を必要とするアプリのみでアプリ側が解放前に削除する、というのが現時点では現実解ではないかと個人的には思います。
Re:Diablo IIIは？ (スコア:1)
前者はマルチタスクＯＳに一般的な保護機能。後者はセキュアに関することですから。
当然、ＶＲＡＭがあるプロセスに使用されている間は（プライマリサーフェスが画面キャプチャされるなどの例外を除いて）、他のプロセスは見ることができません。
それは保護されています。
使い終えたメモリに残ったごみをどうするかはマルチタスクとは関係のない、セキュアＯＳとしてのポリシーの問題です。
全ての情報が漏えいしてはならないわけはなく、（特に低スペックなマシンの場合）すべてのＶＲＡＭをクリアするべきかどうかは別の問題となります。
Re: (スコア:0)
こういう奴が出力専用引数に渡すメモリをmemsetするアホなコード書いてんだろうな
Re: (スコア:0)
Chromeがシークレットモードといいつつメモリクリアしてなくてメモリ上に情報を残しているのが問題で、
これがDiabloじゃなくて例えばメモリ上に残っている画像を記録するスパイウェアだったらどうするんだってことですよ。
Re: (スコア:0)
ディアボロってスパイウェアだったんです？
Re: (スコア:0)
下で言われてますが、
・ゲームやブラウザでなくNVidiaのドライバの問題であるらしい。
・しかしNVidia曰く、「Windowsでは起きてねえよAppleに言え」
Re: (スコア:0)
これ、
結局（つか多分）chromeもnvividiaも悪くなく、アップルだけ（OSX）のバグだけって事？
chromeがメモリクリア処理発行 → OSXがメモリクリアさぼる → GPUドライバがメモリクリア発行→OSXがさぼる→消した画面が表示される
って話じゃないのか？
Re: (スコア:0)
ドライバ側でクリアするための処理を書いても、MacOS では高速化のためか、その処理をサボッてるのが原因らしい。
まぁ MacOSを 使える程度の用途であれば、その程度の問題は許容範囲だろう。
Re: (スコア:0)
Windowsがメインメモリをアプリに渡すときはゼロクリアだかをやってから渡しているんだっけ？
ビデオメモリも同じ感覚で使っていたんじゃないかな
うちでも発生してる (スコア:0)
MacMini Mid2010 (GeForce320M) + OSX 10.10.5 で同じ現象が発生してる。
ただ、うちの場合は最近になって起きるようになった。
具体的にはシステム環境設定の「アクセシビリティ」→「ディスプレイ」の「透明度を下げる」をOnにしてから。
この設定変更で少し動きが軽くなったけど、VRAMのクリアも端折っているんだろうか？
chromeと聞いてS3を思い出す (スコア:0)
＞ChromeとNVIDIAのドライバ
S3のChrome 9 HCかなんかだとふと思ってしまったよ
今更何という話だし、もはやchromeといえばGoogleなんだけどね
＞NVIDIAのドライバとChrome
本文後半のこの書き方なら間違えることもないが、ひととき懐かしさに浸らせてもらいました。
Re:chromeと聞いてS3を思い出す (スコア:2)
あまり関係無い上に詳しくは知らないけど、S3のMeTaLとAppleのMetalを思い出し。
Firefoxでも稀によくある (スコア:0)
HW支援とOMTC有効の状態では
タブ切り替えで前のタブの描画が残ったりとか
GPU活用についてはどこもまだまだ手探り感が否めないんでしょうね
毎度恒例の二重基準 (スコア:0)
OSXの場合→OSが割り当てるメモリがゼロクリアされている事を前提にしてるアプリが悪い
Windowsの場合→メモリをアプリに渡す前にゼロクリアしないM$が悪い
Re: (スコア:0)
あるいはC言語全盛の頃の話とか。
UNIXに対しては開発者視点に、Windowsに対してはユーザ視点になる人も多いように思う。
MSX (スコア:0)
MSXでゲーム画面をキャプチャするために本体の電源をブチっと切ってからOSを起動し
VRAMに残ってるデータを保存していたのを思い出しました。
時間がたつとちょっとずつ画像が崩れていく……