ちゃっぴの監禁部屋

安全でないライブラリのロードにより、リモートでコードが実行される という seurity advisory が出ています。まあ、ここ読んでいるような人にとってはすでに知っていることだと思いますが。

ちょっと興味があったので、いろいろ情報あさっていましたが、正確なところはわかりませんがどうやら下記のようなことじゃないかと。

LoadLibrary や LoadLibraryEx 等を利用して DLL を動的に load する場合、絶対 path を指定しないと Dynamic-Link Library Search Order の順序に従って DLL が検索されます。

この検索先の中に current directory が含まれるのがミソで、load する予定の DLL と名前が完全に一致する DLL が存在するとそいつが読み込まれてしまう。

直接呼ばれる関数に攻撃 code を仕込んでおけばいいわけですが、Win32 DLL には DllMain という DLL を load されるときに自動的に実行される entry point があるので、こいつを使えばもっとお手軽。

ここまでは全然新しくない話なんですが、今回出てきたのは current directory が remote (SMB や WebDav) 上だった場合、remote に file を配置しておくだけで攻撃が可能ということ。

個人的には application が file を開くときに current directory を変更して開くなんて考えずらいと思っていましたが、この攻撃が可能な application は 40 以上存在するとのことなので。

Update: 40 Windows apps contain critical bug, says researcher

この問題への対応としては、Dynamic-Link Library Security にまとめられています。

• LoadLibrary, LoadLibraryEx, CreateProcess, ShellExecute を呼び出すときは可能な限り fully qualified path を利用する。
• Dynamic-Link Library Redirection, Manifests を利用し正しい DLL を呼び出すことを強制する。
• Registry HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode を変更し DLL の検索順序を変更する。
• DLL を呼び出す前に SetDllDirectory に "" を指定して current directory の path を除去する。 (Multi thread, process 間での競合注意)
• Safe process search mode が有効になっていないときは SearchPath を利用しない。SearchPath をどうしても利用する必要があるときは先に SetSearchPathMode に BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE を指定して呼び出した後に利用する。Current directory は最後に回されるが除去はされないので注意が必要。
• LoadLibrary?が検索する DLL の検索順序は OS によって異なるので、推測だけで行わない。ちゃんと OS version 確認しましょう。

基本的な対応としては application code の修正です。ということで、DLL を dynamic load している application の開発者は について既存の code に問題が無いかご確認ください。

なお、DLL の検索対象から current directory を除去する方法については WebDav や SMB のみ除去するといった設定が可能になる patch が提供されています。

DLL 検索パス アルゴリズムを制御する新しい CWDIllegalInDllSearch レジストリ エントリについて

WebDav のみ SMB のみ不可といった制限も可能なので patch を適用した上で設定を変更しておいたほうがよいでしょう。WebDav, SMB 不可程度であればほぼ影響は無いでしょうから。

• 新たなリモートの攻撃手法に関するアドバイザリ 2269637 を公開
• DLL Preloading Attacks
• DLL hijacking vulnerabilities

Web browser の TLS cipher suites を比較してみる
Windows の TLS chipher suites の順序を変更する方法

上記の続き。

Windows 7 以降の OS では TLS 1.2 が利用できるようになりました。

• TLS v1.2 の概要

Internet Explorer の [インターネット オプション] の [詳細設定] - [セキュリティ] - [TLS 1.2 の使用] がその設定です。既定では無効になっています。

ただ、上記で [TLS 1.2 の使用] を有効化しても、それだけでは TLS 1.2 は利用されません。TLS 1.2 を利用するためには [システム暗号化: 暗号化、ハッシュ、署名のための FIPS 140 準拠暗号化アルゴリズムを使う] policy を有効化する必要があります。こちらも既定では無効です。

[グループポリシー エディター] で [Windows の設定] - [セキュリティの設定] - [ローカル ポリシー] - [セキュリティ オプション] で [システム暗号化: 暗号化、ハッシュ、署名のための FIPS 140 準拠暗号化アルゴリズムを使う] を有効化します。

有効化したら gpupdate.exe を利用し policy を即時適用します。

>gpupdate.exe /force
ポリシーを最新の情報に更新しています...

ユーザー ポリシーの更新が正常に完了しました。
コンピューター ポリシーの更新が正常に完了しました。

