カテゴリー
Windows

IE 7のセキュリティ改善を台無しにするIE 7 Beta2日本語版

IE7の設定画面の日本語訳の話。

そして、同図右のように、「(not secure)」な項目を選択すると、その設定項目部分の背景色が赤っぽくなり、項目タイトルの「Download signed ActiveX controls」の右の部分に、「(not secure)」と表示され、この項目が「安全でない」設定になっていることを警告するようになった。

今後ユーザは、ここが「赤くなるような設定使ってはいけない」ということになる。

そして、IE 7 Beta 2の日本語版が先日リリースされた。この画面がどうなっているかを確認したところ、図2のようになっていた。

図2: 図1の日本語版での翻訳

なんだこの「(セキュリティで保護されていない)」というのは。SSLが使われていないとでも言いたいのか?

マイクロソフトの日本語化係の人は、「安全でない (not secure)」という言葉をどうしても使いたくないのだろうか。

確かに日本語版IE7の表記は紛らわしいですね。

not secure = 安全でない = 危険

なので

セキュリティで保護されていない = 危険

に変えた方が分かりやすいかな。

カテゴリー
Windows

Windows PowerShell RC1

Perlの様な文法を持つシェルだそうです。.NETが自由自在に使える(?)のかも。

# Over 130 standard utilities (called “cmdlets) for completing common system administration tasks such as working with the registry, services, processes, Windows Management Instrumentation, event logs, etc..

# Intuitive, task-based scripting language and support for existing scripts and command line tools..

# Designed for consistency so all tools and system data stores follow a common syntax, common naming conventions and information can be easily shared/piped between tools.

# Simplified command-based navigation of the operating system (including drives, startup files, and registry).

# Powerful object manipulation capabilities (objects can be directly manipulated or pipelined to other tools or databases).

# Designed for extensibility so that independent software vendors and enterprise developers can easily build custom tools and utilities to administer their software.

WindowsXP以上が必要らしい。

インストールされたプログラムくらいは簡単にリストできるようになっているようです。次がMSDNに掲載されていたインストールされたプログラムをリストするコードです。とても簡単ですね。

$strComputer = "."

