FreeBSD.org intrusion announced November 17th 2012 だそうです。
- FreeBSD developerからSSHの鍵(秘密鍵ですね。こらこら)が漏れた。
- 2012/9/19から2012/11/11までにpackageではなくてports treeからインストールされたものは完全性が保証できない。
あたりが重要項目でしょうか。
FreeBSD.org intrusion announced November 17th 2012 だそうです。
あたりが重要項目でしょうか。
パスワードつきzipのunzipで表題のようなエラーが出るときがあります。
1 2 3 4 5 6 7 |
> zip -e hoge.zip hoge.txt > unzip -v hoge.zip Archive: hoge.zip Length Method Size Ratio Date Time CRC-32 Name -------- ------ ------- ----- ---- ---- ------ ---- 0 Stored 0 0% 06-13-12 21:09 00000000 hoge.txt unzip: ZIP decompression failed (-3) |
which unzip するとわかりますが、今時の FreeBSD は /usr/bin/ に unzip がいて、これは archivers/unzip の ports から /usr/local/bin/ にインストールされる Info-ZIP の unzip とは別物です。というわけで
1 2 3 4 5 6 7 |
> /usr/local/bin/unzip -v hoge.zip Archive: hoge.zip Length Method Size Cmpr Date Time CRC-32 Name -------- ------ ------- ---- ---------- ----- -------- ---- 40960 Defl:N 8288 80% 06-13-2012 21:09 342c5fc6 hoge.txt -------- ------- --- ------- 40960 8288 80% 1 file |
/usr/local/bin/ を指定してめでたしめでたし。
2012/5/29 18:00現在、gigazine で bingる と、顔を見るだけで判断できてしまう… ギガジン、恐ろしい…のようなSERPになっているのは私だけでしょうか。
原発や軍事用に使われている中国製シリコンチップにサイバー攻撃可能な未知のバックドアが発見される – 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 界隈で何かを狙っているなんてことはないですよね。
追記: その後も
とか、この分野は実験環境を作るハードルが高めなので面白ネタの宝庫ですね。
関係ないですがきゃりーぱみゅぱみゅと耐タンパ性って微妙に似てる?
弊社の製品「アポ助」のクライアントはFlashアプリケーションで、ActionScriptを駆使して作られています。 直感的で誰でもすぐに使える画面が好評なのですが、その直感的な操作を実現するために、その時の状態に応じて入力フィールドやチェックボックスなどを動的に生成してレイアウトしています。
ところが、このように動的にコンポーネントを生成してレイアウトするアプリケーションの場合、入力コンポーネントにUIComponentの子クラスを使うとやっかいなことになることがあります。
アポ助はクリニック用の予約管理システムなので、患者様のお名前を入力するフィールドや、診察の種類を選ぶボタンがあり、以下の画像が正しい姿です。
ご覧のように、文字やフィールドなどがきれいに整列して見易くなっています。以下が使用しているクラスです。
テキスト部分: flash.text.TextField
入力フィールド:fl.controls.TextInput
診察の種類:fl.controls.RadioButton/fl.controls.CheckBox
(fl.controlsのコンポーネントは、fl.controls.UIComponentの子クラスです。)
ところが、特定の条件において、これが次のように表示されることがあります。
一目瞭然ですが、フィールドのサイズ設定が反映されずに枠からはみ出ていますし、ラジオボタンやチェックボックスに、肝心のボタンが表示されていません。この問題はUIComponentの描画のタイミングに起因するようです。
この問題はUIComponentのdrawNow()メソッドを呼ぶことで回避できます。つまり、描画のタイミングを明示的に指示する形です。TextInputのwidthやheightの設定が反映されなかったり、チェックボックスが表示されない時などに、試してみてください。
HTTPサーバのログにはステータスコード416を返していることが結構あったりするようです。Rangeヘッダは先ごろApache Killerで有名な問題がありましたが、特にDoSしようとしているわけでもなく普通のリクエスト。共通項は
くらいしか見当たりません。ただし新しめのChromeでは416の直後に再度GETして正常取得しているので、何らかの対症療法が施されているように見えます。https://code.google.com/p/chromium/issues/detail?id=68298によれば13で修正されているようですがregressionでしょうか、はたまた別件でしょうか。Range, If-*ヘッダをログ、ChromeからのRangeはunsetして様子を見ることにします。
新しい機械をセットアップするといろいろ起きて楽しいです。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の報告をしたところ、「ごめん、誤検知。次で直すね。ありがとー!(超訳)」とのお返事。
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インストーラ実行開始直後
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
Java(TM) Platform SE binary は動作を停止しました ... 問題の署名: 問題イベント名: BEX アプリケーション名: jre-6u31-windows-i586.exe アプリケーションのバージョン: 6.0.310.5 アプリケーションのタイムスタンプ: 4f2ce2fa 障害モジュールの名前: StackHash_6718 障害モジュールのバージョン: 0.0.0.0 障害モジュールのタイムスタンプ: 00000000 例外オフセット: 046898a0 例外コード: c0000005 例外データ: 00000008 OS バージョン: 6.1.7601.2.1.0.256.48 ロケール ID: 1041 追加情報 1: 6718 追加情報 2: 6718520661a5809bd4bc4af70234b126 追加情報 3: 2b9a 追加情報 4: 2b9a6b667e74ecf8b9265e65579805bf |
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’に戻して完了。
ありがちな作業なのでそのものずばりなツールはごまんとありそうですが、極力先人の知恵を組み合わせて手抜きしながらIPv6対応のものを自力生成してみます。net-mgmt/p5-Net-IPが超便利です。最近はaggregateされたものは置いてないようなので aggregate-cidr-addresses を使います。NANOG MLのメールのとおりにIPv6の場合はprefix()をprint()に変更します。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
#!/usr/bin/perl # -*- mode: cperl; coding: iso-8859-1; tab-width: 8 -*- use Net::IP; use strict; my $cc = 0 > $#ARGV ? 'JP' : $ARGV[0]; foreach (<stdin>) { chomp; if ($_ =~ /\|$cc\|ipv([46])\|([^\|]+)\|(\d+)\|/) { if (4 == $1) { my $ip = new Net::IP ("$2 + " . ("$3" - 1)) || die ('argument for Net::IP'); foreach ($ip->find_prefixes ()) { print "$_\n"; } } else { print "$2/$3\n"; } } } close (AGR); # end of file |
上を hoge.pl とでもして保存。先ほどの aggregate-cidr-addresses もその名前のままダウンロードして、最後の
1 2 3 |
foreach (@addrs) { print $_->prefix(), "\n"; } |
の部分を
1 2 3 4 5 |
foreach (@addrs) { if ($_) { print 6 eq $_->version ? $_->print() : $_->prefix(), "\n"; } } |
に置き換えます。日本のサイダーであればfetchなりwgetなりを使って
1 2 |
fetch 'ftp://ftp.apnic.net/pub/stats/apnic/delegated-apnic-latest' perl hoge.pl JP <delegated-apnic-latest | perl aggregate-cidr-addresses >jp |
お気楽日本のサイダー jp のできあがり。全部のRIR statsは以下のとおり。
1 2 3 4 5 |
ftp://ftp.apnic.net/pub/stats/apnic/ ftp://ftp.lacnic.net/pub/stats/lacnic/ ftp://ftp.ripe.net/pub/stats/ripencc/ ftp://ftp.arin.net/pub/stats/arin/ ftp://ftp.afrinic.net/stats/afrinic/ |
頻繁にRIRにftpしないように良い子はちゃんとftpしたファイルを保存します。あとRIR dbはただの登録情報なので、実際に設置されている国と異なったりanycastだったりする場合も多いので、もう少し精度良く場所を知りたい場合はGeoIPなどの他、looking glass, traceroute, whoisなどを使って推察していくことになります。
devel/php5-pcre (port directory error)の記事を書いてから早1年半以上たったところで思わぬ事態に遭遇。archiver/php5-zipのmake中に
/usr/local/include/pcre.h はあるので、よく見ると -I/usr/local/include が無いです。configure がおかしかったことになるので config.m4 と config.log を見ると、 PHP_PCRE_DIR に /usr/local が指定されるところまでは正常、その後
1 2 3 4 |
#include <main/php_config.h> #if defined(HAVE_PCRE) && !defined(COMPILE_DL_PCRE) yes #endif |
をプリプロセッサに渡して出来上がりに 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以外は実際に存在していたか特に確認していません)。
1 2 3 |
# cd /usr/local/include/php/ext # cp -p php_config.h php_config.h.prev # fgrep -v -e ext/pcre/ -e ext/spl/ -e ext/dbase/ -e ext/ncurses/ -e ext/ming/ -e ext/mhash/ php_config.h.prev > php_config.h |
間違いの無いようにファイルも
1 2 3 |
# /bin/sh # for p in pcre spl dbase ncurses ming mhash; do [ -f "$p/config.h" ] && mv -v "$p/config.h" "$p/config.h.prev"; done # exit |
とでもしてリネームしておきます。最後に
1 |
# portupgrade -fr lang/php5 |
あたりをしておけば安心です。ふぅ。/usr/ports/UPDATINGとしては1.5)を追加して
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
20100409: AFFECTS: users of lang/php5 AUTHOR: [email protected] As of PHP 5.3, a few extensions were removed from or included into the core PHP5 package. Follow the steps below to update your installation. 1) Delete the following packages (if installed): - php5-dbase - php5-ncurses - php5-pcre - php5-spl - php5-ming - php5-mhash Keep package names in the output of this commend, # pkg_info -R php5-dbase php5-ncurses php5-pcre php5-spl php5-ming php5-mhash Delete them, # pkg_deinstall -f php5-dbase php5-ncurses php5-pcre php5-spl php5-ming php5-mhash 1.5) Remove unused files (if installed): # cd PREFIX/include/php/ext # cp -p php_config.h php_config.h.prev # fgrep -v -e ext/pcre/ -e ext/spl/ -e ext/dbase/ -e ext/ncurses/ -e ext/ming/ -e ext/mhash/ php_config.h.prev > php_config.h # for p in pcre spl dbase ncurses ming mhash; do [ -f "$p/config.h" ] && mv -v "$p/config.h" "$p/config.h.prev"; done 2) Rebuild lang/php5 and all ports that depend on it. # portupgrade -fr lang/php5 # portupgrade -f [packaged names checked on step 1)] |
とでもなりましょうか。
ひとつのSpriteの上に、大小様々ないくつものSpriteを乗せました。 そのSpriteはA4の紙よりも大きいため、印刷する際には複数のページに分けないといけません。 ActionScriptで一つのSpriteを例えば2ページに分けて印刷するには、PrintJob.addPage()を2回呼び、それぞれの第2パラメータに、1回目ならnew Rectangle(0, 0, <ページ幅>, <ページ高さ>)を渡し、2回目ならnew Rectangle(0, <ページ高さ>, <ページ幅>, <ページ高さ>)を渡します。このように、各ページにSpriteのどの部分を印刷するかを指定します。
ActionScriptのコンパイル時やランタイムの日本語のエラーメッセージはなかなかどうして手ごわくて、暗号なんじゃないかと思えてくる時があります。
正しく解釈できるようになるには経験値が必要ですが、全てのエンジニアがその経験をすぐに積めるわけではないですし、試行錯誤を繰り返してこそ経験値が増えるのに、その試行錯誤の副産物であるエラーメッセージの解釈に経験値が必要だなんて、鶏が先か卵が先か。しかも分かり辛いエラーほど、そのエラーの文言とはまったく無関係の初歩的なケアレスミスによって発生するものが多いのです。
この記事には、そんな、ActionScriptのコンパイルエラーを解読…ではなく解釈するための経験値の素を継続的に追加していきます。
まず最初に、これから特定のメッセージが発生した際のいくつかの考えられる原因を説明しますが、そのメッセージの原因が必ずここに説明してあるものであるとは限らないので、注意してください。同じメッセージで複数の原因がある場合があるので、ここに説明してあるものは、あくまでそれらのうちの一つとして参考にしてください。
右括弧がコロンの前に必要です、と言っているわけですが、そんなことない時でも出ます。
関数の定義の際にfunctionのキーワードを書き忘れた場合。直前までJavaでコーディングをしていると、よく出会います。
誤: private isOk(strTest:String):Boolean {
正: private function isOk(strTest:String):Boolean {
定義を使用できません、って何か使用しているつもりはないのだけど…と混乱しがちなメッセージです。
これは、クラス変数を定義するつもりが、public class….で始まるクラス定義の外に変数の定義文を書いてしまうとこれが出ます。もちろん、賢いIDEを使っていればこのようなことは起きません。
または、「protected 属性はクラスプロパティの定義でのみ使用できます。」
「そうですよね」と答えたくなるメッセージですが、このエラーがある日突然起き始めることがあります。それまでは大丈夫だったのに。
これは、にょろ括弧{}の不一致です。このエラーが起きた場所から遡って行って、{}を含むfunction定義を見つけて、目を皿のようにして{}を見ましょう。多分if文やループ文など、どこかのブロックが閉じていないか、もしくは余計な}があるか、というところです。
「式xをArrayとして使用」って、もう、文章が完全に崩壊しています。某アインシュタインの伝記の翻訳本ぐらい支離滅裂です。
この文章は、「Array(x)と書くとnew Array(x)という意味になっちゃうよ」と注意してくれているのです。さらに、「キャストしたければArray(x)ではなく、(x as Array)を使いましょう」(Arrayのキャストにはas演算子を使う)と正しい方法を教えてくれているのです。親切にもメッセージが正しい方法を教えてくれる稀有なケースであるにも関わらず、残念な翻訳でもったいないことになっていますね。
この記事は、正しい解釈が必要なメッセージに遭遇したら今後も引き続き更新します。
今まで長いことオンライン請求できていたのに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のコマンド設定の先頭に!をつけるとその応答があったとみなす機能を使用します。
例えばログに
1 2 |
Jan 18 10:13:33 FaxGetty[1194]: <-- [9:AT+FTM=?\r] Jan 18 10:13:33 FaxGetty[1194]: --> [41:3,24,48,72,73,74,96,97,98,121,122,145,146] |
のように出ている場合で9600bit/sにしたい場合は、表を見ると121,122,145,146を削って設定ファイルに
1 |
Class1TMQueryCmd: "!3,24,48,72,73,74,96,97,98" |
と記載すればよいことになりそうですが、実際にはV.17のトレーニングが成功してしまうために14400bit/sでの通信が始まります。V.17でトレーニングさせないためには参照先の表をよく眺めてこの場合は73,74,97,98,121,122,145,146も削らなければならないのでした。
1 |
Class1TMQueryCmd: "!3,24,48,72,96" |
同様に AT+FRM の応答ログと設定ファイルの Class1RMQueryCmd を使用します。
同様に AT+FCC の応答ログと設定ファイルの Class2DCCQueryCmd を使用します。
Comodoより重要サイトの証明書が不正な相手に発行されたという記事。RAはどこだったんでしょうか(参考1, 参考2)。ちょっと昔のnull-prefixの証明書の話とは異なります。
How to avoid fraudulent SSLでは、失効した証明書を
場合に、クライアント側が有効な証明書とみなしてしまう
などの、サーバ証明書を売る立場での説明があります。特に今回のような大きな問題の場合は、クライアントが検証用にCRLをダウンロードするタイミングよりOCSPレスポンダへの問い合わせのタイミングのほうが早い場合が多いのでしょう。
秘密鍵がポストされてしまったようなので、ブラックリストでの対応があるクライアントは最新にアップデート、OCSPに対応している場合はタイムアウトした場合も無効となることの確認が急がれます。
参考: MS01-017
Japan Earthquake: Possible scams / malware 詐欺、マルウェアを撒くメールが発生する可能性があるのでご注意をという記事 ⇒ その後各種発生しています。詐欺メールの内容は読むに耐えません。
Tsunami in Japan…既に検索エンジンに対するポイズニングが成功しているという記事。