これで適用されました。IE の設定も含めて再起動は一切必要ありません。

以上の設定を施すと Client Hello で送信される Version が TLS 1.2 に cipher suites は下記のように変わります。

FIPS 140 準拠 policy を有効化したことにより RC4 が使えなくなっていますね。 この状況では SSL で接続できない Web site が出てくるかもしれないですね。また、FIPS 140 準拠 policy は SSL / TLS に限らず、Windows CNG (Crypto Next Generatin) API の動作に影響するため、適用にあたっては最新の注意が必要になるでしょう。

同じ API を利用している Chrome, Opera は TLS 1.2 を有効化する設定項目が見当たらないため、Version は常に TLS 1.0 を送信し、TLS 1.1 および TLS 1.2 で追加された cipher suites は利用できません。ただ、FIPS 140 準拠 policy の影響は受けるので RC4 が利用できなくなります。

• システム暗号化 : 暗号化、ハッシュ、署名のための FIPS 準拠アルゴリズムを使う - Windows Server 2003
• TLS/SSL Cryptographic Enhancements - Windows Vista
• Cipher Suites in Schannel
• FIPS 140 Evaluation

Web browser の TLS cipher suites を比較してみる のつづき。

Internet Explorer で AES 256 bit を使いたいのに順番が低いため使えね～。とお怒りの方ももしかするといらっしゃるかも知れませんが、これは Windows Vista 以降であれば group policy で変更できます。

[ファイル名を指定して実行] で「gpedit.msc」と入力。

[コンピューターの構成] - [管理用テンプレート] - [SSL 構成設定] と node を展開し、[SSL 暗号の順位] を double click。

Policy を有効化し、"," comma で区切ったcipher suites list を入力する。途中 space を含めることができないので注意。

普通の group policy であれば、gpupdate.exe /force で反映がかかるのですが、試してみた感じでは Windows を再起動するまで設定が反映されませんでした。

なお、この group policy を変更すると Chrome, Safari の cipher suites も IE と全く同じになります。Chrome, Opera の TLS (SSL) は IE と同じ API 使っているのは間違いないですね。Firefox や Opera は影響を受けません。こちらは独自のものを利用している模様。

<参考>

• Changing the SSL cipher order in Internet Explorer 7 on Windows Vista
• Prioritizing Schannel Cipher Suites

TLS (SSL) は Client Hello で client が利用可能な cipher suites (公開鍵暗号、共通鍵暗号、hash algorithm) を提示し、Server Hello で実際に利用する cipher suite を決定します。

Client Hello で送信される cipher suites は Web browser によりまちまちです。各 Web browser の default 設定で送信される cipher suites の調査結果は下記です。Client OS は Windows 7 です。

Chrome と Safari は Internet Explorer 8 と全く一緒です。

Internet Explorer は AES 128 bit を使いたがりますが、Firefox は AES 128 bit よりも RC4 128 bit を使いたがります。Firefox は CAMELLIA や SEED にも対応していますね。

Cipher suites は RFC で管理されているようなんですが、その documents が散らばっているので下記にまとめておきます。

Windows Vista 以降の Windows Firewall では firewall を profile 毎に個別管理できるようになりました。

セキュリティが強化された Windows ファイアウォール ファースト ステップ ガイド

新しい network に接続したときに下記のような dialog が出てくるのでおなじみですよね。

自宅、もしくは企業内であれば必ず 「パブリック ネットワーク」 を選択してください。また、 「パブリック ネットワーク」 の firewall は絶対に緩めないでください。

実は昨日の勉強会で無線 LAN に接続している端末の firewall の状態を確認するため、ICMP と SMB で接続を試してみました。無線 LAN に接続されている host が 39 台あり、内 9 台は ICMP が通り、8 台は SMB で接続が可能でした。

まあ、勉強会の無線 LAN で攻撃される可能性はほぼ無いと思うので問題は無いと思いますが、気になるのは別の network に接続したときの firewall 設定です。

最近は EMOBILE や UQ WiMAX または公衆無線 LAN とかいろいろ利用している人が多いでしょう。このような network に接続している場合、直接 global IP address が割り当てられる) 場合が多いです。

