archiver/php5-zip (pcre.h: No such file or directory)

devel/php5-pcre (port directory error)の記事を書いてから早1年半以上たったところで思わぬ事態に遭遇。archiver/php5-zipのmake中に

In file included from /usr/ports/archivers/php5-zip/work/php-5.3.8/ext/zip/php_zip.c:30:
/usr/local/include/php/ext/pcre/php_pcre.h:29:18: error: pcre.h: No such file or directory

/usr/local/include/pcre.h はあるので、よく見ると -I/usr/local/include が無いです。configure がおかしかったことになるので config.m4 と config.log を見ると、 PHP_PCRE_DIR に /usr/local が指定されるところまでは正常、その後

をプリプロセッサに渡して出来上がりに yes があるかという条件判定で PHP_PCRE_REGEX=no になってしまっています。php/main/php_config.h は php/ext/php_config.h を読み込み、さらに php/ext/pcre/config.h を読んでいます。そこには #define COMPILE_DL_PCRE 1 の行が。というわけで1年半前のports/UPDATING の指示は微妙に作業が足りていないようです。/usr/local/php/ext/php_config.h に、必要の無い行がある場合は削除します(pcre spl以外は実際に存在していたか特に確認していません)。

間違いの無いようにファイルも

とでもしてリネームしておきます。最後に

あたりをしておけば安心です。ふぅ。/usr/ports/UPDATINGとしては1.5)を追加して

とでもなりましょうか。

RIP, dmr 1941-2011

すごい勢いでつぶやかれているようですが、まさにこの本(K&R)が世のプログラミング言語に与えた影響は計り知れず、彼がいなければ世のOSの状況も変わっていたし、それに広範囲に依存している世の中も大きく変わっていたと思います。鶯色のカバーのANSI C対応第2版の翻訳本は今でもきれいに本棚に並んでいますが、高校生のころ読んだ白いカバーの初版の翻訳本はぼろぼろです。

レセプトオンライン 7月分のレセプトデータが送れない

今まで長いことオンライン請求できていたのに2011年7月から急にレセプトデータの送信時にハングアップするようになったという方が増えているようですが、原因はInternet Explorer 9に対応できていない(webサイトが)ことのようです。(その後サイト側のIE9対応完了したようなので、この件に該当する方は既にいらっしゃらないと思います)




請求期限までに送らないといけないのであわてていらっしゃる方も多いと思います。Windows Vista, Windows 7, Windows Server 2008で以前はIE8以下だったけれども現在IE9がインストールされているという場合は更新をアンインストールして以前のIEに戻せば送信できるようになる可能性があります。アンインストールは Internet Explorer 9 をインストールまたはアンインストールする方法 の「Internet Explorer をアンインストールするには」以降(インストールの仕方の次の項です)に従えばできます。

レセプトオンライン用のPCでは、使用可能であることの確認ができるまではIE9をインストールしない、Windows UpdateでIE9を選択しない、あるいはIE9のインストールを開始する旨のダイアログが出た時点で「キャンセル」を押すなどの対応が必要です。

IE9のβが出てから大分たったような気がしますが、どんな時系列だったかを遡ってみると…

この辺が最近の主要なできごとのようです。Windows Updateで「重要な」ものを全部インストールするようにしている方は7月、能動的にIE9をインストールされた方は時期によって5月、6月でも問題に直面したことになります。動作環境ではないとはいえ非常に多くの人に生命線として利用されているものがいまだIE9で動作しない旨の表明が無い(2011/7/6現在)のが困りものですが、これだけ準備期間があったのにちょっと対応が遅いようです…

HylaFAXでの送受信速度を制限する

回線は大丈夫でもモデムがおかしかったりして強制的に送受信速度を制限したい場合は、HylaFAXのコマンド設定の先頭に!をつけるとその応答があったとみなす機能を使用します。

Class 1 FAXモデムの場合 ITU-T.31

送信 (ITU-T.31の8.3.3およびTable 6)

例えばログに

のように出ている場合で9600bit/sにしたい場合は、表を見ると121,122,145,146を削って設定ファイルに

と記載すればよいことになりそうですが、実際にはV.17のトレーニングが成功してしまうために14400bit/sでの通信が始まります。V.17でトレーニングさせないためには参照先の表をよく眺めてこの場合は73,74,97,98,121,122,145,146も削らなければならないのでした。

受信 (ITU-T.31の8.3.4およびTable 6)

同様に AT+FRM の応答ログと設定ファイルの Class1RMQueryCmd を使用します。

