MSが勝手にWindows Update関連ファイルを更新

MSが勝手にWindows Update関連ファイルを更新

ZD Net本家のブログによるとMSは何の通知もなしに勝手にXP/VistaのWindows Update関連ファイル更新しているそうです。「勝手に更新」とはWindows Updateを実行しない設定にしているにも関わらず密かにアップデートしている、と言うことです。

変更されたファイルは以下のファイルだそうです。

The files on Vista are:

* wuapi.dll
* wuapp.exe
* wuauclt.exe
* wuaueng.dll
* wucltux.dll
* wudriver.dll
* wups.dll
* wups2.dll
* wuwebv.dll

And on XP SP2:

* cdm.dll
* wuapi.dll
* wuauclt.exe
* wuaucpl.cpl
* wuaueng.dll
* wucltui.dll
* wups.dll
* wups2.dll
* wuweb.dll

Windows Updateだけは何が何でも最新版にしたかったのか、古いバージョンをメンテナンスするのが面倒になったのか、理由は分かりませんがQA/テストを行っている方には非常に迷惑な話です。

好意的に推測するとWindows Updateのファイルの更新が必要な場合、先に更新しておかないと一旦Windows Updateを終了し、またWindows Updateを実行しなければならないからだと思います。

理由はともかく、他人のPCにインストールされているファイルを密かに更新するのはマルウェア的すぎます。

追記:
MSによるとサービス開始以来Windows Updateのファイルは密かに更新しており通常の動作だとの事です。

Microsoft said that the Windows Update service automatically updates itself “from time to time to ensure that it is running the most current technology.” “This is normal behavior, and it has worked this way since the service debuted several years ago,” the company said.

http://www.itworld.com/Comp/2218/070913msupdates/

古いURLとか、維持したくなかったのかな?

NoScriptの使い方

Firefoxユーザなら必ずインストールして使用する事をお勧めするのがNoScript拡張です。

参考:新しい紹介文を書きました。

NoScriptはデフォルトでJavaScriptの実行を拒否します。これだけでもかなり安全にWebサイトを参照できるようになります。しかし、NoScriptはプラグインの実行も拒否できるようになっています。Java, Firefox, Silverlight,その他全ての拡張を選択して実行を拒否できます。残念ながらJava, Sliverlight以外はデフォルトで実行可能に設定されています。

もっと読む

$100/Gflopsを切るクラスタ

Athlon64 X2 3800+四台のクラスタで26.25Gflops、コストは$2470。$100/Gflopsを切ってます。今年の夏でAthlon64 X2 3800+を使っているあたりからもコストをかなり気にして部品を買っている事が分かります。トータルコストで$2500を切る意気込み(というか予算が$2500だったのでしょうけど)はNICの買い方からもうかがえます。

Network Adaptor Intel PRO/1000 PT PCI-Express NIC (node-to-switch) $41.00 4 $164.00
Network Adaptor Intel PRO/100 S PCI NIC (master-to-world) $15.00 1 $15.00

TOP500のスーパーコンピュータの時期と順位の関係は以下だそうです。
http://www.top500.org/

* Nov. 1993: #6
* Nov. 1994: #12
* Nov. 1995: #31
* Nov. 1996: #60
* Nov. 1997: #122
* Nov. 1998: #275
* June 1999: #439
* Nov. 1999: Off the list

クアッドコアCPUを使えばかなりの速度になると思います。100Gflopsくらいなら気軽(?)に作れるようになりましたね。

詳しくは以下をどうぞ。
http://www.calvin.edu/%7Eadams/research/microwulf/

個人的に使うとしたらdistccでビルドマシンとかに使えそうです。しかし、普通に使える4台構成にした方がいろんな意味で幸せな気がします。

追記:
似たような物がないかちょっと調べると2003年にDual Opteron 4台クラスタの結果が見つかりました。18.8Gflopsでした。パラメータが違いますが詳しくは両方のリンクの中身を参照ください。
http://www.google.co.jp/url?sa=t&ct=res&cd=3&url=http%3A%2F%2Fwww.softek.co.jp%2FSPG%2FPgi%2FTIPS%2Fpdf%2FPGI-Opteron.pdf&ei=bkToRq-lJqKwsgK_hfX4BA&usg=AFQjCNFimrTnX2pPFPnOb2Jc9DknceLUGw&sig2=_bCnKlNqk3n7cBcDGaA-YA