>ipconfig.exe /all 
PPP アダプター EMOBILE:
 
   接続固有の DNS サフィックス . . . :
   説明. . . . . . . . . . . . . . . : EMOBILE
   物理アドレス. . . . . . . . . . . :
   DHCP 有効 . . . . . . . . . . . . : いいえ
   自動構成有効. . . . . . . . . . . : はい
   IPv4 アドレス . . . . . . . . . . : 114.48.188.112(優先)
   サブネット マスク . . . . . . . . : 255.255.255.255
   デフォルト ゲートウェイ . . . . . : 0.0.0.0
   DNS サーバー. . . . . . . . . . . : 60.254.193.158
                                       117.55.64.152
   プライマリ WINS サーバー. . . . . : 10.11.12.13
   セカンダリ WINS サーバー. . . . . : 10.11.12.14
   NetBIOS over TCP/IP . . . . . . . : 無効

>ipconfig.exe /all
イーサネット アダプター WIMAX0:

  接続固有の DNS サフィックス . . . : uqc.ne.jp
  説明. . . . . . . . . . . . . . . : Intel(R) Centrino(R) WiMAX 6250
  物理アドレス. . . . . . . . . . . : **-**-**-**-**-**
  DHCP 有効 . . . . . . . . . . . . : はい
  自動構成有効. . . . . . . . . . . : はい
  IPv4 アドレス . . . . . . . . . . : 119.107.210.237(優先)
  サブネット マスク . . . . . . . . : 255.255.255.255
  リース取得. . . . . . . . . . . . : 2010年7月25日 22:46:06
  リースの有効期限. . . . . . . . . : 2010年7月26日 22:46:06
  デフォルト ゲートウェイ . . . . . : 119.107.200.135
  DHCP サーバー . . . . . . . . . . : 119.107.200.135
  DNS サーバー. . . . . . . . . . . : 119.107.200.151
                                      119.107.200.23
  NetBIOS over TCP/IP . . . . . . . : 有効

Subnet mask は 255.255.255.255 になっていますが、global IP が割り当てられていて途中で filtering されていないため、listen しているすべての port が攻撃にさらされていますね。

以前 EMOBILE の network で脆弱性を突く network packet を検知できるような firewall を入れてしばらく monitor してみましたが、ほんとアホのように攻撃がきていました。脆弱性が存在したら間違いなくいちころです。めちゃくちゃ危険ですよ！

とはいえ、自宅や企業内で利用する場合には firewall に許可構成を入れないと問題がある場合も多いでしょう。ですから mobile PC では profiling機能を持つ firewall を導入することは必須です。

すでに書きましたが Windows Vista 以降の OS では標準で profile 機能を持つ firewall を持っています。Windows XP 以前にはありません。Third pary 製の fireawall に関してはここ数年調査していませんが、こちらも profiling 機能を持っていないのであれば、mobile PC でそれのみに頼るのは大問題ですね。

思い当たる方はぜひこの機会に firewall の構成を確認してください。非常に危険ですよ！

先日 main で利用している notebook PC を Thinkpad X60 (1709-GDJ) から Thinkpad X201s (5129-CTO) に変更しました。

基本的に選べるものは最上級のものを使う感じですねが、OS, memory および HDD は乗せえる前提なので、最低のものを選択しています。 Ultra base は特に必要ではなかったんですが、無料 campaign やっていたので付けることに。

発注時には結構待たされるような連絡を受けましたが、おおよそ 2 週間後には商品が届きました。

現在は上記構成から HDD を Seagate ST9640320AS に、 memory を MICRON PC3-8500 DDR3 4 GB x 2 に、OS を Windows 7 Ultimate x64 Edition に変更しています。この構成での Windows experience index は下記の通り。

以前利用していた Thinkpad X60 (1709-GDJ) との比較考察は下記の通り。

• プロセッサ
  5.0 → 6.6 に。以前は Core 2 duo T7200 で当時の最上級だったんですが、やっぱり向上しているようですね。Core i7 640LM 伊達じゃないかも。

• メモリ
  5.0 → 6.6 に向上していますが、これは PC2-5300 から PC3-8500 への変更結果ですね。

• グラフィックス
  3.4 → 3.3 と低下していますが、monitor が XGA (1024 x768) から WXGA+ (1440 x 900) に変わったため実際には向上しているといえるでしょう。

