unzip: ZIP decompression failed (-3) unzip fails to extract password protected archive

パスワードつきzipのunzipで表題のようなエラーが出るときがあります。

which unzip するとわかりますが、今時の FreeBSD は /usr/bin/ に unzip がいて、これは archivers/unzip の ports から /usr/local/bin/ にインストールされる Info-ZIP の unzip とは別物です。というわけで

/usr/local/bin/ を指定してめでたしめでたし。

チップのバックドア

2012/5/29 18:00現在、gigazine で bingる と、顔を見るだけで判断できてしまう… ギガジン、恐ろしい…のようなSERPになっているのは私だけでしょうか。

GIGAZINE 20120529

原発や軍事用に使われている中国製シリコンチップにサイバー攻撃可能な未知のバックドアが発見される – GIGAZINE の元ネタとなっているケンブリッジ大のページLatest news on my Hardware Security Research – Sergei Skorobogatov(HTTPS Everywhereを入れている人はcam.ac.ukをはずしておかないとエラーになります 2012/5/29) や、もっと昔のだよーと書かれている Copy Protection in Modern Microcontrollers でのくらっとくる色で警告など、いずれにせよ、古いdraftなabstractをRedditに晒されたからという理由で急いでいろいろ付け加えられているようです。その後RedditはFalse news story: No Chinese backdoor in military chip「ホームルータの20%(最近もWAN側にあるのがあった!)、工業制御用の50%のコンピュータでバックドアあるし~(数字の根拠は???)、中国が源なの?そもそも軍事用チップじゃないじゃん」という趣旨のblogで盛り上がったようです。このbloggerが付け加えているように、だからといってバックドアが有るチップを軍事用に使っちゃ良いことにはならないですね。

元文の一番下に並んでいる良く見るような型番もあるリストはごく一部で、多くのマイクロコントローラ、スマートカード、セキュアメモリチップ、FPGAは脆弱だそうです(PSoCはその頃手に入らなかったのだろうか、それともこの手法ではみつからないということなのだろうか、単に載せなかっただけなのか、時系列やターゲットが整理されていないので良くわからない)….どういう展開を見せるのか、連休明けの Microsemi Corporation 界隈で何かを狙っているなんてことはないですよね。

追記: その後も

とか、この分野は実験環境を作るハードルが高めなので面白ネタの宝庫ですね。

関係ないですがきゃりーぱみゅぱみゅと耐タンパ性って微妙に似てる?

HTTP status code 416 (Chrome)

HTTPサーバのログにはステータスコード416を返していることが結構あったりするようです。Rangeヘッダは先ごろApache Killerで有名な問題がありましたが、特にDoSしようとしているわけでもなく普通のリクエスト。共通項は

  • Chrome (新旧問わず 6.0.472.63, 15.0.874.121, 17.0.963.56, …)
  • GET対象のサイズが6で割り切れる(リクエストは複数ですが対象は高々3つだけなのでたぶんたまたま)。

くらいしか見当たりません。ただし新しめのChromeでは416の直後に再度GETして正常取得しているので、何らかの対症療法が施されているように見えます。https://code.google.com/p/chromium/issues/detail?id=68298によれば13で修正されているようですがregressionでしょうか、はたまた別件でしょうか。Range, If-*ヘッダをログ、ChromeからのRangeはunsetして様子を見ることにします。

誤検知: cmdproxy.exe Trojan.Win32.Siscos.ipv

新しい機械をセットアップするといろいろ起きて楽しいです。WindowsでもGNU Emacsでちゃちゃちゃっと便利に済ませたいときがよくあるのでNTEmacs 23.3をぶち込んだところ、Vulnerability Scanが便利なKasperskyさんが表題の警告を表示。variant部分が3文字です。Trojan.Win32.Siscos.ipvは最近追加された亜種、詳細説明無し。Trojan.Win32.SiscosのNumber of resultsは6453だそうで。データを盗むということのようですがdetached署名でも確認してあり VirusTotalで2/43、しかも片方はsuspiciousなので誤検知ということで良さそうです。(最近出たemacs-23.4-bin-i386.zipの方は署名に使われているkey ID 0x597F9E69(0x587DE7C6597F9E69)な公開鍵がGNUの公開鍵一覧にもメジャーなキーサーバにも存在していないのでFSFに鍵無いと連絡だけしてとりあえず放置してありますが、こちらのcmdproxy.exeはどうだったんでしょうね)