そういえばIntelが80コアで1TflopsのFPUを開発した、とかニュースになっていたので数年Tflopsくらいなら気軽(?)に作れるようになるのでしょうね。

1年前の記事ですがトースターサイズで200Gflopsな物も

トースターサイズの箱で200GFLOPS、ペンティアム4を載せたPC 45台分の演算能力があるとのこと。なにか他のことに使いたいなと思った方、価格は不明ですが買えないことだけは確実です。

http://japanese.engadget.com/2006/01/17/powerblock-200-cell/

この記事を見てPS3を思い出しました。メモリが小さいのがネックですがPS3を4台クラスタにした方がMicrowulfよりコストパフォーマンスが良かったりして。

MomongaLinux 4 完全インストールガイドが第一位

ITProの「昨日のLinuxランキング」で他の完全インストールガイドを抑え、MomongaLinux 4が第一位でした。

「先週のLinuxランキングでもMomongaLinuxの記事が一位!

プロジェクトメンバとして最近全然なにもしてないですが、うれしかったのでスクリーンショットを撮っておきました :)

Momonga is No1

Momonga is No1

ビルド環境とNFS Lock問題

私のビルド環境はコンパイル用のPCがNFSマウントされているsubversionレポジトリのチェックアウトを参照するように設定されています。NFSなのでflockを利用するにはnfslockdが必要です。NFSサーバがMo3の時はNFS Lock問題は発生しなかったのですが、NFSサーバをMo4にしたらOmoiKondaraを実行中に何故かflockできなくなりRubyライブラリの中でエラーが発生するように…

面倒なのでスルー力を活かしてライブラリのflockを省略、これでビルドできる、と思ったら今度はeachでエラー

一部(?)のSIPデバイスは危ない

VoIPはセキュリティ上の脅威としてトップレベルに位置する機能です。Zone-Hに書いてある内容が幅広いSIPデバイスに適用できるとするとかなりの脅威です。

The research that was published indicates that, for at least one vendor, it is possible to automatically call a SIP device from that vendor and have it silently accept the call, even if it is still on the hook – instantly turning it into a classic bugged phone. Whereas historic telephony bugs needed physical targeting of the line running to a property or place of business, the presence of VoIP in the equation allows bugging from anywhere in the world with equal ability. Now anyone can do from their armchair what only spies and law enforcement used to be able to do from inside the telephone switch / pit / distribution board, though it’s still illegal to do so.

少なくとも一つのベンダのSIPデバイスは話し中でも密かに着信し盗聴できた、としています。盗聴器が必要ないので気軽(!?)に盗聴できます。

どれくらいのデバイスに同様の問題があるか気になります。

参考:
SIP Phoneの検索結果
http://www.google.co.jp/search?q=SIP+Phone

CSRFに脆弱なルータはWHR-G54Sだけではないはず

BaffaloのWHR-G54S
http://buffalo.jp/products/catalog/item/w/whr-g54s/
にCSRF脆弱性とレポートされています。海外製品のレポートは見かけますが、日本製のSOHOルータのレポートは記憶にないです。よくある脆弱性なので日本製のレポートは初めてではないと思いますが、個人的には初物なので書きました。

WHR−G54SはCSRF対策がない(足りない?)ので認証状態にあればFirewall設定を変更できるようです。

SOHOルータはよくターゲットにされるので管理ページにログインしたら、ログオフしてブラウザを終了させた方が良いと思います。ログオフ機能が無くても普通はログオフするとセッション情報は消去されるはずです。ログオフ機能が付いていてもブラウザを終了させるのは、ログオフ機能の実装にも問題あった場合でもセッションが切れるようにする為です。

サンプルコードを見ると

<body onload=”document.CSRF.submit()”>
<form name=”CSRF” method=”post”
action=”http://192.168.11.1/cgi-bin/cgi?req=inp&res=filter_ip.html”
style=”display:none”>

の様にJavaScriptを使ってページを表示するだけでCSRF攻撃を行うコードになっています。フォームも非表示にしているので攻撃された事に利用者はまず気が付かないと思います。

