カテゴリー
Security

SquirrelMailのコードが改竄される

追記: 攻撃が目的の改竄だった模様です。
http://blog.ohgaki.net/index.php/yohgaki/2007/12/16/squirrelmail-1

—-

http://squirrelmail.org/index.php

によると、12/8にSquirrelMail 1.4.12のコードが改竄されていたようです。

While we believe the changes made should have little impact, we strongly recommend everybody that has downloaded the 1.4.12 package after the 8th December, to redownload the package.

The code modifications did not made it into our source control, just the final package. We are currently investigating older packages to see if they were also compromised.

攻撃用のコードは含まれていなかったようです。攻撃コードが含まれなかったのであれば、攻撃者は「パッケージを改竄してどの程度で改竄された事実が判明するかを検証する」等の目的を持っていたのだと思われます。

GNUのFTPサーバがクラックされた事例を思い出します。MD5などのシグニチャは必ずチェックするようにした方がよいのは当り前ですが、MD5やSHA1ハッシュの重要性を再認識してもらうにはよい機会かもしれません。

混乱を避けるためにSquirrelMail 1.4.13がリリースされています。
http://squirrelmail.org/download.php
新しいパッケージはGnuPGでもサインされています。

gpgでサインされた署名をチェックするには鍵を取得しなければなりません。gpg署名の確認方法を書いておきます。パッケージとそのパッケージに対応したgpg署名をダウンロードします。

[yohgaki@dev download]$ gpg –verify squirrelmail-1.4.13.tar.bz2.sig
gpg: 2007年12月15日 02時17分49秒 JSTにDSA鍵ID F8FD1F73で施された署名
gpg: 署名を検査できません: 公開鍵が見つかりません

鍵がないので署名が検証できません。鍵ID”F8FD1F73″で署名されているので取得します。

[yohgaki@dev download]$ gpg –keyserver pgp.nic.ad.jp –recv-key F8FD1F73
gpg: 鍵F8FD1F73をhkpからサーバーpgp.nic.ad.jpに要求
gpg: 鍵F8FD1F73: 公開鍵“Jonathan Angliss <jon @netdork.net>”を読み込みました
gpg: 最小の「ある程度の信用」3、最小の「全面的信用」1、classic信用モデル
gpg: 深さ: 0 有効性: 1 署名: 0 信用: 0-, 0q, 0n, 0m, 0f, 1u
gpg: 次回の信用データベース検査は、2009-02-05です
gpg: 処理数の合計: 1
gpg: 読込み: 1

この公開鍵を利用してもう一度チェックすると正しい署名であることが確認できます。

$ gpg –verify squirrelmail-1.4.13.tar.bz2.sig
gpg: 2007年12月15日 02時17分49秒 JSTにDSA鍵ID F8FD1F73で施された署名
gpg: “Jonathan Angliss <jon @netdork.net>”からの正しい署名
gpg: 別名“Valcor <valcor @netdork.net>”
gpg: 別名“Netdork Abuse <abuse @netdork.net>”
gpg: 別名“Netdork Sales <sales @netdork.net>”
gpg: 別名“Netdork Support <support @netdork.net>”
gpg: 別名“Jonathan Angliss <jon @squirrelmail.org>”
gpg: 別名“Netdork Security <security @netdork.net>”
gpg: 別名“Jonathan Angliss <jangliss @aaxchange.com>”
gpg: 警告: この鍵は信用できる署名で証明されていません!
gpg: この署名が所有者のものかどうかの検証手段がありません。
主鍵の指紋: 676A 1701 665B E343 E393 B8D2 2B83 E814 F8FD 1F73

警告が表示されているのは先ほど取得した公開鍵にサインしていないからです。「“Jonathan Angliss <jon @netdork.net>からの正しい署名」となっているので問題ありません。気になる場合は公開鍵を署名すれば警告メッセージは表示されなくなります。

公開鍵の署名は以下のリンクが参考になります。
http://homepage.mac.com/mio_rhapsody/gnupg/GnuPG_ShellScript.html#SignKey

カテゴリー
Security

WordPress Charset SQL Injection Vulnerability

http://www.securiteam.com/unixfocus/6N00D0AKKM.html

に解説されている脆弱性は基本中の基本です。

Most database query in WordPress uses escape() method to sanitize SQL string, which is essentially filtering input via addslashes() function. However addslashes() fails to consider character set used in SQL string, and blindly inserts backslash before any single quote, regardless of whether such backslashes will form another valid character or not.

addslashes()によるエスケープは行ってはならない、とよく言っていますがWordPressでさえaddslashes()を使っていたのですね。WordPressはUTF-8だけでなくGIB5とか使えるのですね。WordPressをSJISを使っている方は同じ脆弱性があるので要注意です。

本質的には私のブログでも指摘している脆弱性と同じ種類の問題です。

追記
CVEが出てます。
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6318

(1) Big5, (2) GBK, or possibly other character set encodings that support a “\” in a multibyte character.

BIG5, GBKエンコーディングが影響を受け他の文字に¥が現れる文字エンコーディングにも影響があると思われる、と書いてあります。つまりSJISが該当します。

対策を書いておきます。

  • データベースを正しい文字エンコーディングで作成する
  • アプリケーションからデータベースやクライアント文字エンコーディングを変更する場合、データベースのAPI(pg_client_encoding, mysql_set_charsetなど)を利用する(SQL文で変更しない)
  • 文字列をデータベースクエリ用にエスケープする場合はデータベースAPIを利用する(pg_escape_string, mysql_real_escape_stringなど)