シェルを呼び出してまでWindowsでEmacsを使うこともないのでさくっとquarantineしてくれちゃって良いのですが、一応困る人がいるかもしれないのでunbel32以来久々のfalse detectionの報告をしたところ、「ごめん、誤検知。次で直すね。ありがとー!(超訳)」とのお返事。

問題イベント名: BEX

http://technet.microsoft.com/en-us/library/cc738483(v=WS.10).aspx によれば a buffer overflow or DEP exception だそうな。ってことは例外は全部 ?EX なのか、例外は最大で26個までなのか、はたまた36個までなのか、特別例外とかいう「イベント」があったらまずくないのか、などなどBOFとでも書いておいてくれればいだくはずもない素朴な疑問はおいておいて、バイナリが正しい配布のものであることを確認して、複数のアンチウィルスでも確認、さらに可能であればそれがDEPに対応できていないことを確認した後にわざわざその実行ファイルでのDEPを無効にし、実行完了後に戻すことにします。

今回はWindows用JREインストーラ実行開始直後

JREインストーラのハッシュはどこにも見当たらないのでインストーラ本体のデジタル署名を隅々まで確認。もっともらしそう。「オンラインで解決策を確認してプログラムを終了します」をクリックすると無言のまま終了。何も無いことを確認してくれたんですね。

このインストーラに対してDEPくらい対応してよという声も複数見つかるので、では半べそですがインストーラのDEPを無効にします。 EMET があれば簡単です。’Configure System’ボタンを押し、DEP を ‘Always On’ から ‘Application Opt Out’ に格下げ。’Configure Apps’ボタンを押して jre-6uxx-windows-xxx.exe を追加、DEPのチェックをはずし、OSごとリブート。インストーラを実行してインストール完了後に’Configure Apps’で追加したものを削除して、DEPを’Always On’に戻して完了。

老舗ダウンロードサイトが勝手に独自インストーラでラップ

今年の8月よりCNETの老舗ダウンロードサイト Download.com が広告対象のソフト(ツールバー)の独自インストーラでオリジナルのインストーラをラップするという暴挙に出ているというFyodorさんの怒りの記事です…ちょっと前は広告対象をインストールしないと目的のソフトがインストールできないようになっていた(VLC)とか、お子様用のソフト(Kea Coloring Book)もとか、上塗りで何かとまずいですね…

追記: SourceForgeもやらかしました

複数経路で入手したハッシュ値での確認の必要性を再認識させられます。

国ごとのIPアドレスの範囲 – RIR stats -> 各国のIPv4とIPv6のCIDR

ありがちな作業なのでそのものずばりなツールはごまんとありそうですが、極力先人の知恵を組み合わせて手抜きしながらIPv6対応のものを自力生成してみます。net-mgmt/p5-Net-IPが超便利です。最近はaggregateされたものは置いてないようなので aggregate-cidr-addresses を使います。NANOG MLのメールのとおりにIPv6の場合はprefix()をprint()に変更します。

上を hoge.pl とでもして保存。先ほどの aggregate-cidr-addresses もその名前のままダウンロードして、最後の

の部分を

に置き換えます。日本のサイダーであればfetchなりwgetなりを使って

お気楽日本のサイダー jp のできあがり。全部のRIR statsは以下のとおり。

頻繁にRIRにftpしないように良い子はちゃんとftpしたファイルを保存します。あとRIR dbはただの登録情報なので、実際に設置されている国と異なったりanycastだったりする場合も多いので、もう少し精度良く場所を知りたい場合はGeoIPなどの他、looking glass, traceroute, whoisなどを使って推察していくことになります。

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

CVE-2011-0411 Plaintext injection in STARTTLS

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

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

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/