yohgaki's blog

http://blog.ohgaki.net/2008-1

でご紹介したオープンソースとインターネットをテーマにした無料セミナーの件です。いよいよ明日（6/28）になりました。好評の為座席が足りない事が確実となりました。会場となる会議室を大きな会議室に変更しました。

旧：66会議室（30名）
新：61会議室（144名）

ご興味をお持ちの方はサンポート高松ホール棟6階の61会議室にお越しください。12:30頃から開場致します。

懇親会も飛び入り参加可能です。是非、ご参加ください。

PostgreSQLカンファレンス2008が今週金曜日(6/6)に開催されます。

http://www.postgresql.jp/events/postgresql-conference-2008

例年通り参加費が必要ですが懇親会費込みです。

参加費：
カンファレンス ならび に懇親会 4,000 円
チュートリアルも含むカンファレンス ならびに 懇親会 10,000 円

今回のカンファレンスの目玉は色々ありますが、その一つはチュートリアルセッションです。まだ、空席が残っているようなのでライセンスもBSDでMySQLよりも使いやすいPostgreSQLを始めてみたい方には良いチャンスだと思います。新人研修の一環としても良いと思います。

* MySQLユーザのためのPostgreSQL入門
（リナックスアカデミー 学校長 濱野 賢一朗 氏）

興味がある方は是非カンファレンスにお越し下さい。

OCamlはプログラミングコンテストで優勝するチームや開発者御用達の言語であることは以前から知っていましたが、個人的に利用しようと思ったありませんでした。しかし、最近関数型言語の人気が非常に高まってきています。関数型言語の簡潔なコードや副作用の少ないコードの生産性が認められてきたからだと思います。

OCamlを勉強しようかと思いましたが、AmazonでちょうどF#の本（英語版）が昨年末出版されている事を見つけて購入しました。

Read more »

OpenTechPressにLinux/Apache系Webサイトを狙った正体不明の攻撃についての現状報告と気になる記事があります。

この攻撃ですが、結構話題になっていて私のブログでも先日FTPとCPanelユーザはクラッキングに注意が必要と題したエントリを公開しています。OpenTechPressの記事中にもcPanelの件は紹介されていますが、非常に気になる記述がある

問題のルートキットを検出する方法ないし、感染の確認されたサーバの洗浄法についてアドバイスが得られないかをApache Software Foundationに問い合わせてみたが、Apacheのセキュリティ対策チームに属するMark Cox氏から得られたのは、「現状で攻撃者側がサーバ群のルートアクセスを得た方法の詳細はつかみ切れていませんが、同時にApache HTTP Serverに潜む脆弱性に起因していることを示す証拠も得られていません」という回答である。

Linuxサーバにルートキットがインストールされるらしい。そしてその確認方法は

感染後は数字で始まるディレクトリの新規作成が行えなくなるとされている（例えば「mkdir 1」など）。

としています。ルートキットなのでps uaxなどとしてもプロセスリストには出てこないはずです。本当にmkdir 1でファイルが作れないなら試してみるのも良いかもしれません。ただし、mkdir 1でファイルが作れないのはルートキットのバグと考えられるます。最新版では修正済かもしれません。記事に紹介されているようにパケットをモニタリングする方法の方が確実でしょう。

rootのパスワードを推測した可能性が高いと記載されていますが本当のところはどうなのか気になります。

この攻撃のすごいところは、その手法がかなり洗練されている点です。

How a Rootkit works
1. Once the Rootkit is successfully installed, the server will sit idle until rebooted. During a server reboot, the system initialization scripts will call the infected binaries.
2. When executed, the infected binary packages use /dev/mem as a pathway to the Kernel, and then attach to several system calls within the running Kernel. This results in hidden files, broken binary packages, and random JavaScript code being seen by web visitors.
3. When the system is fully online in an infected state, the Kernel will begin serving a JavaScript payload to random web requests/visits. This occurs outside of Apache and will not be seen in any of the Apache logs. The JavaScript injection will look like:
<script language='JavaScript' type='text/JavaScript' src='cbolw.js'></script>

http://servertune.com/kbase/entry/258/