管理用ページには割と頻繁にCSRF脆弱性やXSS脆弱性が見つかっています。SOHOルータに限らず、システム管理者の方は管理用ページにログインしたらログオフとブラウザの終了を行う癖をつけると良いと思います。管理用ページにアクセスするブラウザは普段使わないブラウザにする、仮想環境からのみアクセスする等はより効果的です。
# 私はできるだけ別のマシンから管理用ページを見るようにしています。

この種の攻撃を無闇に見ず知らずの他人に攻撃して成功させるのは比較的難しいと考えられます。しかし、標的型攻撃なら非常に簡単です。例えば、知人がCSRFに脆弱な管理ページで操作している、と知っていればログインしている間に攻撃者が作ったページに誘導して攻撃を成功させるのはそれほど難しくありません。

匿名性保証ができる攻撃者なら製品設定の解説サイトを作り、そのサイトに訪問したユーザに対してCSRF攻撃を行う方法も考えられます。この場合、攻撃に成功する確率はかなり高くなると思います。

生体認証システムの脆弱性

元々生体認証は再生攻撃に弱く、通信経路の安全性確保は必須であることは常識だと思うのですが…. 生体認証システムには設計が脆弱な物もあるようです… どの製品と明記されていませんが、このホワイトペーパーに書いてある製品はダメ過ぎです。

Anti DNS Pinning/DNS Rebinding/DNS multi-pinning

備考:かなり古いブログですが公開し忘れしていた分です。

この話題はどちらかというとWebブラウザとプラグインの問題と言えるので書いていませんでした。Web開発者としては早く直してほしい問題ですがサーバのコードを書く側としては対策をできません。なぜかこの話題の日本語リソースがあまり無いようです。とりあえず私のブログにも書いておくことにします。

WebブラウザとプラグインはSame Originポリシーで守られています。基本的にはXMLHttpRequest、Javaアプレット、Flashはそのコードを送ったサーバにのみリクエストが送信できるようになっています。クッキーもコードを送ったサーバ(ドメイン)のクッキーにのみアクセスできるようになっています。

Same Originポリシーが無いと悪意があるサイトにアクセスするだけでいくらでもクッキーに保存されたセッションIDなどを盗めます。これを防ぐ為にブラウザはDNS Pinning(IPアドレスを固定するセキュリティ対策)と呼ばれる手法を利用しています。

DNS Pinningが無いとファイアーウォールで保護されている内部のコンピュータにアクセスしたり、IPアドレスベースでの認証の回避が可能になります。DNS Pinningが無い場合にどのように攻撃されるか簡単に解説します。

DNS Pinningの必要性

ブラウザがURLを解釈する際、ホスト名をIPアドレスに変換するためにDNSサーバに問い合わせを行います。サーバ名はDNSによって管理されサーバのIPアドレスは必要に応じて自由に変更できるようになっています。

攻撃者がドメインを管理して、悪意があるDNSサーバを運用している場合、ブラウザからの最初の問い合わせには実際に存在する攻撃用のページをホストしているサーバのIPアドレス(通常のグローバルIPアドレス)を返します。

仮に攻撃用のURLは次のURLだとします。
http://www.example.jp/attack.html

被害者がURLにアクセスさせる攻撃用attack.htmlのコンテンツにはXMLHttpRequestを利用してwww.example.jpサーバにリクエストを送信するJavaScriptを記述します。ページが記述してあるwww.example.comとXMLHttpRequestの送信先であるサーバ(www.example.com)は同じサーバであるのでブラウザはアクセスを許可します。

DNS Pinningが無い場合、ブラウザはサーバ名を解決するためにDNSで再度名前の解決を行います。攻撃者がホストしている悪意のあるDNSサーバはwww.example.comの名前解決リクエストがきた場合は内部のIPアドレス、例えば192.168.0.1、192.168.0.2、192.168.0.3等を返させます。この様なDNSサーバを用意することにより攻撃者は簡単に本来アクセスできてはならない内部ネットワークのコンピュータにアクセス可能になります。

例えば、IPアドレスが192.168.0.1のコンピュータはSOHOルータでCSRFに脆弱な場合、Firewallを無効にしたり、VoIP対応ルータの場合通話を盗聴されたりVoIPサービスを不正利用される可能性があります。さらなる攻撃を行うために内部ネットワーク構成のスキャン等を行う事も可能になります。