Class 2 FAXモデムの場合 ITU-T.32

ITU-T.32の8.5.1.1およびTable 21

同様に AT+FCC の応答ログと設定ファイルの Class2DCCQueryCmd を使用します。

Comodo affiliate RA was compromised

Comodoより重要サイトの証明書が不正な相手に発行されたという記事。RAはどこだったんでしょうか(参考1, 参考2)。ちょっと昔のnull-prefixの証明書の話とは異なります。

How to avoid fraudulent SSLでは、失効した証明書を

  • OCSPレスポンダが提供されていてOCSPをサポートしているクライアント使用でも
    • OCSPを有効にしていない
    • OCSPレスポンダの応答がタイムアウトした場合に有効な証明書とみなすようにしている

    場合に、クライアント側が有効な証明書とみなしてしまう

  • 大手ブラウザはそのような状況用にブラックリストを更新 ⇒ 最新にせよ
  • OCSPを有効にせよ、タイムアウト時に証明書を無効として扱うようにせよ
  • EV SSLを使用せよ(いきなりサーバ側の話)(現在CAはOCSPをサポートしないといけない 参照: EV SSL Certificate Guidelines 11.1.1)

などの、サーバ証明書を売る立場での説明があります。特に今回のような大きな問題の場合は、クライアントが検証用にCRLをダウンロードするタイミングよりOCSPレスポンダへの問い合わせのタイミングのほうが早い場合が多いのでしょう。

秘密鍵がポストされてしまったようなので、ブラックリストでの対応があるクライアントは最新にアップデート、OCSPに対応している場合はタイムアウトした場合も無効となることの確認が急がれます。

参考: MS01-017

Japan Earthquake: Possible scams / malware

Japan Earthquake: Possible scams / malware 詐欺、マルウェアを撒くメールが発生する可能性があるのでご注意をという記事 ⇒ その後各種発生しています。詐欺メールの内容は読むに耐えません。

Tsunami in Japan…既に検索エンジンに対するポイズニングが成功しているという記事。

国内でも善意につけこむ各種詐欺

CVE-2011-0411 Plaintext injection in STARTTLS

多くのSMTPクライアントはサーバ証明書を検証しない -> その場合そもそもMITMがいない確認ができていないので常にcommand injectionに脆弱な状態 -> だからこの問題は見た目より大きな問題ではない。という皮肉が効いてます…今時だとスマホアプリやIoT機器(こちらはそれなりの値段で買わないと手に入らないものが多いので比較的公開されてませんが、某社製のSSLスタックを積んでたりすると…)のサーバ証明書の検証不備の脆弱性がその状態ですね。

というわけでSTARTTLSからみでSMTP over TLS以外にもしばらく後続がありそうです。

入試問題リアルタイムQAサイト投稿問題対策?

金属探知機とか免許とって電波ジャマー導入とか技術的対策はされるでしょうが、ポイント制集合知サイトに限って言うならば、ポイント欲しさに検索して得た文章が適当に転記され、さらに悪いことに締め切ることができるのでいい加減な答えのまま締め切られてしまい修正もできない、という状態のものが少なくありません。正しいかどうかを見極める能力が必要である性質を利用すれば次のような対策が可能?

例えば英語の場合、大学側が英語のテストで赤点を取りまくるけど英語が大好きな生徒を集めます。あるいは人材派遣会社が英語が大好きだけど英語のテストではまったく点が取れない陽気な人を集めます(自分の場合、英語の点が取れない上に好きではないので答を書くことすらできない)。そしてどんな質問にも即答できるように簡単な講習を行います。正しい答えを書くのではなく、とにかくすばやくいい加減に回答する練習です。古きよき例を使うと「あなた方の基地は竹の子に占拠された」を即座に「ALL YOUR BASE ARE BELONG TO BAMBOO CHILDREN」と英訳できればOKです。そして試験当日QAサイトにへばりつかせてがんがん回答させます。これで自動的に容疑者は落第になります。おかしな回答であることで論文盗作チェッカーと同じような仕組みでのチェックも容易になるはずです。

とアホなことを書きましたが、今度はQAサイトから「偽計業務妨害罪」に問われちゃしゃれにならないし、そして何より本当に何か知りたかった人が巻き添えを食うことなので実行するわけにはいかないです。これからQAサイト側も自主的に入試時間中は新規質問受付停止とかするのかもしれませんが、なぜ公開サイトを利用したのかも不明ですし、いたちごっこなのでその方向での対策は無意味かもしれません。お後がよろしゅう。