ApacheやPHPなどのWebアプリケーションレベルで攻撃用のJavaScriptを送信しているのではなく、ルートキットがインストールされたカーネルから送信している、としています。

アプリケーションレベルはもちろん、Apacheのログにも残らず、不審なファイル/プロセスも見えないこの攻撃はかなりの脅威です。

Flash Playerに深刻な脆弱性（簡単に他所のサイトのアカウントが乗っ取れる脆弱性と他の脆弱性）がありアップデートがリリースされています。

悪意のあるSWFファイルを読み込ませることによって脆弱性を悪用することができ、攻撃が成功すればシステムを乗っ取ることも可能だという。

http://internet.watch.impress.co.jp/cda/news/2007/12/20/17964.html

ここまでしか読まなければかなり控えめな表現であることが分かります。後半の方まで読むとエンジニアであれば理解できる書き方になっています。

Flash Playerにはクロスドメインポリシーファイルの扱いに関する脆弱性が存在しているという。その結果、細工を施されたWebページによって、サイトのクロスドメインポリシーが迂回される可能性があり、サイト管理者の意図に反してデータがアクセスされる可能性があるとしている。このほか、任意のHTTP ヘッダが送信可能な脆弱性も存在するという。

あまり素人向けの解説とは言えないかも知れません。Watchなのでこれでも良いのかも知れませんが。

Securiteamの記事は最初の方に重要な事が書いてあるので分かりやすいです。

This vulnerability allows remote attackers to run arbitrary JavaScript code in the security context of other domains,

http://www.securiteam.com/securitynews/6E00L00KKC.html

Universal Cross Site Scriptingと呼ばれるタイプの非常に危険な脆弱性です。別の言い方をすると他所のドメインのクッキーを自由に盗める脆弱性です。悪意のあるフラッシュを実行するとログイン状態にあるサイトのアカウントを乗っ取られる可能性があります。

しかもこの脆弱性の攻撃は非常に簡単です。元ネタのStanford大のページ、Securiteamのサイトには攻撃方法が記載されています。

Exploit:
package {
  import flash.display.Sprite;
  import flash.net.*;
  import flash.utils.*;

  public class uxssdemo extends Sprite {
    public function uxssdemo() {
      setTimeout(DoAttack, 1000);
    }

    public function DoAttack():void {
      var request:URLRequest =
          new URLRequest('javascript:alert("Cookie: "+document.cookie+"\\n\\nContent: \\n\\n" + document.lastChild.innerHTML);window.close();');
      navigateToURL(request, 'tg');
    }
  }
}

Flashをよく知らない人でも簡単に攻撃できます。もしまだアップグレードしていない方は即刻Flash Playerをアップグレードした方がよいです。

Adobeのセキュリティ情報
http://www.adobe.com/support/security/bulletins/apsb07-20.html

Flashのダウンロードページ
http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash

Flashのバージョンチェック
http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_15507

前のエントリで改竄は大きなセキュリティ上の問題ではない旨説明がされている、と紹介しましたが新リリースのアナウンス部分に新しい情報が追加されていました。

http://www.squirrelmail.org/index.php

Due to the package compromise of 1.4.11, and 1.4.12, we are forced to release 1.4.13 to ensure no confusions. While initial review didn't uncover a need for concern, several proof of concepts show that the package alterations introduce a high risk security issue, allowing remote inclusion of files. These changes would allow a remote user the ability to execute exploit code on a victim machine, without any user interaction on the victim's server. This could grant the attacker the ability to deploy further code on the victim's server.

リモートファイルインクルードが可能になっていたらしいです。1.4.11は9月末にリリースされたパッケージなのでかなりの期間、危険なパッケージが公開されていた可能性があります。

利用されている方はバージョンアップしておいた方がよいと思います。また影響範囲が分からないので新しいバージョンがリリースされた場合に直ぐにアップデートできるよう準備する方がよいでしょう。

SquirrelMailのサイトでは前のニュースで影響が少ないとしていた部分は、追記として危険な問題がある事を明記しておかないと勘違いするユーザも少なからず発生するような気がします...

24GBのファイルをコピーしようとしてエラーになり??な話です。大きなファイルを使いそうなファイルシステムにはXFSを利用していたので気が付きませんでした。

