パスワードを忘れた? アカウント作成

アカウントを作成して、スラドのモデレーションと日記の輪に参加しよう。

13647502 story
Chrome

デスクトップ版Chrome 67、Spectreなどの対策としてSite Isolationが有効に 19

ストーリー by headless
対策 部門より
デスクトップ版のChrome 67ではSpectre/Meltdownなどの脆弱性を狙う投機的実行のサイドチャネル攻撃を緩和するため、すべてのサイトを別プロセスで読み込む「Site Isolation」が有効になっているそうだ(Google Security Blogの記事Ars Technicaの記事The Registerの記事BetaNewsの記事)。

Chromeでは以前からタブごとに別のプロセスを使用しているが、タブ内のiframeやポップアップで別のサイトが読み込まれる場合はメインタブと同一プロセスが使われていたという。通常は同一オリジンポリシーによりクロスサイトiframeやポップアップの内容にメインドキュメントからアクセスすることはできないが、何らかの脆弱性を狙われた場合にはSpectreに限らず、Site Isolationが有効な緩和策となる。また、Webページがサブリソースとして読み込もうとするクロスサイトのHTML/XML/JSONレスポンスをブロックするCross-Origin Read Blocking(CORB)も含まれる。なお、同一ドメインのサブドメインについては同一サイト扱いになるとのこと。

Site IsolationはChrome 63 で実験的な企業向けのポリシーとして実装されており、多くの問題が解決されたことから、デスクトップ版Chromeの全ユーザーで有効にできるレベルに達したという。ただし、現時点で有効になっているのは99%のユーザーで、1%はパフォーマンス改善などのため無効のままにしているそうだ。プロセス増加により、メモリー使用量は10~13%程度の増加が見込まれる。

Site Isolationの動作はhttp://csreis.github.io/tests/cross-site-iframe.htmlを開いて「Go cross-site (complex page)」をクリックし、Chromeのメニューから「その他のツール→タスクマネージャ」を選んでタスクマネージャを起動すれば確かめられる。有効になっていればiframeに読み込まれたサイトが「サブフレーム」として表示されるはずだ。
13634966 story
セキュリティ

AvastやAVGを利用している環境でFirefoxがTLS 1.3を利用できなくなるトラブル 41

ストーリー by hylom
またAvastか 部門より

セキュリティソフトを導入しているとFirefoxからGoogleのサービスへのアクセスができなくなる、といった問題が報告されている(ghacks.net)。

問題となっているのはAvastおよびAVGのセキュリティソフト。これらのセキュリティソフトを導入した環境でFirefoxでTLS 1.3を利用しようとすると問題が発生するようだ(MozillaのBugzillaAvastのフォーラム)。

また、ChromeでもAvastを利用している環境でTLS 1.3接続関連のトラブルが発生することがあるようだ(The Chromium Projectsでの報告)。

13623613 story
Chrome

Google、Chrome拡張のインラインインストール廃止へ 16

ストーリー by headless
廃止 部門より
Googleは12日、Chrome拡張のインラインインストール機能を廃止する計画を発表した(Chromium Blogの記事Neowinの記事The Vergeの記事Softpediaの記事)。

インラインインストールを利用すると、Chromeウェブストアでホストされている拡張機能を作者のWebサイトなどから直接インストール可能になる。以前は任意のWebサイトでホストする拡張機能をインストールできていたが、不正な拡張機能が問題になったことから Googleはインラインインストールへの移行を推奨。2014年5月にはChromeウェブストア以外でホストされる拡張機能のブロックを開始していた。

さらに2015年にはユーザーをだますような説明で誘導する拡張機能のインラインインストールを無効化しているが、その後も同様の手法が後を絶たなかったようだ。Googleでは望まない拡張機能に関する大量の苦情を受けており、大半を不正なインラインインストールが占めているという。一方、Chromeウェブストアからインストールされた拡張機能は苦情が大幅に少ないとのこと。

インラインインストール廃止は3段階で進められる。まず、6月12日以降に新規公開された拡張機能では既にインラインインストールが無効化されており、chrome.webstore.install()メソッドを呼び出そうとすると自動でChromeウェブストアにリダイレクトされるようになっている。9月12日以降は既存の拡張機能でもインラインインストールが無効となり、Chromeウェブストアへのリダイレクトが行われる。12月初めに安定版リリース予定のChrome 71では、インラインインストール用のAPIメソッドが削除されるとのことだ。