• ゲーム用グラフィックス
  解像度の向上があるにも関わらず 3.2 → 4.8 と大幅に伸びています。ぶっちゃけ、こんなにいらないんですが。

• プライマリ ハードディスク
  5.7 → 5.9 に。2.5 inch 5200 rpm なので、まあこんなもんですね。

ということで非常に快適です。

Performance が良好というのもあるんですが、それ以上に快適と感じる部分が他にもいろいろ存在します。

• 発熱
  T7200 はめちゃくちゃ熱く、ここのところのような猛暑だと確実に落ちますｗ それに比べて Core i7 640 LM は発熱が少なく、本日のような猛暑でも問題ないですね。

• Battery の持ち
  以前は 4 cell battery だったので数時間持ちませんでした。今回 9 cell にしたのでこれで battery に気を使わなくてすみそうです。9 cell にしても X201s だと重さは気にならないのがすごいところ。

• 解像度の向上
  WXGA+ はやっぱり快適ですね。ただ、notebook PC 全体の大きさに比べて panel の大きさが小さめなので、改善の余地があるかも。

• Memory 容量
  常に Web browser windows を数十個開けているような人間なので、memory 3 GB では余裕で足りなくなっていました。8 GB にしたので、大量に開いても全く問題ないですね。

• Ultra base
  今までいらないと思っていたので利用していませんでしたが、電源、UTP cable を常に Ultra base につないでおいて、docking で切り離しを行う。これ結構快適かも。今回は無料だったのでいいですが、それなりの金額出して別途購入するのはどうかな～。

• 終了、起動が高速
  WindowsR 7 Lenovo Enhanced Experience のおかげだと思いますが、起動、終了がものすごく高速です。Memory 8 GB あるので休止状態は現実的ではないですから起動、終了の高速化はものすごく大きいですね。

全体的な印象としては Thinkpad X60 (1709-GDJ) は実は欠陥品 (特に発熱) だったのでは？と思うくらい Thinkpad X201s は快適です。この満足度は Thinkpad X31 (2672-BBJ) 以来だなぁ。

最近は UQ WiMAX を試用していますが、以前から EMOBILE を外出先の main 回線を利用しています。EMOBILE への接続は通常は EMOBILE から提供されている utility を利用している人が多いと思いますが、私は利用していません。というのは、別の接続 utility を使っていたり、OS 標準の機能の方が使いやすいからです。

ただ、EMOBILE から提供されている utility を利用しない場合、大きな問題があります。接続設定によって接続完了までの時間が大幅に変わってくるという問題です。

Windows Vista 以降の OS では既定で IPv6 が有効化されています。IPv6 が有効な状態では下記 dialog で数十秒から ～ 1 分程度余計な時間がかかります。

これを解消するには IPv6 を無効化すればよいです。なお、以降の設定手順および画面はすべて Windows 7 です。

必要無いので上記画面では IPv6 だけではなく「Microsoft ネットワーク用クライアント」も無効化しています。

IPv6 を無効化する弊害としては当然ですが、IPv6 が利用できなくなります。EMOBILE からの公式情報はありませんが、EMOBILE は IPv6 の IP address は取得できないものの、Tunnel adapter 6TO4 adapter を通じて IPv6 を扱えます。

>ipconfig.exe /all
PPP アダプター EMOBILE:

   接続固有の DNS サフィックス . . . :
   説明. . . . . . . . . . . . . . . : EMOBILE
   物理アドレス. . . . . . . . . . . :
   DHCP 有効 . . . . . . . . . . . . : いいえ
   自動構成有効. . . . . . . . . . . : はい
   IPv4 アドレス . . . . . . . . . . : 114.48.188.112(優先)
   サブネット マスク . . . . . . . . : 255.255.255.255
   デフォルト ゲートウェイ . . . . . : 0.0.0.0
   DNS サーバー. . . . . . . . . . . : 60.254.193.158
                                       117.55.64.152
   プライマリ WINS サーバー. . . . . : 10.11.12.13
   セカンダリ WINS サーバー. . . . . : 10.11.12.14
   NetBIOS over TCP/IP . . . . . . . : 無効