sshfsでマウント先のファイルシステムにコピーしようとしたら16GBでエラー、クラッシュした為と思いますが勝手にumountされました。sshfsの制限かな?とscpにしても同じ、4GBにsplitしてコピー後にcatしても16GBちょうどでエラーなのでググるとKernel 2.4の制限が出てきました。

http://www.ussg.iu.edu/hypermail/linux/kernel/0403.3/1673.html

Depends upon the block size.

Block size file size
1 kb 16 GB
2 kb 256 GB
4 kb 2048 GB
8 kb 2048 GB

2.4カーネルのこの制限はそのまま2.6カーネルのext3にも引き継がれているいたようです。
# 追記を参照

古いe2fsprogsの場合、mkfs -t ext3で作られるデフォルトのファイルシステムのブロックサイズは1KBなので最大ファイルサイズはたったの16GBになります。

"ext3 filesize"くらいでヒットしても良さそうですが出てきませんでした。"ext3 16gb filesize"でやっと適切な検索結果になりました。やはり大きなファイルを使う場合はXFSですね。

他のキーワードでも試してみました。

• エラーメッセージだけ： "ファイルサイズ制限を超過しました" ext3の制限は出てこない
• エラーメッセージとファイルサイズ: "ファイルサイズ制限を超過しました" 16GB ext3の制限はでてこない

もう少し検索してみると「"ファイルサイズ" 16GB linux」でやっとKernel 2.4の翻訳に当たりました。

私もXFSだったので困ることは今まで無かったですし、皆さんも16GBの壁にはあまり困っていないのかな??

追記：
smbdさんに教えてもらった有用なリンク：

• ファイルシステム諸元
• ext3 諸元拡大に関する研究開発動向、及び改造方式の検討
  http://lc.linux.or.jp/paper/lc2006/CP-09.pdf

後のPDFにおもしろい事が書いてあります。PDFに記載されているext3の最大ファイルサイズの拡張は2.6.17-rc1で取り込まれ

ブロックサイズ： 4KB 最大ファイルサイズ: 4TB
ブロックサイズ：64KB 最大ファイルサイズ: 256TB

まで拡張されている、としています。ということはこのエントリのタイトルは「ext3の最大ファイルサイズは256TBでなく16GB?!」になるのかも知れません。それとも、ブロックサイズ128KBとかできる?

追記2:
最近のe2fsprogsはデフォルトのブロックサイズは4096byteになっています。320GBのSATA HDD 2本でRAID1にしていた/dev/md0の全体がext3でフォーマットされていたので最近フォーマットされた、と思っていたのですがブロックサイズが1024byteであった事を考えるとkernel 2.4くらいのシステムでフォーマットされていたパーティションだとと思います。3年か4年前くらいに購入したテスト用のPowerEdge800なので何度かOSを入れ替えているのですが/dev/md0は相当古い(?)linuxでフォーマットしたか、mkfs.ext3のデフォルト値が小さいシステムでフォーマットしたのだと思います。

気になたのでいつ頃から4KBブロックサイズがデフォルトになったか調べてみました。
Fedoraのe2fsprogsパッケージのChangeLogによるとS/390とzSeriesは2002年に4KBブロックサイズがデフォルトになったようです。

* Mon Jun 17 2002 Karsten Hopp <karsten @redhat.de>
- set default blocksize for mke2fs on S/390 and zSeries to 4096

ソースを見た方が正確なのでe2fsprogs-1.39のdoc/libext2fs.texinfoによるとまだ1KBがext2のデフォルトだと書いてあります。（ext3の記述は見つからず、ただext3はext2+ジャーナルの構造なのでブロックサイズなどは同じだと思います）

lesystem. Valid values are 0 (1024 bytes), 1
(2048 bytes), or 2 (4096 bytes). The default blocksize is 1024 bytes.

どうもtexinfoファイルはアップデートされていないようなのでコードの方を見てみました。
misc/mke2fs.cがmkfs.ext2, mkfs.ext3のコードでe2fsprogs-1.39のソースだと1221行目にデフォルト値が設定されています。

} else {
retry:
retval = ext2fs_get_device_size(device_name,
EXT2_BLOCK_SIZE(&fs_param),
&dev_size);
if ((retval == EFBIG) &&
(blocksize == 0) &&
(fs_param.s_log_block_size == 0)) {
fs_param.s_log_block_size = 2;
blocksize = 4096;
goto retry;
}
}