インラインインストールを利用している拡張機能開発者に対しては、Chrome 71安定版リリースより前にWebサイトのインストールボタンをChromeウェブストアへのリンクに変更するよう求めている。
13612740 story
インターネット

CSSの機能を使用してクロスオリジンのiframeから表示内容を読み取るサイドチャネル攻撃 11

ストーリー by headless
攻撃 部門より
CSSの「mix-blend-mode」プロパティを使い、クロスオリジンのiframeに表示されている内容を読み取ることが可能なサイドチャネル攻撃について、発見者の一人が解説している(Evonideの記事Ars Technicaの記事SlashGearの記事)。

Webページがクロスオリジンのiframe内のDOM要素にアクセスすることはデフォルトで禁じられているが、iframeに別の要素をオーバーレイし、mix-blend-modeプロパティを使用すると色のブレンドが可能となる。「multiply」のように単純なブレンドモードでは処理時間に違いはみられないが、カラーチャネルを分離せずに処理する「saturation」のようなブレンドモードでは下のレイヤーの色によって処理時間が変動するのだという。

これを利用してピクセル単位でレンダリングを実行させ、処理時間を測定すれば、iframe上のターゲットピクセルの色を識別できる。PoCではFacebookのソーシャルプラグインを埋め込んだ攻撃用ページから、Facebookユーザーの名前やプロフィール写真を読み取っている。ただし、1回のレンダリングでは処理時間の違いを測定できないため、多数のsaturationレイヤーを重ねている。また、別のブレンドモードを指定したレイヤーをiframeとsaturationレイヤーの間に入れることで、特定のカラーチャネルを抽出するなどの処理を事前に行っている。

この脆弱性はGoogle ChromeとMozilla Firefoxで確認され、昨年12月リリースのChrome 63と今年5月リリースのFirefox 60でぞれぞれ修正されている。脆弱性は昨年3月に別の発見者がChromiumメーリングリストで報告していたが、Mozillaには手違いで11月まで報告されていなかったため、修正が遅れたとのこと。なお、Safariは発見時点で既に対策済みだったようで、Microsoft Edge/Internet Explorerではmix-blend-mode自体が実装されていない。
13606172 story
Intel

Spectre/Meltdown脆弱性の新バリアント2件が公表される 10

ストーリー by hylom
続々登場 部門より
headless曰く、

5月21日、多くのモダンCPUに影響する投機的実行のサイドチャネル脆弱性(Spectre/Meltdown)の新バリアント2件が公表された(US-CERT TA-18-141AIntelの発表AMDの発表ARMの発表Project Zero — Issue 1528)。

CVE-2018-3639(Variant 4)はメモリー読み取りの投機的実行により、メモリー上の古いデータが読み取り可能になるというもので、Speculative Store Bypass(SSB)とも呼ばれる。

CVE-2018-3640(Variant 3a)はシステムレジスタ読み取りの投機的実行により、権限のないシステムパラメーター読み取りが可能になるというもので、Rogue System Register Read(RSRE)とも呼ばれる。こちらはMeltdown脆弱性(Variant 3: CVE-2017-5754)のサブバリアント扱いとなっている。AMD製のCPUはMeltdown脆弱性の影響を受けないが、Variant 3aについても影響を受けるものは確認されていないとのことだ。

脆弱性の深刻度は2件とも「Medium」となっているが、MicrosoftによればVariant 4はJavaScriptコードを使用したWebブラウザー上での攻撃も可能だという。ただし、メジャーなWebブラウザーでは既に攻撃を困難にする修正が行われているそうだ。これに対し、Variant 3aでは攻撃者がローカルでログオンして攻撃用プログラムを実行する必要がある。この攻撃の緩和策はマイクロコード/ファームウェアの更新に限られるとのことだ。

13602220 story
Chrome

Chrome 69ではHTTPS接続ページの「保護された通信」という表示が削除される 58

ストーリー by headless
保護 部門より
Googleは17日、9月リリースのChrome 69でHTTPS接続ページの「保護された通信」という表示を削除する計画を明らかにした(Chromium Blogの記事Making HTTP As Non-SecureThe Vergeの記事Ars Technicaの記事)。