この様にDNSによって名前の解決を毎回行っていると内部ネットワークへの不正アクセスを許してしまいます。これを防ぐためにブラウザやブラウザの拡張はDNS Pinning(DNSリクエストのキャッシング)を行います。同じサーバ名にリクエストを送信する場合、DNSによって名前の解決を行わず既に解決済みの結果を利用します。

このように解説すると、悪意のあるDNSサーバを用いた攻撃は明白で全ての実装が最初からこのような攻撃を考慮していたはず、と思われる方もいるかも知れません。しかし、実際にJava AppletがDNS Pinningを実装していなかったり、XMLHttpRequestオブジェクトがDNS Pinningを実装していかったりしたケースがありました。

攻撃例としてFirewall設定の変更やVoIPの不正利用を取り上げていますが、実際にAnti DNS Pinning/DNS Rebidingを利用したFirewall設定の改竄やVoIPの不正利用などの攻撃は行われています。

Anti DNS Pinning/DNS Rebinding

Anti DNS Pinningは名前が示すとおりDNS Pinningを回避する手法の名前です。Stanford大学の論文でより直感的に分かりやすい名前としてDNS Rebindingが利用されています。DNS RebidingはAnti DNS Pinningの別名と考えても差し支えありません。


書きかけです。近日中に再編集します。

IHクッキングヒータ電磁波の安全性

全く専門外ですが電磁波は目に見えないうえ安全性に疑問を思っているので興味を思っています。

WHOは、具体的な規制値は示さなかったものの、日本や米国などでの疫学調査から「常時平均0.3―0.4マイクロテスラ(テスラは磁界や磁石の強さを表す単位)以上の電磁波にさらされていると小児白血病の発症率が2倍になる」との研究結果を支持。「電磁波と健康被害の直接の因果関係は認められないが、関連は否定できず、予防的な対策が必要だ」と結論づけた。

思っていたより小さな値で「電磁波と健康被害の直接の因果関係は認められないが、関連は否定できず、予防的な対策が必要だ」としている報道はずっと気になっていました。この報道だけでは送電線で発生する50/60Hzの超低周波電磁波の影響なのか分かりませんが恐らく超低周波電磁波を対象にしていると思います。とにかくポイントは「予防」として「常時電磁波にばく露しない」ように注意した方が良いとしている所です。海外ではすでに幼稚園・保育園・小学校など高圧送電線の近くに設置しないようにしている国もあります。
# 日本は裁判になり保育園・小学校などを高圧線の付近に設置差し
# 止め請求行われていますがが認められたケース無いようです。

IHクッキングヒータの購入も検討しているので久し振りに調べてみる事にしました。結論から書くとちょっと調べたくらいではIHクッキングヒータが発生する電磁波の安全性・危険性について納得できる情報は見つかりませんでした。すでに購入済みで気になる場合は電磁波防止エプロンなどを着れば良いと思います。
# ただし、市販の電磁波防止グッズは信頼性に欠ける物も多いよう
# なので注意が必要。

電子レンジは2GHz以上(通常は2.45GHz)の超高周波で水や脂肪などがエネルギーを吸収して加熱します。IHクッキングヒータは鍋やフライパンに電流を流しその電気抵抗で加熱します。電流を発生させる周波数は20kHz、オールメタルでは60kHzから90kHzくらいまで利用しています。

検索するとIHクッキングヒータは「電子レンジの扉が開いているようなもの」と素人の私でもすぐに分かるような全く勘違いしているページが検索結果の上位に出てきたりします。いきなり調べる気力がなくなりそうになりましたが、気を取り直してもう少し有用なサイトが無いか調べると石川県消費生活支援センターのホームページに平成14年に行ったテスト結果が載っていました。