$colItems = get-wmiobject -class "Win32_Product" -namespace "root\CIMV2" `
-computername $strComputer

foreach ($objItem in $colItems) {
      write-host "Caption: " $objItem.Caption
      write-host "Description: " $objItem.Description
      write-host "Identifying Number: " $objItem.IdentifyingNumber
      write-host "Installation Date: " $objItem.InstallDate
      write-host "Installation Date 2: " $objItem.InstallDate2
      write-host "Installation Location: " $objItem.InstallLocation
      write-host "Installation State: " $objItem.InstallState
      write-host "Name: " $objItem.Name
      write-host "Package Cache: " $objItem.PackageCache
      write-host "SKU Number: " $objItem.SKUNumber
      write-host "Vendor: " $objItem.Vendor
      write-host "Version: " $objItem.Version
      write-host
}

http://www.microsoft.com/technet/scriptcenter/scripts/msh/apps/user/usapms01.mspx

今までWindowsでバッチ処理というとWSHによりVBScript/JScriptで記述する事が普通でしたがPerl風のPowerShellもオプションに加えられた形になります。どう便利なのか今ひとつ分かっていませんがサンプルコードを見る限りは非常に簡単にWindowsの情報を取得して処理を行えるようになっている様です。

Exchange Server 2007 and System Center Operations Manager 2007 (Microsoft Operations Manager “V3”) will be built upon Windows PowerShell.

Exchange Server 2007はPowerShellを使って構築されている、と書かれています。色々複雑な処理も簡単(?)に行えるような言語になっていると思われます。Windowsでバッチ処理が必要な場合はPowerShellも良い選択肢なのかも知れないです。

カテゴリー
Windows

Windows Vista のUser Acount Protection(UAP)機能

The bad news, then, is that UAP is a sad, sad joke. It’s the most annoying feature that Microsoft has ever added to any software product, and yes, that includes that ridiculous Clippy character from older Office versions. The problem with UAP is that it throws up an unbelievable number of warning dialogs for even the simplest of tasks. That these dialogs pop up repeatedly for the same action would be comical if it weren’t so amazingly frustrating. It would be hilarious if it weren’t going to affect hundreds of millions of people in a few short months. It is, in fact, almost criminal in its insidiousness.

と非常に使いづらい、と書いてあります。

このUAPと言う機能、MacOSXやLinuxユーザなら知っている管理者権限の必要な操作を行う場合にクレデンシャル(管理者ユーザのパスワード)を聞く機能です。個人的にはVistaには非常に期待しているのでこんな部分で使い物にならないようにされては困ります…

カテゴリー
Computer Windows

2006年はIEが安全に使えた日はまだ0日!?

【追記】

他のWindows XP+IE6の最新環境で試してみました。
ダウンロードした.htmファイルを開いてJavaScriptが実行されてもクッキーは表示されませんでした。表示しなかった環境はほとんど何も触っていない状態のWindows XP+IE6環境です。クッキーを表示するのは普段使っているノートPCのWinXP+IE6最新環境です。何か原因があるはずですが今のところ動作の違いの原因は分かっていません。参考までにIE関連で何が入っているかというと

-Google Toolbar (page rank付き)
-Norton Internet Security
-Java(JRE1.5)

が入っています。これらはクッキーを表示しないPCの環境には入っていません。少なくとも手元の環境では脆弱性が再現するWinXP PC1台と再現しないWinXP PC1台がありました。

そこでVMWare5でWinXP SP2をインストールした直後の状態のクローンを作成して試してみました。Windows Updateを全て適用、全ての更新が正しく適用されている事を確認後、「ファイルを開く」でJavaScript付き.htmを開いてみたところクッキーが表示されました。クッキーにアクセスできる脆弱な状態が普通なのか?それとも普通(?)はクッキーにはアクセスできないのかどちらなのでしょうね?

他にCSSXSS脆弱性が直っていないらしいので、どちらにしろ結局IEが安全では無い日は昨年から続いていますが。

———–

IEで意図しないJavaScriptが実行される問題の話です。
この問題は4月の定例パッチの直前に明らかになったので修正できなかった問題と思われます。結果として昨年末から既知の脆弱性があるままの状態が継続しています。

IEが拡張子ではなくデータの内容によって適当(と言うより不適切)に処理してしまう事は有名ですが、この問題は拡張子を優先してしまって問題になったケースと言えると思います。.htmを拡張子に持つファイルを送信する際にContent-Dispositionにattachment指定しても、これを無視してinlineでhtmlとしてファイルを処理してしまい(?)クッキーが漏洩してしまいます。今月のMSの定期更新にはこの件に関する修正が無いようだな、と思っていましたが修正されていないようです。

Googleはこの問題の為に.htmファイルをzipに圧縮するようにしたようです。

脆弱性のデモサイトがあります。

http://xs.vc/content-disposition/

にどのような動作になるかテストでるようになっています。
まず、ここにアクセスすると

SECRET=12456767890

とサイトが設定したクッキーがJavaScriptのAlartダイアログボックスで表示されます。ページ中の添付ファイル(Content-Disposition: Attachment)の.htmはAttachmentであるのでダウンロードされ、サイトが設定したクッキーを表示できるべきではありません。しかし、パッチ適用後のIEでも添付ファイルを開くと添付ファイル中のJavaScriptが実行され

SECRET=1234567890

とJavaScriptのダイアログが開いてしまいます。(Firefoxをデフォルトのブラウザにしている方はIEをデフォルトブラウザに変更してから試してください)

つまりこの脆弱性を利用すると、.htmファイルを添付できるサイトのクッキーを盗めてしまいます。.htmファイルを添付できる仕様のサイトはGoogleの様にzipに圧縮する等の対策を行わないとクッキーを盗まれます。ユーザとしての自衛は簡単で.htmファイルは「開かず保存してから見る」と大丈夫です。

この仕様(というかバグ)はWebメールや添付ファイルをサポートする掲示板、CMS、Wiki、バグ管理システム等で影響があります。私が現時点で把握している最新版IEのセキュリティ上の問題はこれだけです。IEセキュリティのリサーチをしている訳ではないので他にも脆弱性があるのかも知れません。他にあったら是非教えてください。

とにかく、私にが知る限りでも2006年になってからIEが安全に使えた日(攻撃可能な既知の問題が無かった日)はまだ無いです… 残念…

カテゴリー
Computer Windows

4月のIEのパッチ

MS06-013 Cumulative Security Update for Internet Explorer (912812)

では

CVE-2006-1191 – Cross-Domain Information Disclosure Vulnerability

に対応となっているので直ると思っていて良いのでしょうか?多分今度はきちんと直っているのでしょうね。

直るとされているセキュリティホールは次の通り。

CVE-2006-1359 – DHTML Method Call Memory Corruption Vulnerability
CVE-2006-1245 – Multiple Event Handler Memory Corruption Vulnerability
CVE-2006-1388 – HTA Execution Vulnerability
CVE-2006-1185 – HTML Parsing Vulnerability
CVE-2006-1186 – COM Object Instantiation Memory Corruption Vulnerability
CVE-2006-1188 – HTML Tag Memory Corruption Vulnerability
CVE-2006-1189 – Double-Byte Character Parsing Memory Corruption Vulnerability
CVE-2006-1190 – Script Execution Vulnerability
CVE-2006-1191 – Cross-Domain Information Disclosure Vulnerability
CVE-2006-1192 – Address Bar Spoofing Vulnerability

出典:eEye Digital Security

かなり強力な穴ぞろいなのでユーザ全てが直ぐにパッチを当てて欲しいです。しかし今度のアップデートは「Flashが動かなくなる」という噂が先行しているのでアップデートしないユーザも多数でそうな気がします。

数がどれくらいになるか分かりませんが、
CVE-2006-1359 – DHTML Method Call Memory Corruption Vulnerability
のお陰でスパイウェアをインストールされてしまったユーザはかなりの数になると思います。

IEは今年に入ってからリモートから攻撃可能な既知のセキュリティホールが無い状態が1日も無いですが、今度のアップデートで全部直っているのかな?

カテゴリー
Windows

Microsoftのオープンソースラボ

オープンソースと対決、とは違う路線を模索というところでしょうか?

カテゴリー
Windows

それでもIEを使いますか?

IEは危険すぎるので使わない方が良いと言っています。過去の実績から言っても明らかです。2004年には1年の内、98%の期間、既知のセキュリティホールに対して脆弱だったとされています。

MSIE was 98% unsafe. There were only 7 days in 2004 without an unpatched publicly disclosed security hole.

Firefox was 15% unsafe. There were 56 days with an unpatched publicly disclosed security hole. 30 of those days were a Mac hole that only affected Mac users. Windows Firefox was 7% unsafe.

さすがにセキュリティホールのレポートが少なくなってきたかな、と昨年末頃には思っていたのですが、最近はすごい事になっています。危険なIEのセキュリティホールが次々に発見されています。

セキュリティ系MLでも書かれていましたが明日にもセキュリティパッチがリリースされる模様です。

Firefoxでは参照できないサイトもIE Viewをインストールしていればさほど困りません。

注意しなければいけないのはFirefoxを使っていても一年の内15%ほど期間な期間があった事です。エンドユーザ教育として「Winnyをインストールしない・使わない」と教えるのも良いですが「ブラウザは危険です」と教える必用があるかと…

# 多くのWebサイトがかなり危険な状態である事も教える必用がありますね…