Tunnel adapter 6TO4 Adapter:

   接続固有の DNS サフィックス . . . :
   説明. . . . . . . . . . . . . . . : Microsoft 6to4 Adapter
   物理アドレス. . . . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP 有効 . . . . . . . . . . . . : いいえ
   自動構成有効. . . . . . . . . . . : はい
   IPv6 アドレス . . . . . . . . . . . : 2002:7230:bc70::7230:bc70(優先)
   デフォルト ゲートウェイ . . . . . : 2002:c058:6301::c058:6301
   DNS サーバー. . . . . . . . . . . : 60.254.193.158
                                       117.55.64.152
   NetBIOS over TCP/IP . . . . . . . : 無効

IPv6 が有効化された状況では http://www.kddi.com へ IPv6 address を直指定 (http://[2001:268:fd02::1]/) してみましたが、問題なく接続できます。Network inteface から IPv6 を無効化すると接続できないことを確認しました。

参考 イーモバイル(emobile)はIPv6対応しているデュアルスタック構成のようだ。

ただ、IPv6 の利用がまだ一般的で無いことと、EMOBILE から直接 IPv6 address を払い出させるわけではないので、IPv6 を無効化しても問題ないでしょう。接続完了までに数十秒を超える時間がかかることの方が問題だと思いますので。

接続完了までの時間への影響は IPv6 が有効であるかが最も大きいですが、その他にもいろいろ接続設定項目ありますので最適と思われる設定を示します。

[オプション] tab で下記の check をはずす。

• 名前、パスワード、証明書の入力を求める
• Windows ログオン ドメインを含める
• 電話番号の入力を求める

[セキュリティ] tab で下記 check をはずす。

• 暗号化されていないパスワード (PAP)
• Microsoft CHAP Virsion 2 (MS-CHAP v2)

これで接続完了が遅いことに対するいらいらが解消できるでしょう。

なお、最近利用している UQ WiMAX は IPv6 を全く support していないようです。

UQ WiMAX Certificationプログラム - Q IPv6には対応していますか？

EMOBILE での場合と同様に http://[2001:268:fd02::1]/ への接続を試行してみましたが、こちらは接続できませんでした。

UQ WiMAX の場合、IPv6 が有効になっていても EMOBILE のように接続完了までの時間が大幅に伸びることはありませんが、無駄な処理を行うことになるので EMOBILE 同様 IPv6 を無効化しておくことをお勧めします。

「UQ WiMAX を試してみる」で UQ WiMAX に接続できるようになったので、どのくらい速度が出るか試してみました。とりあえず、自宅で試したんですが、そのときの信号強度は 48 ~ 52 % でした。

• 速度測定結果 1 (UQ WiMAX)

  
  

• 速度測定結果 2 (UQ WiMAX)

  
  

• 速度測定結果 3 (UQ WiMAX)

  
  

下りは 3 ～ 5 Mbps で上りは 1 ～ 2.5 kbps でした。UQ WiMAX の回線速度公称値は下り最大 40 Mbps、上り最大 10 Mbps なのでものすごく低い値ですね。(*)WiMAX は信号強度が下がると大幅に速度が低下するという話もあるので、後日信号強度が高い地点で再検証してみます。

以前から EMOBILE から利用しているのですが、自宅での速度は下記です。

• 速度測定結果 4 (EMOBILE)

  
  

利用している modem は D21HW なのでこちらの公称値は下り 7.2 Mbps、上り 1.4 Mbps です。下りは大幅に減退しているものの上りの速度は優秀ですね。

ということで、USTREAM 等で live 配信をする場合、信号強度が低いのであれば上りが安定している EMOBILE を利用したほうがよさそうですね。Web browsing を行ったりするのであれば、UQ WiMAX を利用したほうがよさそうです。

そんな感じでいろいろ試してみる予定です。

[追記]

私が利用している WiMAX adapter インテル® Centrino® Advanced-N + WiMAX 6250 での公称値は下り最大 20 Mbps 上り最大 6 Mbps です。UQ WiMAX の公称値よりも低いです。

先日 Thinkpad X201s (5129-CTO) を購入しました。

Wireless network adaptor に「インテルR CentrinoR Advanced-N + WiMAX 6250」を選択したので、とりあえず使ってみようということで、自宅で UQ WiMAX を利用してみました。

15 日は無償で利用できるということなんですが、WiMAX adaptor を rental するのではなく、持っている WiMaX adaptor を利用して試す方法がわかりにくい。

15日間WiMAXお試し利用 Try WiMAX for PC