git-annotateによると"2005-01-27 19:07:26"にデフォルトブロックサイズの行が変更された事になっています。

20953129 (Theodore Ts'o 2005-01-27 19:07:26 -0500 1244) blocksize = 4096;

# これはe2fsprogsの開発版なのでデフォルト値を設定している
# 行が1.39と異なっています。

最近のシステムであれば4KBブロックサイズがデフォルトだと思います。この為、4TB(システムによっては2TB)が最大ファイルサイズになるのでext2/ext3の最大ファイルサイズは4TBと考えて問題ないと思います。

mke2fs.confをサポートしているe2fsprogsの場合（ほとんどのlinuxはサポートしていると思いますが）/etc/mke2fs.confでもデフォルトのブロックサイズを設定/参照できます。

[defaults]
base_features = sparse_super,filetype,resize_inode,dir_index
blocksize = 4096
inode_ratio = 8192

[fs_types]
small = {
blocksize = 1024
inode_ratio = 4096
}
floppy = {
blocksize = 1024
}
news = {
inode_ratio = 4096
}
largefile = {
inode_ratio = 1048576
}
largefile4 = {
inode_ratio = 4194304
}

最近のext3ファイルシステムはディレクトリエントリでB-Tree検索をサポートしています。mkfs.ext3のコマンドのオプションで指定してもよいですが/etc/mke2fs.confに記述してもよいです

もし、ブロックサイズが分からないまたは気になる場合は

dumpe2fs /dev/sda1 | less

等とするとブロックサイズを確認できます。

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

coMomongaのパーティションは3GBで小さく手狭になってきたのでパーティションを大きくしようと思い調べてみました。

coLinuxのパーティションサイズを変更するにはTopoResizeが利用できるようです。このツールを使ってディスクイメージも作成できるようです。折角TopoResizeがあるので試してみる事にしよう、と思ったらリンク先にないですね。

他にも既に作成済みのディスクイメージをダウンロードしてしまうと言うお手軽な方法もあるようです。

空のイメージ　http://gniarf.nerim.net/colinux/blank/
スワップ　　　http://gniarf.nerim.net/colinux/swap/
ext3　　　　　http://gniarf.nerim.net/colinux/fs/

追加するだけならこれらのファイルを使用するのが一番簡単と思います。

Linuxを持っている方なら

dd if=/dev/zero of=colinux.img bs=1024 count=1G
mkfs.ext3 colinux.img

等としてもイメージが作成できそうです。odで最初の方のダンプしてかるーく最初方だけ見ただけなので実際には試していませんが。特別なデータは書いてなさそうだったので多分大丈夫でしょう。TopoResizeの様にext2/ext3パーティションの拡張等もLinuxにイメージを持ってきて普通にリサイズすれば出来そうです。

TopoResizeがあれば試してみたかったのですが仕方が無いのでLinux上で拡張してみる事にしました。

参考
http://wiki.colinux.org/cgi-bin/ColinuxImageTools

PCを乗っ取れる脆弱性がある、とされていたAdobe Reader/Acrobatですがパッチがリリースされた模様です。

Adobe Acrobat
http://www.adobe.com/support/downloads/product.jsp?product=1&platform=Windows

Adobe Reader
http://www.adobe.com/support/downloads/product.jsp?product=10&platform=Windows

• Close a potential security vulnerability on Windows® XP computers that have Internet Explorer 7 installed (CVE-2007-5020); see the Adobe Security Bulletin (APSB07-18) concerning this issue
• Address several PDF forms-related issues
• Provide additional stability

APSB07-18

Critical vulnerabilities have been identified in Adobe Reader and Acrobat that could allow an attacker who successfully exploits these vulnerabilities to take control of the affected system. This issue only affects customers on Windows XP with Internet Explorer 7 installed. A malicious file must be loaded in Adobe Reader or Acrobat by the end user for an attacker to exploit these vulnerabilities. It is recommended that affected users update to Adobe Reader 8.1.1 or Acrobat 8.1.1. This is an update to resolve the issue previously reported in Security Advisory APSA07-04.

重要な箇所はWindows XPでIE7を利用しているシステムのみ影響するとしている部分です。VistaユーザやXP+IE6なら影響ないとされています。
# RedHatによるとRHELなどのLinux環境にも影響が無いとされています。

CVSS2.0のスコアを見てわかるように非常に危険なセキュリティ上の問題とされています。

CVE-2007-5020

CVSS Severity (version 2.0):
CVSS v2 Base score: 9.3 (High) (AV:N/AC:M/Au:N/C:C/I:C/A:C) (legend)
Impact Subscore: 10.0
Exploitability Subscore: 8.6

とりあえずハンドラの問題を回避する方法は
http://isc.sans.org/diary.html?storyid=3477

既知の問題が全部直っているのかな?と思ったら根本的な原因は以下
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3896
にあるような感じです。

ところでRealPlayerをインストールしている方は少ないと思いますが、0day攻撃されているようです。ほとんど必要ない物なのでアンインストールしておきましょう。

追記：
ZDNetによるとこの脆弱性を利用しWindowsファイアーウォールを無効にする攻撃がSymantecにより観測されている、と記載されていました。パッチが必要なシステムは早めにパッチを適用した方が良いと思います。

Canon iP7500をMomongaLinuxから利用するには

http://www.canon-sales.co.jp/drv-upd/bj/bjlinux260.html

に掲載されているフィルタをインストールしてCUPSのプリンタ設定ページからドライバを選択すれば利用できるようになります。

バイナリrpmを入れても良いのですが、以前にうまく動作しなかった事があるのでSRPMからインストールすることにします。

このcnijfilter-commonはlibxml（obsoleteなパッケージです）が必要なので、どこかから適当なSRPMを拾ってきます。rpmbuildコマンドでビルドするとlibtoolでエラーが発生するので/usr/sbin/libtoolで上書きします。書き換えていれば問題無くビルドできました。

次にcnijfilterのビルドですが、まずcups-devel, gtk+1-develをインストールしておきます。他にも必要な開発用パッケージがあるかもしれません。必要な物はインストールします。

%installセクションの

install -c -s -m 755 ${PR_ID}/database/* ${RPM_BUILD_ROOT}%{_libdir}/bjlib

の-sオプションを削除します。ライブラリでもないファイルに-s(stripオプション)が付いているのでエラーになります。後はrpmbuildでビルドして出来上がったrpmを全部インストールします。

CUPSは再起動しないと新しいドライバを読み込まないので再起動します。その後、プリンタメーカでCanonを選択するとcnijfilterがサポートするプリンタ（Canon PIXUS iP4200 / PIXUS iP6600D / PIXUS iP7500 / PIXUS MP500)が一覧に表示されるようになります。

サポートディストリビューションはSUSE Linux 10.0、Turbolinux FUJIとなっていますが同じ手順でFedoraなどにもインストールできると思います。ここにRedHat系のOSが載っていないのはサポート負荷軽減の為?と勘ぐりたくなります。Libxml2を使うように書き換えればもっと簡単に多くのディストリビューションで使えるようになると思います。

Canonのページを見るとUSBからの接続しかできないような記述になっていますがネットワークプリンタとして接続できればLPDでもIPPでも印刷できます。

MomongaLinux3以来のインストールでしたが以前よりインストールが簡単になっていました。以前はインストール済みのライブラリ（確かlibpngとか）を強制的に別バージョンに見せてインストールしたと思うのですが今回はそのような荒技を使わなくても普通にインストール出来ました。

Mac OSXにはiP7500用のドライバがあるのですがこのドライバはMacのUSBポートに直接iP7500が刺さっていないと動作しない代物です。OSXもCUPSを使っています。CUPSのフィルタならOSXでも使えるはずなので余裕があるときにインストールしてみたいと思います。

追記：
とりあえずビルドした物を公開しました。よろしければどうぞ。
http://wiki.ohgaki.net/index.php?Momonga%20Linux%2FCanon%20Printer