ChromeではHTTP接続ページで情報アイコンの右側に「保護されていません」という警告メッセージが表示される場面を徐々に拡大しており、7月リリース予定のChrome 68ではすべてのHTTP接続ページに警告を表示する計画だ。一方、Chromeで閲覧されるHTTPS接続ページの比率が2年前と比べて大幅に増加していることもあり、保護された通信をデフォルト扱いにし、特に表示を行わないことに決めたという。

Chrome 69ではHTTPS接続ページで錠前アイコンのみがグレーで(現在は緑色)表示されるようになり、将来はアイコンも表示されなくなるようだ。この部分には証明書の情報やサイトの設定などを表示する機能が割り当てられているが、これらの機能がどうなるのかについては説明されていない。

また、10月リリースのChrome 70では、HTTP接続ページでユーザーがデータを入力した際に情報アイコンが警告アイコンに変わり、アイコンと「保護されていません」表示が赤色に変化するようになることも同時に発表された。将来はデータ入力の有無にかかわらず、すべてのHTTP接続ページで警告表示にする計画とのことだ。
13601545 story
Chrome

Google、Web Audio API限定で一時的にChrome 66の音声自動再生ポリシーを削除 14

ストーリー by headless
暫定 部門より
Googleは15日、Chrome 66からWeb Audio APIの音声自動再生ポリシーを一時的に削除するアップデートの提供を開始した(Issue 840866The Vergeの記事The Registerの記事Softpediaの記事)。

Chrome 66では音声付きメディアの自動再生が制限されているが、Web Audio APIのAudioContextオブジェクトの扱いが変更されたことでHTML5ゲームなどの音が出なくなる問題が発生していた。今回の変更はWeb Audio APIを使用する開発者がコードを修正する時間をとれるようにするための暫定的なもので、10月リリース予定のChrome 70で再度適用される。 <video>や<audio>を使用するメディアの音声自動再生ポリシーは変更されない。

手元のChromeバージョンは66.0.3359.181。以前音が出なくなっていたHTML5ゲームなどを確認したところ、「chrome://flags/#autoplay-policy」のオプションを変更しなくても音が出るようになっていた。
13580913 story
Google

Google、Pixelbookにマルチブートオプションの追加を計画? 32

ストーリー by headless
追加 部門より
GoogleがPixelbookにマルチブートオプションを追加する計画を進めているのではないかという話が出ている(XDA-Developersの記事Neowinの記事Android Policeの記事Redditのスレッド)。

発端となったのは、Chromium OSの「vboot_reference」プロジェクトに数週間前に出現した「eve-campfire」ブランチ(eveはPixelbookのコードネーム)で、コミットメッセージの「AltOS」「Alt OS」という記述をRedditユーザーが発見したことだ。コミット内容としては、AltOSのブートフロー用フラグの追加と、AltOS選択画面用文字列の追加というものだ。コメントには「go/vboot-windows」という記述もみられる。

Alt OSは「alternative OS」、つまりChrome OSと他のOSをデュアルブートにするオプションではないかと予想されているが、現時点で詳細は不明だ。Redditではコメントの記述からPixelbookでWindowsを実行できるようになることを期待するコメントがある一方、Fuchsia OSは別としてGoogleがWindowsやLinuxのブートを公式にサポートするとは思えないという意見も出ている。そもそもデュアルブート関連という予想がまったく外れている可能性もあるが、スラドの皆さんはどう思われるだろうか。
13580000 story
Android

AndroidのWebView、バージョン66ではSafe Browsingがデフォルト有効に 4

ストーリー by hylom
追跡ブロック 部門より

Googleは17日、危険なWebサイトへのアクセスをブロックするGoogle Safe BrowsingをAndroidのWebViewでデフォルト有効にすることを発表した(Chromium Blog9to5GoogleAndroid Police)。

WebViewはAndroid 5.0以降でGoogle Playを通じたアップデートが提供されており、昨年6月からSafe Browsingは利用可能だが、デフォルトでは無効になっていた。今月リリースのWebView 66ではデフォルトでSafe Browsingが有効になり、WebViewを使用する開発者は特に変更の必要なく保護機能を利用できるようになるとのこと。