○ 携帯電話(15機種を測定)
携帯電話の近接(0㎝)の電磁界は0.1mG~1,400mGでした。
○ 電子レンジ(18機種を測定)
電子レンジ本体近接(0㎝)の電磁界は46.3~1,426mGの範囲にあり、200mGを超えたものは9機種でした。
○ パソコン(15機種を測定)
パソコン本体近接(0㎝)の電磁界は0.1~35mGにあり、30mGを超えたのは2機種でした。
○ テレビ(18機種を測定)
テレビ近接(0㎝)の電磁界は、2.3~111mGでした。
○ 電磁調理器(3機種を測定)
電磁調理器のIH盤1台を使用したときの盤上0㎝(鍋ぶた)の電磁界は144~328mGでした。IH盤2台を同時に使用したときは、1台を使用したときの1.6~2倍でした。鍋径の小さい不適小鍋を使用したときは、盤上0㎝で1,407mG、950mGでした。
○ ホットカーペット(4機種を測定)
ホットカーペット近接(0㎝)で217~233mGでした。
○ 電気毛布(1機種を測定)
電気毛布近接(0㎝)で251mGでした。
○ 電気あんか(1機種を測定)
電気あんか近接(0㎝)で65mGでした。

曖昧さ無くす為だと思いますが全て0cmでテストしています。単位がマイクロテスラでなくミリガウスですが変換は簡単で1ミリガウス=0.1マイクロテスラです。JEMAによるとIHクッキングヒータの場合30cm離して規定の大きさの鍋で計測するとなっています。
http://www.jema-net.or.jp/Japanese/kaden/ih/ih-08.htm

どのような計測器を使用したかも記載されていました。

電磁界テスター(3軸式低周波ガウスメーター、米国F.W.BELL社製)

とあったのでググると計測に利用したと思われる機種に最も近い機種は「7030型 ハイエンド3軸ガウスメータ」でした。

簡易型のガウスメータの購入も考えていたのでこれの仕様を見て本格的過ぎて驚きました。とても個人で買えるような代物ではない事は一目瞭然です。しかもウォームアップ時間もかなりのモノです。

ウォームアップ時間: 60 分

これだけの計測器なので、最近話題になっている超低周波の電磁波だけでなく計測可能な全周波数帯(URLの機種は50kHzまで)の合計値が掲載されているのだと思います。ここに掲載されている電磁調理器の電磁波の強さは

に掲載されている「ICNIRP(国際非電離放射線防護委員会)が発表している限度値」「60Hzで1000mG」「50Hzで833mG」の値に適合していると思われます。

電磁波の健康への影響は周波数、強さとばく露時間も問題ですが総務省の研究結

ではほとんどの調査結果は特にリスクの変化はなかったとしています。

普通のIHの場合は20kHzくらいを利用し、オールメタルの場合は60kHz~90kHzくらいまでを使うようです。このあたりの周波数の安全性研究はどうなっているのか気になる所です。

安全性以外には当然ですがIHだと中華料理は作りづらいと思います。以下のURL(ガス屋さんのURLなのである程度差し引いて受け止める必要あり)にも煮物は作りづらいと書いてあります。

IHの場合、掃除は簡単ですが料理がやりづらいのは仕方ないですね。

国際非電離放射線防護委員会(ICNIRP)の防護指針

に適合していれば、とりあえずはリスクは低いと考えても良いとは思います。

# 満員電車の中は携帯電話のおかげでこの基準値以上で危険かも、とか
# 地中に埋められている高圧線には基準(1万ボルト=1m)が適用されず
# 基準値オーバで危険かも、書かれたページもありました。携帯電話
# などの高周波はかなり研究されているので多少オーバしたくらいでは
# いきなり影響がでるような事はないと思います。

ところで発電所や電気工事など、長時間強い電磁波にばく露している方と一般の方の健康状態を比較すれば超低周波電磁波の影響が分かりやすそうに思えます。国際的な基準とされるICNIRPの防護指針でも仕事の場合は何倍もの電磁波ばく露も基準内となっています。素人考えなのかな?

個人的な問題としてIHを買うか?ですが購入の方向で検討します。

参考:

サーバシグニチャは隠すのが当たり前

私も何年も前からセミナーではサーバ、モジュールバージョンは隠すようにと言っています。何故こんな事で賛否両論になるのか全く理解できません。犯罪者がどのように攻撃するか?を考えればなぜ隠す必要があるのか理由は明白です。サーバのバージョン情報が詳しく公開されていれば、その情報を使うに決まっています。攻撃に使える情報は全て使わない訳がありません。

最新版を使っているから安全ではない事も明白です。サーバに0day攻撃の脆弱性が発見された場合どの情報を使います?公開または推測できるバージョン情報に決まっています。