別の対策として、プリペアードクエリを利用する方法もあります。

壊れた文字エンコーディングの文字列を無理矢理扱えるようにする方法があります。しかし、壊れた文字エンコーディングを扱えるようにするとアプリケーションや環境に存在する未知の脆弱性により攻撃可能になるかもしれないリスクがあります。壊れた文字エンコーディングを扱えるようにするのではなく、既にあるデータは綺麗にして、新しい文字データは全て正しい文字エンコーディングであるように入力時にバリデーションすべきです。

カテゴリー
Computer Database

MySQL5.0.51では不十分

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5968

によるとMySQL 5.1.23には脆弱性ありその概要は以下とされています。

Overview
MySQL 5.1.x before 5.1.23 might allow attackers to gain privileges via unspecified use of the BINLOG statement in conjunction with the binlog filename, which is interpreted as an absolute path by some components of the product, and as a relative path by other components.

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

Access Vector: Network exploitable
Access Complexity: Low
**NOTE: Access Complexity scored Low due to insufficient information
Authentication: Not required to exploit
Impact Type: Provides administrator access, Allows complete confidentiality, integrity, and availability violation , Allows unauthorized disclosure of information , Allows disruption of service

MySQL 5.0系の最新版は5.0.51ですが、これには上記の脆弱性の修正が含まれているか気になったので調べてみました。

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5969
これは同じ日付のMySQL 5.0.51のCVEエントリです。これにはBINLOGの脆弱性に関する記述がありませんでした。リリースノートのURLがあったので見てみましたが以下のリリースノートにの記述がありませんでした。(現時点で)

5.0.51のリリースノート
http://dev.mysql.com/doc/refman/5.0/en/releasenotes-cs-5-0-51.html

5.0.52のリリースノート(現時点では、Enterprise版のユーザしかダウンロード出来ない?)
http://dev.mysql.com/doc/refman/5.0/en/releasenotes-es-5-0-52.html

5.0.54のリリースノート(現時点ではまだダウンロード出来ない)
http://dev.mysql.com/doc/refman/5.0/en/releasenotes-es-5-0-54.html

5.0には影響ない?
5.0.51で修正?
5.0.52で修正?
5.0.54で修正?

どれなのかよく分かりません。分かったのはMySQLはコミュニティ版とエンタープライズ版でセキュリティパッチリリースを差別化している事です。5.0.52にもセキュリティフィックスが記載されています。つまり最新のコミュニティ版の5.0.51では不十分です。探せばダウンロードできるのか?アカウントを取ればダウンロードできるのか?いづれにせよどれが最新で安全なのか分かりづらいです。

リポジトリへのコミットを見ていればセキュリティパッチを見分けてインストールする事も可能ですが、とても一般向けとは言い難いです。

MySQL 6.0のバージョン管理にはBitKeeperを利用しているようです。5.1、5.0はsubversionのようなので今はまだよいですが、BitKeeperも障壁の一つになりそうです。リポジトリ自体にアクセスしてみよう、と思ったのですが少しググっただけではどこへアクセスすればよいのか分かりませんでした…

追記
しばらくしてからまた新しいMySQLのCVEが出ています。
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5970
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6303
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6304

新しい方は明確にかいてあるので古い方はどうなの?と思わなくてもよいようになっています。

カテゴリー
Linux

ext3の最大ファイルサイズは2TBでなく16GB?!

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

カテゴリー
Security

安全性について知っておくべき事

パスワードの解読にも『PS3』が活躍
http://wiredvision.jp/news/200711/2007113023.html

PS3で米大統領選の結果を「正確に」予知?…実はMD5脆弱性への問題提起
http://slashdot.jp/security/07/12/02/1931233.shtml

PS3は演算処理性能が高くFoldings@HomeのClient statistics by OSをみるとPCの値に比べおよそ26倍の性能した。

「パスワードの解読にも『PS3』が活躍」の記事では100倍の性能を達成とあります。この100倍が意味するのはランダムな文字列の難しいパスワードを解読するのに100年かかっていたのが1年で済む、1000時間かかっていたのが10時間で済む、と言うことです。時間的にクラッキングが実用的ではなかった物が十分実用的になったと言えます。

「PS3で米大統領選の結果を「正確に」予知?…実はMD5脆弱性への問題提起」はアルゴリズムとハードウェアの向上により、数年前から予測されていた「同じMD5値を生成する事は簡単になる」状態になったことが実証された事になります。

Microsoft等のソフトウェア会社大手では随分前にMD5の利用を止めています。SHA1が同様な状態になるまではまだまだ時間が必要ですが時間の問題となってきたのかも知れません。

ところで、Webシステムの中にはいまだにパスワードをプレインテキストで保存している所が多数あります。メールで「パスワード」を教えてくれる大手サイトも少なくありません。最低限、SHA1ハッシュでパスワードは保存しましょう… できればsalt付きで。

パスワードの最大文字数が少なすぎるサイトも稀に見かけます。パスワード文字列が少なすぎるサイトなら簡単にクラックされる可能性があります。256バイトくらいは入力できるようにしておいた方が良いでしょう。数年前の研究結果だったと思いますがその論文によると、文章になっている長い文字列のパスワードの場合、辞書に載っている単語ばかりを利用していても十分な強度持っているとされていました。