WebViewのSafe Browsingは既に、APIドキュメントではデフォルトで有効との記述に変更されている。開発者はベータ版のWebViewを使用してテストURL(chrome://safe-browsing/match?type=malware)にアクセスすれば、アプリでの動作を確認できる。

13576107 story
Firefox

Firefox、HTTP/HTTPSページでのFTPサブリソース読み込みをブロックする計画 21

ストーリー by headless
阻止 部門より
MozillaがFirefox 61を目標に、HTTP/HTTPSページでFTPからのサブリソース読み込みをブロックする計画を進めているそうだ(mozilla.dev.platformのGoogleグループ投稿The Registerの記事Bleeping Computerの記事)。

Google Chromeでは既にFTPサブリソース読み込みをブロックしている。Firefoxでは攻撃者がFTPを使用することでクロスサイト認証(XSA)攻撃(※)の警告表示をバイパスできる問題(バグ1361848)があり、この解決方法としてChromium.orgの議論などから発想を得てBugzillaで提案されたらしい。このバグ以外にも、サブリソースをブロックすることでFTP関連のセキュリティ問題は多くが解決できると考えられるとのこと。

FTPサブリソースのブロッキングはFirefox Nightlyでは既に実装されているようで、サンドボックス化されたiframeを含め、HTTP/HTTPSページのFTPサブリソース読み込みはデフォルトですべてブロックされるという。Chromium.orgの議論ではブロッキングによる問題が発生したという報告が出ていることもあり、ブロッキングの有効/無効を切り替えるプリファレンスも追加されるようだ。

※ クロスサイト認証攻撃はCSRF攻撃の一種。攻撃者はコントロール下のホストにHTTP認証を設定して画像を保存し、Web掲示板などに投稿する。投稿にユーザーがアクセスすると攻撃者のホストのログインフォームが表示され、Web掲示板のものと誤解したユーザーが入力するログイン情報を取得できる。Firefoxではこのようなログインフォームに対し他のサイトからのものだという警告を表示するが、バグ1361848は攻撃にFTPを使用することで警告表示をバイパスできるというものだ。
13559012 story
Chrome

Chrome 66では音声付きメディアの自動再生が制限される 20

ストーリー by headless
制限 部門より
Googleが4月に安定版リリースを予定しているChrome 66では、音声付きメディアの自動再生が制限されるそうだ(Chromium Blogの記事Google Developersの記事The Vergeの記事Mashableの記事)。

音声のないメディアではこれまで通り自動再生が許可される。音声のあるメディアに関しては、1) 同じドメインでユーザーがクリックなどの操作をした 2) デスクトップ版でMedia Engagement Index(MEI)が閾値を超えている 3) モバイル版でユーザーがホーム画面にサイトを追加している、のいずれかに一致すれば自動再生が許可される。

MEIは同じサイト内で 1) メディアを7秒以上再生 2) 音声付きでミュートされていない 3) アクティブなタブ上での動画再生 4) 動画サイズは200×140ピクセル以上、といった条件に一致する再生回数やサイト訪問回数などから算出される。昨年9月のChrome 62 CanaryからMEIの収集が始まっており、「chrome://media-engagement/」で記録を確認できる。

たとえば、動画ニュース記事にWeb検索からアクセスした場合は音声付き動画の自動再生は許可されないが、そのサイトのトップページから記事にアクセスした場合は許可される。また、ユーザーがいつも動画を再生しているストリーミングサイトなどの場合は自動再生が許可されることになる。

なお、Chrome 64以降ではフラグ「chrome://flags/#autoplay-policy」を「Document user activation is required.」にすることで自動再生の制限ポリシーをテストできる。
13524893 story
犯罪

Windows版Google Chromeユーザーを主なターゲットにしたテクニカルサポート詐欺の手法 23

ストーリー by headless
詐欺 部門より
Webブラウザーに偽の警告画面を表示して電話をかけさせるタイプのテクニカルサポート詐欺では、ユーザーの操作を困難にするためのさまざまな手法が用いられるが、Windows版のGoogle Chromeユーザーが主なターゲットとみられる新たな手法による攻撃をMalwarebytesが報告している(Malwarebytes Labsの記事Neowinの記事Ars Technicaの記事SlashGearの記事)。

この手法では、ウイルスに感染したのでISPがPCをブロックしたといった内容の警告とMicrosoftの偽の電話番号を表示するとともに、大量のファイルダウンロードを実行してCPU使用率を100%まで上昇させ、ウインドウやタブを閉じることができないようにする。ダウンロードするファイルは実体があるわけではなく、Blobオブジェクトを生成し、window.navigator.msSaveOrOpenBlobメソッドで保存するというものだ。これを繰り返すことで大量のファイルダウンロードが実行されることになる。
13524880 story
Chrome

