GnuCitizenとばしてますね。先日はPDFによるコード実行脆弱性を公開（ただし、詳細不明）していました。その前はQuickTimeでした。今度はGmailの脆弱性だそうです。
The technique used in this example is known as Cross-site request forgery, or simply put CSRF.
CSRF脆弱性だったそうです。リンク先のページではフィルタ設定を改竄するスクリーンショットが掲載されていました。
対策は簡単、予測不可能なリクエストIDを全てのデータ変更リクエストにつけるだけです。手っ取り早いのはセッションIDを流用する方法ですが、セッションID漏洩のリスクが増加するのであまりお勧めできません。次に簡単なのはセッション変数としてIDを保存する方法です。この方法を採用したのかな?POSTメソッドなので単純にセッションIDを利用したのかな?
追記：
中身は同じなのかも知れませんが、XSS(?)でも似たような攻撃ができたようです。
PHP 5.3のブランチが出来ています。
個人用のアプリケーションなら、「Release fast, release early」でも良いと思いますが、フレームワークに近い言語が「Release fast, release early」だと困る方も多いと思います。互換性を維持しないアップグレードは1年に一回以内、出来れば18ヶ月か24ヶ月サイクルくらいに留めた方が良いと思います。
モジュールを別途配布するようにすればかなり現実的になるのですけどね…
PHP Core, PHP Standard, PECL, 3rd party, 程度に分けて管理すれば良いと思います。
とにかく、準備が必要な方はテストで使ってみては？
http://cvs.php.net/viewvc.cgi/php-src/?pathrev=PHP_5_3
少し前にPythonの画像処理デフォルトモジュールの脆弱性について書きました。「普通はデフォルトのライブラリは使わずにImageMagickとかを使うよね」というツッコミが入っていたので、画像ライブラリは脆弱性が多いことも紹介していたのですが、そのImageMagickに脆弱性です。DoS, Off by One, Integer overflowです。
http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=596
http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=595
http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=594
影響する画像形式は一般的な画像形式でないので、あまり影響は大きくないのです。最近ImageMagickなどは脆弱性が多い、と書いていたので載せました。
Linuxパワーユーザには当たり前の情報が多いですが、IDFでlesswatts.orgがお披露目となったようです。
と同じ情報が掲載されているものが多いようです。
LinuxをノートPCで利用する場合に少しでも長くバッテリを利用する為のTipsが掲載されています。サーバの消費電力軽減にも役立つTipsもあります。Intelチップ専用のTipsもありますが、Intel以外でも使えるTipsもあります。Kernelやコマンドがサポートしていないと利用できない機能もあります。
サイトの掲載されているTIPS：
echo 1 > /sys/devices/system/cpu/sched_mc_power_savings
hdparm -B 1 -S 12 /dev/sda
-B set Advanced Power Management setting (1-255)
-S set standby (spindown) timeout
-y put IDE drive in standby mode
-Y put IDE drive to sleep
-Z disable Seagate auto-powersaving mode
echo 5 > /proc/sys/vm/laptop_mode
hal-disable-polling –device /dev/scd0
デスクトップでもCD/DVDを挿入した場合に操作を選択するダイアログを表示されない為に利用すると便利。
ethtool -s eth0 wol d
ethtool -s eth0 autoneg off speed 100
1000Mbpsに戻すには最後のパラーメータを1000にしてethtoolを実行。
iwpriv eth1 set_power 5
省電源機能を無効にするには最後のパラメータを6にして実行。
rmmod ipw2200
modprobe ipw2200 associate=0
WiFiアクセスポイントを一生懸命探さなくなる。
for i in `find /sys -name “rf_kill” ; do echo 1 > $i ; done
有効にするには
for i in `find /sys -name “rf_kill” ; do echo 0 > $i ; done
hciconfig hci0 down
rmmod hci_usb
xbacklight -set 50
xset +dpms
120秒のアイドルで電源OFF
xset dpms 0 0 120
xrandr –output TMDS –off
mount -o remount,relatime /
atimeの様にアクセス時間の記録をsyncしない（直ぐにatimeをアップデートしない）のでディスクの利用が効率化する。デスクトップでもお勧め。
echo 1 > /sys/module/snd_ac97_codec/parameters/power_save
echo 1 > /dev/dsp
cat /sys/module/snd_hda_intel/parameters/power_save
0より大きな数値で有効化されている。
* Processor C1E support: This enables maximum power saving of the processor when idle.
* Enhanced Speedstep (EIST): This allows Linux to optimally reduce the frequency and voltage of the processor when not using the maximum capacity.
* Fan control: Set to “auto speed”; this allows the fans to slow down (and use less power) when the temperatures in the machine allow this.
* Enable the HPET (often called “Multimedia timer”) option. This allows Linux with tickless idle to maximally save power by being idle longer.
BIOS設定はハードウェア管理機能が不明なデバイスとして認識しないよう、一部の省電源機能を無効化しています。上記の機能を有効化すると消費電力が少なくなります。
AdobeはAdobe Readerのブラウザプラグインは止めるべきだと思います。PDFがブラウザから見れてもうれしい事は少なく、反対に迷惑な場合が多いです。Firefoxの人気拡張にPDF Downloadがある事からも私だけでなく、多くの方が迷惑だと思っていると考えられます。せめてプラグインのインストールはデフォルトでオプションにして、欲しい人だけインストールできるようにするべきです。
Adobe Readerですが、どうもPDFからシステム上のファイルを簡単に覗き見できる、ということらしいです。
[Full-disclosure] 0day: PDF pwns Windows
http://www.gnucitizen.org/blog/0day-pdf-pwns-windows
I am closing the season with the following HIGH Risk vulnerability:
Adobe Acrobat/Reader PDF documents can be used to compromise your
Windows box. Completely!!! Invisibly and unwillingly!!! All it takes
is to open a PDF document or stumble across a page which embeds one.
元ネタのGnuCitizenサイトにアクセスできないので具体的な攻撃方法は不明。
http://blog.ohgaki.net/index.php/yohgaki/2007/09/14/noscripta_rafia_a_s
に書いたようにNoScriptで全てのプラグインはデフォルトで実行しない設定にしている方が安全だと思います。
攻撃方法が詳細が分からないので、何とも言えませんが、Adobe ReaderからPDFを読み出してもファイルを読んで、外部に送れるような問題であれば防ぐのは難しいです。少なくともプラグインを禁止していれば「ページを見て攻撃される」リスクはかなり軽減すると思います。
追記
GNUCitizenにアクセスできたのでみてみると
My advise for you is not to open any PDF files (locally or remotely)
と、「ローカルでもリモートでも、PDFファイルは開くな」と記載されています。アタックベクタが不明なので、対処方法は安全性が保証できるPDF以外は開かないのが良いと思います。少なくとも、ブラウザプラグインでクリックしたら開いた、という状況は良くないと思います。
実は少し前に流行っていたPDFファイル付きスパムメールのPDFを自分で開いた事がないです。これにファイルを盗み見れる攻撃が仕込まれていたとすると脅威ですね。
PDFプラグインの実行はNoScriptでも制御できます。
詳しくは
http://blog.ohgaki.net/index.php/yohgaki/2007/09/14/noscripta_rafia_a_s
PHPのモジュールには脆弱なコードが多かったが、PHPのモジュールに限らないはず、と言っていましたがまた別の例がありました。
Full-Disclosure（9/16）に投稿されたメッセージによると
The module imageop contains a lots of int overflow, which result in heap overflow, and maybe memory dump.
The files imageop.c and rbgimgmodule.c are examples.
という状態らしいです。モジュール（ライブラリ）は叩けば埃が沢山出てくると思います。
imageopのコードフラグメントを見ると整数オーバーフローに全く注意していないコードになっているのは明らかです。
「標準モジュールでimageopなんてモジュールだれも使ってないよ。ImageMagickなど使っている」と反論がありましたが
Maybe the real question is, if they don’t know how secure an int overflow in imageop module, maybe other modules are vulns too.
と、投稿者は書いています。確かにその通りだと思います。
で、ImageMagickですが今は以前に比べてあまり脆弱性が報告されなくなりましたが少し前まで脆弱性が山ほどレポートされていました。最近レポートされている脆弱性もあります。
http://osvdb.org/searchdb.php?action=search_title&vuln_title=ImageMagick&Search=Search
http://secunia.com/search/?search=ImageMagick
裏を返せば古いバージョンを使っていて脆弱なシステムも意外と多いかも?と思ってしまいます。これはPythonに限った事ではありません。
画像、映像、音声処理ライブラリは脆弱性の固まりだと思っていた方が良いです。
コマンドを呼び出していれば他の言語と同じ、速度や使うリソースの問題がありますが、Javaはこの点に関してかなり有利だと思います。
Second Lifeは使ったことが無いので知らなかったのですが、IEを拡張してsecondlife://プロトコルを追加しているのですね。このプロトコルハンドラが脆弱でユーザIDを盗める脆弱性があるそうです。
Second Life is configured to handle ’secondlife://’ protocol urls. Internet Explorer, and browsers based on Internet Explorer, copy all information from a src or href attribute to launch the SecondLife application. Using this, a malicious website can specify an iframe or anchor tag which redirects login through a server not under Linden Lab control.
現在のところ修正中らしいです。
You can remove the association for the secondlife:// protocol until we release a fixed client by deleting the registry entry.
Second Lifeを利用している方は上記に記載されているようにWindowsレジストリを削除した方が良いと思います。
NoScriptのIE版があればiframeも禁止できるのですけどね。
PHPにもプロトコルハンドラを簡単に追加できるのですが、ハンドラの開発者がセキュリティ対策を行っていないと穴だらけになってしまいます。IEの場合も事情は一緒なのかも知れません。
プロトコルハンドラを拡張しているアプリ（主にネットワークゲーム?）には注意が必要なのかも知れません。
Flashも同じような事ができるので、JavaScript（XMLHttpRequest)でもできるようにしてしまおう、という規格…
This restriction on “read” access to web resources is very strict and generally appropriate. However, there are scenarios where an application would like to “read” data from another resource on the web without these restrictions and in these scenarios the browser’s default “security sandbox” has to be extended or eased.
つまり「Same Originポリシー」を緩くする規格です。
使い方は簡単
Content-Access-Control: allow <*.example.org> exclude <*.public.example.org>
Content-Access-Control: allow <webmaster.public.example.org>Means that every subdomain of example.org can access the resource including webmaster.public.example.org, but with the exclusion of all other subdomains of public.example.org.
Content-Access-Control: allow <example.org> <*.example.org>
Means that example.org and all its subdomains can access the resource.
です。選択的にアクセス可能なドメインをContent-Access-Controlヘッダで処理できる、という訳です。
セキュリティ的には「Same Originポリシー」を緩くするのはリスクが高くなる事を意味します。Webセキュリティの根幹である「Same Originポリシー」はどちらにしてもブラウザとプラグイン任せなので、少し緩くしても同じ、という考えなのでしょう。
XMLHttpRequestのプロキシは必要なくなります。確かに作り易くはなりますが必要なのか考えさせられます。
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.dllAnd 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とか、維持したくなかったのかな?
Firefoxユーザなら必ずインストールして使用する事をお勧めするのがNoScript拡張です。
参考：新しい紹介文を書きました。
NoScriptはデフォルトでJavaScriptの実行を拒否します。これだけでもかなり安全にWebサイトを参照できるようになります。しかし、NoScriptはプラグインの実行も拒否できるようになっています。Java, Firefox, Silverlight,その他全ての拡張を選択して実行を拒否できます。残念ながらJava, Sliverlight以外はデフォルトで実行可能に設定されています。
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よりコストパフォーマンスが良かったりして。
ITProの「昨日のLinuxランキング」で他の完全インストールガイドを抑え、MomongaLinux 4が第一位でした。
「先週のLinuxランキングでもMomongaLinuxの記事が一位！
プロジェクトメンバとして最近全然なにもしてないですが、うれしかったのでスクリーンショットを撮っておきました :)
私のビルド環境はコンパイル用のPCがNFSマウントされているsubversionレポジトリのチェックアウトを参照するように設定されています。NFSなのでflockを利用するにはnfslockdが必要です。NFSサーバがMo3の時はNFS Lock問題は発生しなかったのですが、NFSサーバをMo4にしたらOmoiKondaraを実行中に何故かflockできなくなりRubyライブラリの中でエラーが発生するように…
面倒なのでスルー力を活かしてライブラリのflockを省略、これでビルドできる、と思ったら今度はeachでエラー
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
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攻撃を行う方法も考えられます。この場合、攻撃に成功する確率はかなり高くなると思います。