しかし、結局ガラ携から直投稿ですか…たいした捜査もする必要もなかったということですね…

ハンドルネームという字面を頻繁に目にしたので久々に検索してみて見つけたこのページ「Handle Name は間違った英語か」とても面白く拝読しました。

自転車用リアチャイルドシートリコール問題

鉄製「自転車用リヤチャイルドシート」無償交換のお知らせを何気に見てから街を歩いていると、あることあること、そこらじゅうにあります。いや、まじで。それもそのはず〈ニュースリリース〉「鉄製 自転車用後席幼児座席(リヤチャイルドシート)」無償交換のお知らせ 〜リコール対象の拡大〜にあるだけで別ブランドもあわせて569,523台。自転車に人がいて止まっていたら、買ったチャリンコ屋で確認した方が良いかもと声をかけるようにしていますが、ぜんぜん知らなかったという人が結構多い感じです。検索してみると、安全には代えられないものの交換品が色も選べないという不満が多いようです。というわけで少しでも多くの人が知る助けになればとJFYIでした。

FreeBSD ACPI acpi_tz0: _CRT value is absurd, ignored (256.0C)

HP Compaq nx6320/CT Notebook PC(ノートPC)にFreeBSDをぶち込んだところ表題のメッセージが出続けます。absurdですか、そうですねハンダが溶けそうです。acpi(4) と SEE ALSO の acpi_thremal(4) が関係ありそうです。 hw.acpi.thermal.tz%d._CRT は致命的なのでシャットダウンする温度だそうな。上書きできると書いてありますが、実は一瞬できるように見えるだけですぐにもとの値に戻るようです。 hw.acpi.thermal.polling_rate を 0 にしてポーリングを止めてしまうという荒技だと猛暑のときに機械が壊れそうなので、こちらacpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) FIX?のようにしてみます。

中身を眺めると、 ThermalZone (TZ0) の中が記事で参照しているところと同様のようです。単位は0.1Kのようなので、90℃=363.15K=3631.5*0.1K を返すようにしてみます。

これを元に

あとはハンドブックの通りに /boot/loader.conf に以下を追加。

リブートして表題のメッセージは止まりました。よかったよかった。

PivotXを利用されている方は最新版にアップデートするべし (was: PivotXを利用されている方は2.2.5以降へアップデートするべし CVE-2011-1035)

2011/10/8追記: WordPress TimThumb RFI Vulnerability used as Botnet Recruitment Vectorにあるようなurlがquery string上で目立つTimThumbを狙ったアクセスを頻繁に観測していますが、PivotXも2.3.0のリリースノートでさりげなく書いてあるように本体がTimThumbを搭載しています。常にリリース状況を確認して最新にされることをお勧めします。なおこの問題に脆弱なPivotXのfingerprintingも、多くのケースでそうであるようにヘッダも含めてバージョン表示を消したところで即時に可能です。

2011/2/19追記: CVE-2011-1035, Vulnerability Note VU#175068


2011/2/14: PivotX 2.2.4がリリースされても告知が無く、SourceForgeにもリリースのアーカイブファイルがアップロードされないのでどうなっているのか見てたところ、フォーラムで開発チームからいくつか発言が出てきました。

2.2.4は緊急セキュリティ修正、そしてまもなく2.2.4での修正による悪影響を修正した2.2.5が出てくるそうです2011/2/17早朝に2.2.5リリースされました。SourceForgeにも置かれています。実際に攻撃があったことが複数報告されています。開発チームは詳細の公開を望んでいないようですが、結構誰でもすぐにわかってしまうかも…というかそもそも攻撃が現在進行形であるようなので可及的速やかに2.2.4、そしてリリースされ次第2.2.5以降にアップデートする必要があることになります。 http://pivotx.net/ の下の方にある最新情報を軒並み注意しておくとよろしいかと思います。アップデートだけではなく images/ と pivotx/templates/ を含むすべてのフォルダにmalwareが置かれていないことも要確認です。必要の無いファイルがある場合はダッシュボードに注意をうながすメッセージが出るようですが、出ないからと安心してしまわないようにしたいものです。全員のユーザ名が予測困難なものであることの確認とパスワードの変更を検討された方がよろしいかもしれません。

直接この問題とは関係無く、admin,system,pivotxなどの容易なユーザ名や、簡単にblogエントリから推測できるようなユーザ名は使用しないことを周知するとよろしいです。またCSRFはかわせないですがscript kiddieによる外部からのpivotx/index.phpへの直接攻撃には、例えばApache HTTPDで10.1.2.128/25,192.168.0.0/16からしかログインできないようにして良い状況でサーバ設定ファイルが変更できるのであれば