Chrome 68ではすべてのHTTP接続ページで安全性に関する警告が表示される 66

ストーリー by headless
警告 部門より
Googleが7月にリリースを予定しているChrome 68では、すべてのHTTP接続ページで安全性に関する警告が表示されるようになるそうだ(Chromium Blogの記事Softpediaの記事VentureBeatの記事The Registerの記事)。

GoogleはHTTP接続ページで情報アイコンの右側に警告メッセージ「Not Secure」(日本語版では「保護されていません」)を表示する場面を徐々に拡大しており、Chrome 56以降ではパスワード入力フィールドやクレジットカード入力フィールドを含むHTTP接続ページで警告が表示されるようになった。Chrome 62以降ではHTTP接続ページの任意の入力フィールドへの入力を開始すると警告が表示されるようになり、シークレットウィンドウではすべてのHTTP接続ページで警告が表示されるようになっている。

Chrome 68では現行版のシークレットウィンドウでHTTP接続ページを表示した場合と同様、すべてのHTTP接続ページで「保護されていません」と表示されることになる。
13489587 story
ニュース

パスワード管理ツールを開発するKeeper Security、脆弱性を伝える記事を掲載したメディアを提訴 7

ストーリー by hylom
えー 部門より
あるAnonymous Coward曰く、

Windows 10に同梱されるようになったパスワード管理ツール「Keeper」に深刻な脆弱性が存在することが発覚した(窓の杜)。これに対しKeeperを開発するKeeper Security社は修正を行うとともにこの問題で影響を受けたという顧客からの報告はないと報告している。さらにこれを伝えたArsTechnicaや記事の執筆者を名誉棄損で訴えるとしているという(ZDNetSlashdot)。

問題の脆弱性はWebブラウザ向け拡張機能に存在するもので、外部からコンテンツやスクリプトをあたかも信頼できるもののように挿入できるというもの。この問題は以前にも指摘されており修正されていたが、再び同じ問題が発生するようになっていたという。報告を受けてKeeper Securityは問題を修正したとのこと(Issueへのコメント)。

この問題はArsTechnicaが「For 8 days Windows bundled a password manager with a critical plugin flaw」という記事で報道したが、これに対しKeeper Security側は「16か月もの間不具合が放置されていたかのような印象を与える間違ったものだ」として訴えたそうだ。

13470116 story
Chrome

Windows版Chrome、サードパーティソフトウェアによるコードインジェクションをブロックへ 25

ストーリー by headless
計画 部門より
Windows版のGoogle Chromeでサードパーティソフトウェアによるコードインジェクションをブロックする計画が発表された(Chromium Blogの記事VentureBeatの記事9to5Googleの記事The Registerの記事)。

Windows版Chromeではユーザー補助ソフトウェアやアンチウイルスソフトウェアなど、Chromeと一緒に動作するソフトウェアをおよそ3分の2のユーザーが使用しており、中には機能を実現するためにコードをChromeにインジェクトするソフトウェアも存在する。しかし、このようなソフトウェアを使用しているユーザーでは、Chromeのクラッシュが15%多く発生するという。現在ではChrome拡張Native Messagingで同様の機能を実現可能になっており、コードインジェクションをブロックしても問題ないと判断したようだ。

変更は3段階で行われ、2018年4月にはChrome 66でクラッシュの発生したユーザーに対し、Chromeにコードをインジェクトするソフトウェアの存在を通知して更新や削除を促す。7月にはChrome 68でサードパーティソフトウェアによるコードインジェクションのブロックが開始される。ブロックによりChromeの起動が妨げられる場合、インジェクションを有効にしてChromeを再起動する一方、ユーザーにはソフトウェアを削除するように求める。2019年1月のChrome 72ではこのような暫定処置を終了し、コードインジェクションが常にブロックされるようになるとのこと。

なお、Microsoftが署名したコードやユーザー補助ソフトウェア、IMEについてはブロッキング対象から除外される。これらの変更に対応するため、開発者に対してはChrome Betaを使用した早めのテストが推奨されている。ただし、現在のDev ChannelはChrome 64Beta ChannelはChrome 63なので、もう少し先の話のようだ。
typodupeerror

Stay hungry, Stay foolish. -- Steven Paul Jobs

読み込み中...