上記に書いてある通りなんですが、申し込むにはまずは UQ WiMAX に接続する必要があります。

私の端末は HDD を入れ替えて OS も入れ替えているので WiMAX の接続 utility なんてものはありません。なので、手動で WiMAX に接続することが必要です。Thinkpad には Access Connections という network connections manager が存在するのでそれを利用して UQ WiMAX に接続しました。

Access Connections を利用する場合、場所によっては UQ WiMAX が検知できないため、検知できない場合には [ワイドスキャン] を実施してください。UQ WiMAX が見つかればそれを click すれば接続できます。

その後、Web browser を立ち上げると UQ WiMAX の Web page が表示されるので、そこで [Try WiMAX for PC はこちら (15日間WiMAXお試し利用)] を click して登録してください。

これで、UQ WiMAX を 15 日間利用できるようになりました。

接続状況とかいろいろ試してみようと思っているので、おいおい blog に書いていくつもりです。

Excel Workbook を読み込む方法はいろいろ存在します。Excel 2003 までだとこんなのがありました。

• Microsoft Excel Object Model (Automation) を利用
• Microsoft JET を利用
• Excel binary file format を直接扱う

Microsoft Excel Object Model (Automation) を利用

Automation (COM) を利用する方法はあまりにも有名なので、あえて説明する必要すらありませんね。これを利用すれば Microsoft Excel の全機能を制限なく扱うことができます。ただし、Microsoft Excel を利用するので Microsoft Excel が install されている環境でないと利用できません。また、server-side での実行も support されていません。詳しくは下記参照。

• Office のサーバーサイド オートメーションについて

Excel binary file format を直接扱う

Binary format を直接扱う方法はおそらくやる人いないでしょう。昔は仕様が公開されていませんでしたが、現在は公開されています。まあ、やるのであれば頑張ってくださいとしか。。。

• [MS-XLS]: Excel Binary File Format (.xls) Structure Specification

Microsoft JET を利用

Microsoft JET を利用する方法は知らない人結構いるんじゃないでしょうか？ Microsoft JET とはもともと Microsoft Access DB engine に接続するための data access provider ですが、その他の data source を扱うための Excel driver や Text File Driver を同梱しています。

これらの driver は当初 MDAC として別の component として提供されていましたが、Windows 2000 から OS に同梱されるようになり、Windows XP 以降では別の component として提供されることは無くなりました。なお、JET は MDAC 2.7 以降で MDAC から削除されていますが、Windows 2000 以降の OS では標準で Microsoft JET (version が古い可能性はある) が含まれているため、そのまま利用できます。

• Universal Data Access 関連ダウンロード
• Microsoft Jet 4.0 データベース エンジン用の最新の Service Pack の入手方法
• Data Access Technologies Road Map

具体的な利用方法は下記を参照してください。

• Visual Basic .NET と ADO.NET を使用して Excel ブックのレコードの取得と変更を行う方法
• コード : Excel のデータをデータ セットに読み込む (Visual Basic)
• DAO から ADO への移植2
• Excel ソース
• Excel のクエリ テーブルで動的レポートを作成する
• 接続文字列の構文 (ADO.NET)
• テスト データに Excel を使用する
• ASP から ADO を使用して Excel のデータのクエリおよび更新を行う方法
• [HOWTO] VB または VBA から ADOX を Excel データで使用する

詳細の公式 reference は ODBC のものしかないですねぇ。

• Microsoft Excel Driver Programming Considerations

まあ、この公式情報の少なさが積極的に利用されない理由だったりすると思うんですが。もっともあまりにも簡単に扱えると Microsoft Excel の売り上げに響く可能性がありますからねぇ。。。

Excel を必要とせず Excel Workbook を扱える Microsoft JET ですが、いくつか制限があります。代表的なものとしては下記。

• 1 cell で扱える文字長は 255 (Unicode 510 bytes) まで
• Password 保護された workbook は扱えない (IRM 保護されたのももちろんダメ)
• Cell の data しか扱えない (AutoShape や Graph は扱えない)

これらの制限がありますが、それなりに利用価値はあるでしょう。Server-Side でも support されていますので。

あと、Microsoft Excel 2002 から利用可能になった、XML format (Office Open XML とは異なる) がありますが、ここでは扱いませんのであしからず。