さらに403では無くてリダイレクトさせるには追加で

.htaccessしか使えない場合はyourblogdir/pivotx/.htaccessファイルを作成して

(yourblogdirはそれぞれの環境に合わせて)程度の制限をしておいても良いかもしれません。くどいようですがCSRFはこれでは防げません。pivotx/index.phpを利用した直接攻撃だけに対する限定的な緩和策で、基本は常に最新版へのアップデートです。

なおこの問題に脆弱なPivotXのfingerprintingは、多くのケースでそうであるようにヘッダも含めてバージョン表示を消そうとも即時に可能です。


2011/2/22:

から、google.com.tr の検索語 “inurl:jp pivotx” のSERPがReferer:の攻撃を観測しましたよ。

2011/2/17早朝:2.2.5がリリースされてSourceForgeにも置かれました。

2011/2/16朝:pivotx.netさきほど復活しました。

2011/2/15現在:pivotx.netがある共有サーバがダウンしてSourceForgeでも2.2.4以降のリリースとしてのアーカイブは入手方法がありませんが、SVNにコミットされたリリース前版は入手可能です:

  • http://sourceforge.net/projects/pivot-weblog/develop
  • http://web.archive.org/web/20160416045740/http://book.pivotx.net/page/1-2 trunk は現在2.3pre-alphaだそうなので、2.2系利用中の方は2.2.xのbranchが良いかと思います。SVN無しでもSorceForgeのレポジトリからのtar機能も一応使えます。リリース前なのでバージョン表記の変更が入ってませんが、 svn co した場合は pivotx/lib.php の $Rev$ が 3505 以降になっているはずです。なおリリースのアーカイブに含まれるextentionsは別途取得となります。gettextの.poファイルはPixotXの実行時に必要ありません。
    • svn co https://pivot-weblog.svn.sourceforge.net/svnroot/pivot-weblog/branches/2.2.x 2.2.x
    • http://pivot-weblog.svn.sourceforge.net/viewvc/pivot-weblog/branches/2.2.x/

浮動少数問題 Java版 CVE-2010-4476

どっかで見たことのある数字のような気がしますが(表記されている1個の値だけではなく範囲になります。DoS仕掛けてくれちゃってる人検出用シグナチャを作る方はこちらやそこから参照されているOpenJDKのBTSですがこちらを。少数をパースする場面って何気に多いですね)。さっそくfp87な機械のEclipseにコピペして自動的に文法チェックされた日にはそのままEclipseハングするので半べそです。2011/2/15に(日本では15日深夜にJava SE 6 Update 24登場しました)6u24が出るまではJava SE Floating Point Updater Toolでしのぎましょうということなので管理者権限でunzipしたjarを実行したら、一生懸命ランタイムライブラリをばらかしてからアーカイブし直してるようでした。インストール先の空き容量がぎりぎりな人はちょっと注意かも。

IPv4無くなりました

枯渇時計を表示させていた方はお気づきのことでしょうが、IANAから通常の分配が終了し、Two /8s allocated to APNIC from IANA【速報】IANAからAPNICへ、二つの/8ブロックが割り振られました によると近日中に最後の/8の5ブロックを5つのRIRに割り振って完全終了になるそうです。v4.fullbogons.cymru.com は今年から来年にかけて bogons.cymru.com との違いがほとんどなくなるはずです。(Bogons vs. Fullbogons – what’s that all about?) とはいえまだあるっちゃあるわけですが…

2011/4/16 追記:APNICにも通常割り振りの在庫が無くなったそうです。

2011/2/5 参考追加

DNSSEC始めました

ルートからJPへのチェイン。弊社が利用しているドメイン(co.jp jp ch me es be dk com net org…)もすべてDNSSECおよびDANE/TLSA対応完了。DNSSECが有効でTLSA RR,CAA RRにも対応したセカンダリDNSサーバ,DANE,TLSA,DMARC,DKIM,SPFに関するご相談は弊社へどうぞ。と宣伝をしたところで以下は設定を確認するためのリンク集と自分で確認する手順。

続きを読む

タイムゾーンのオフセット+09:18:59 はて、18:59はなんぞや?

いろいろ検索したつもりでしたが、実は :18:59 timezone と検索することで先人の方々のサイトがヒットし、Google先生がいれば誰でも天才ということで表題の件は簡単に速攻で解決できたことがわかりました。しかしせっかく書いたので恥ずかしながら公開しておきます…

続きを読む