フィンガープリンティングでかなりの確率で推測可能、という議論もあるとは思います。しかし、適切に運用/設定されているシステムなら細かいバージョン番号までは推測できない場合が多いと考えられます。

犯罪者が攻撃に利用している、利用する可能性が高いと分かっている情報を わざわざ広く一般に公開しない方が良いに決まっていると思います。

近所で空き巣が多発しているにも関わらず「ただいま留守です」「鍵もかかっていません」とわざわざ正直に張り紙をする人がいるでしょうか?

「家を留守にする前に戸締まりをしてから出かけましょう」というアドバイスに対して「窓ガラスを割れば..」「ピッキングをすれば…」と「留守の戸締まりはあまり意味ない」と反論しているような議論は必要ないと思います。

ネットバンキング被害が急増

ちょっと古いですが全銀協の資料によると、今年になってからネットバンキングの不正送金などの被害が急増しているようです。海外と比べると金額は少ないですが急増しているのは確かです。

http://www.zenginkyo.or.jp/news/19/index190823.html

普及率の問題もありますが言語の壁さえ乗り越えられれば日本のユーザは狙いやすいと思います。キャッシュカードや通帳などの物理的な物を必要とする不正送金被害とネットバンキングの被害金額が逆転するのは時間の問題でしょう。

BIND8もメンテナンス終了

また別のDNSキャッシュ汚染脆弱性が見つかったBIND8ですが、2007/8/27でメンテナンス終了と宣言しています。

ISC is announcing BIND 8 to be End of Life as of today, 27 August 2007.

ISC strongly encourages users who depend on BIND 8 to migrate to BIND 9 as soon as possible.

djbdnsを使っているので影響ないですがBIND8が残っているシステム管理者の方、ご苦労さまです…

どうせアップグレードするなら別のDNSサーバも検討してみるのも良いかも知れません。

DJBDNS
http://djbdns.qmail.jp/

PowerDNS
http://www.powerdns.com/

MaraDNS
http://www.maradns.org/

Name Server Deamon
http://www.nlnetlabs.nl/nsd/

dents
http://sourceforge.net/projects/dents/

pdnsd
http://www.phys.uu.nl/~rombouts/pdnsd/index.html

Dual DHCP DNS Server
http://sourceforge.net/projects/dhcp-dns-server/

Oak DNS Server
http://www.digitallumber.com/oak/

Zero Calorie DNS Server
http://www.datazygte.com/downloads.html

dnsjava
http://www.dnsjava.org/index.html

Posadis DNS Server
http://sourceforge.net/projects/posadis/

RB DNS
http://sourceforge.net/projects/rbdns/

JDNSS
http://sourceforge.net/projects/jdnss/

CustomDNS
http://sourceforge.net/projects/customdns/

MyDNS
http://sourceforge.net/projects/mydns/

探してみるとたくさんありますね。

バグが少ないブラウザがより安全とは限らない

Honeypotプロジェクトの調査の結果、興味深いというか、予想通りの結果になったようです。

Older versions of the three major browsers for Windows — Microsoft’s Internet Explorer 6 SP2, Mozilla’s Firefox 1.5.0, and Opera’s Opera 8.0.0 — were each used to browse the same subset, about 10 percent, of the sites. While researchers have disclosed about twice as many vulnerabilities for Firefox 1.5.0 as for Internet Explorer 6 SP2, the Honeynet Project found no attacks against the browser. Microsoft’s Web software, however, was compromised nearly 200 times.

攻撃する人も効率良く攻撃するためにシェアの多いのIEは200回攻撃されたにも関わらず、バグの多い古いFirefox、Operaは攻撃されなかったそうです。

The survey used a large list of 300,000 URLs belonging to about 150,000 hosts, finding that pornographic sites have the highest incidence — about 0.6 percent — of malicious sites, but that all categories included some sites that could lead to compromise.

これも予想どおりですがアダルトサイトが最もリスクが高いようです。しかし、全てのタイプのサイトから攻撃される可能性があるとしています。

A fully-patched version of Internet Explorer 6 visited 2,289 malicious sites, none of which managed to compromise the system.

2289の悪意のあるサイトは全てパッチ済みのIEに対して攻撃を成功させることはなかったそうです。

http://blogs.zdnet.com/security/?p=474

にはリモートコード実行脆弱性数のグラフが載っています。Firefoxが断トツです。