UNLHA32.DLLの開発停止、作者がLHA書庫の使用中止を呼びかける 215
ストーリー by hylom
日本ローカル規格は無視ですか？ 部門より
日本ローカル規格は無視ですか？ 部門より
Claybirdの日記 曰く、
Unlha32.dllの開発が停止された。バグ対応などは当面続けられる模様だが、UNLHA32.DLLの開発者であるMicco氏のWebサイト上で、LZH（LHA）形式の使用中止が呼びかけられている（ratbetaさんの日記）。
今日ではほとんどのウイルス対策ソフトが書庫ファイルに対しウイルスチェックを行う機能を備えているが、多くのウイルス対策ソフトで「LZH書庫ファイルのヘッダー部分に細工を施すことでウイルスチェックを回避できる」という脆弱性が存在するとのこと（LZH書庫のヘッダー処理における脆弱性について）。
Micco氏はこれをJVN（Japan Vulnerability Note、JPCERTおよびIPAが共同運営する脆弱性情報集積サイト）に報告したところ、「不受理」となったそうだ。ZIPや7z形式の書庫にも同様の問題があるものの、そちらは「脆弱性」として受理されているとのこと。Micco氏曰く、
「ベンダー， JVN / IPA 等共に『LZH 書庫なんて知らねぇ～よ』という態度から変わることはない」と判断できましたので， UNLHA32.DLL， UNARJ32.DLL， LHMelt の開発を中止することに決めました。 脆弱性が存在しても放っておかれるような書庫が いつまでも業務目的で利用されるのは嫌ですので。
（中略）
おそらく， 海の向こうでネタに上るか大きな事件でも発生しない限り対応されることはないでしょうから， (特に団体・企業内で) LZH 書庫を使うのは止めましょう。 まぁ， ZIP 書庫ですら 3 年以上経ってから海外でネタに上ったくらいなので， LZH 書庫も あと 10 年ほどしたら海外でネタに上るかもしれません。
つまり主犯はIPAなんだな？ (スコア:5, すばらしい洞察)
ここが受理してれば対応はされたはず…ということですかね。
Re:つまり主犯はIPAなんだな？ (スコア:5, すばらしい洞察)
この騒動で一番重要な事は、「LZH終了のお知らせ」ではなく、アンチウィルスソフトウェアの脆弱性が放置されている点にあります。
海外のCVEはともかく、日本のIPAはLZH形式を知らないはずが無いわけです。日本国内でのLZHファイルの流通量についても知っている(少なくとも調査は容易に行える)はずなので、影響範囲は小さくないとすぐに分かったはずです。
さらに、他形式における対応(アンチウィルスの脆弱性として受理)を考えれば、IPAがアンチウィルスの脆弱性を受理しない事の方が不思議です。
なぜ脆弱性情報が受理されなかったのか、今後はそちらの方が問題になるのではないかと思います。
Re:つまり主犯はIPAなんだな？ (スコア:1)
LHA形式の圧縮/復元ユーティリティを大手中の大手マイクロソフトも配布してはいますけども、たいていの配布元は個人です。
マイクロソフトはWIndows XPの頃に配布していたようですが、WIndows7対応とかServer製品でのサポートってしてるのかは知りません。
また、LHAユーティリティは窓の杜やベクターを通じて入手するケースが多いのでしょうけどそういうところにIPAは働きかけするんでしたっけね?
それに流通はほぼ日本が中心。海外ではLHA形式単体はマイナーなんですよね?
IPAとしては、多数の個人のソフトウェア開発配布元を人手の足りないIPA自身でコントロールしようと試みるのは荷が重いと判断した,
その結果不受理による切り捨てという顛末なのではないだろうか?
LHA形式を切り捨ててもzipもgzipもbz2も7zipも代替手段としてあるわけで、この辺のユーティリティソフトウェアは日本のIPAが真っ先に主導権
をとらなくても残りの世界中で誰かがイニシアティブを発揮してコントロールしてもらえることがわかりきっているわけですし。
Re:つまり主犯はIPAなんだな？ (スコア:5, 参考になる)
何か勘違いをなさっているような気が。
LHA書庫を扱う際、
1.大きなヘッダによるバッファオーバーフロー
2.バッファオーバーフロー回避の結果起こる検疫通過
の2つの脆弱性があり、バッファオーバーフローについては、CVE-2004-0234 [mitre.org] 等で既に脆弱性として扱われています。
私が問題と言っているのは、検疫通過の方です。これはアンチウィルス限定の脆弱性であり、一般の解凍ソフトでは問題になりません。
検疫通過はアンチウィルス製品メーカー以外では対応できないので、一般の解凍ソフト作者への働きかけは関係無い話です。
対策２つありますよね？（Re:つまり主犯はIPAなんだな？ (スコア:2)
これって、アンチウィルス製品メーカの対策って２つありますよね？
１．LHA書庫を全て検閲する（どんなヘッダであっても、無視せずに解凍して中身をチェックする）
２．LHA書庫を"対応書庫ファイルから外す"
# 「きちんと検閲する」or「そもそも検閲しない」
いくつかのアンチウィルス製品メーカのサイトを探してみましたが、具体的にどの圧縮形式に対応しているかわかりませんでした。
ので、そこをつまびらかにすれば、「LHAの中身は探さないんだ＝やばいかも」とユーザにわかるようになる気が。
# それこそ超マイナーな圧縮形式には対応してらんないでしょうし。
問題の本質は一見LHA書庫の中身も検閲しているように見えるけれども、すり抜けているってところですよね。
何を調べて、何を調べていないのか、きちんと明示しなきゃいかん、みたいな風潮になると良いなあ:-P
Re:対策２つありますよね？（Re:つまり主犯はIPAなんだな？ (スコア:2, 興味深い)
どうかなあ。それはアンチウイルスに対する期待が大きすぎるんじゃないかな？
「UPXでのパックに対応している」と書いてあれば、それは全てのUPXをサポートすべきだと思う。
でも「LZHの自己解凍モジュール形式には対応していない（or 対応リストに載っていない)」という対応は十分アリだと思う。
使わなきゃ良いだけの話なので。
怪しげな実行ファイルは実行しないとか、安全が確保されていない圧縮形式で保管はしない・受け取らないとか、そういう対策をとれるからねー
# その意味で、今回のLHAは使わないようにしようってのは悪くない対応なのかも？
Re:つまり主犯はIPAなんだな？ (スコア:2, すばらしい洞察)
Re:つまり主犯はIPAなんだな？ (スコア:2)
しかも、各ジャンル（といっていいよな）に関係の深い言語があるのは当たり前で
たとえばキリスト教関係のことやってるとラテン語なんて死語がついてくるわけで。
その意味では、なにも英語が特殊な位置にあるわけではない。
Re:つまり主犯はIPAなんだな？ [オフトピ、もしくは余計なもの] (スコア:3, 参考になる)
マイクロソフトはWIndows XPの頃に配布していたようですが、WIndows7対応とかServer製品でのサポートってしてるのかは知りません。
Windows Server 2008 R2 や Windows 7 は LHA 圧縮形式の "解凍" に標準で対応しています。
http://ja.wikipedia.org/wiki/LHA [wikipedia.org]
詳細はこのあたりをどうぞ。
Re:つまり主犯はIPAなんだな？ (スコア:2, すばらしい洞察)
どのアンチウィルスベンダーも対応してくれそうにないから LZH 自体を終了します、じゃないの？
Re:つまり主犯はIPAなんだな？ (スコア:1, すばらしい洞察)
Re:つまり主犯はIPAなんだな？ (スコア:1)
LHA作者さん [kurosawa-hp.jp]に取材に行くメディアはないものでしょうかね。
とりあえず行動してみた (スコア:5, 興味深い)
「LZH 書庫のヘッダー処理における脆弱性について 」 [nsknet.or.jp]への対応を、私が利用しているキュリティソフトベンダのカスタマサポートに投げてみた。
これでとりあえず（すくなくとも私に対しては）「未知の脆弱性」が「既知の脆弱性」になったわけだ。
不受理の理由 (スコア:5, 参考になる)
JPCERTが受理しなかったのには、理由があったそうです。
ソースはこの辺:
http://twitter.com/hasegawayosuke/status/15614339358 [twitter.com]
> UnLHAがIPAで不受理だという件、
> http://www2.nsknet.or.jp/~micco/incidents/2010/inci1006.htm#i20100602 [nsknet.or.jp]
> を見る限り制度の理解不足による誤解でしかない。
http://twitter.com/hasegawayosuke/status/15614795535 [twitter.com]
> そもそも現行のIPAの制度ではアンチウイルスで未検出については対象外なので
> 不受理だろう(経産省告示第235号)。
> http://www.meti.go.jp/policy/netsecurity/downloadfiles/vulhandlingG.pdf [meti.go.jp]
> ZIP,Cab,7zのJVNVU#545953はCERT-FI経由の情報を掲載しているだけ。
http://twitter.com/hasegawayosuke/status/15614841340 [twitter.com]
> LZH内のファイルがアンチウイルスで検出できない、というのにCVE番号欲し
> いなら英語でbugtraqにでも投げればいい。その際、LZH形式がどれだけ日本
> でメジャーなのかをきちんと伝えること。
Re:不受理の理由 (スコア:4, 興味深い)
これ本当でしょうか?
参照されている告示によれば、「脆弱性関連情報」には「脆弱性情報」すなわち
を含むとされており、「脆弱性」とは
のことです。
そもそもこれだけでは「ウイルス対策ソフトが○○というウイルスを検出しない」というのが脆弱性関連情報 [ipa.go.jp]に該当するかしないか僕には明らかでありません。さらに、仮にウイルス対策ソフトが個別のウイルスを検出しない問題が告示で言う「脆弱性」に該当しないとしても、本件は個別のウイルスの話ではなく、「ウイルス対策ソフトが LZH 形式アーカイブの中まで検索すると謳っているのに、細工された LZH 形式アーカイブの中を検索しない場合がある」という問題です。告示に書かれた基準に照らして本件が脆弱性関連情報に該当しないと論ずるロジックは僕には理解できません。
これとは別に、 CVE 番号を振ってもらうためには英語で bugtraq に投稿する方が効果的じゃないの、という指摘は、実態を知りませんがそういうものかもと思います。
仕様準拠って大切なんですね (スコア:4, 興味深い)
素通りが生じる組み合わせとして、
・あるウィルスチェッカは、厳密に仕様に準拠した書庫ファイルしかチェックしない
・どこかの誰かが作った親切な解凍ツールは、仕様に準拠しないちょっと壊れた書庫ファイルも頑張って解凍してくれる
とかもあり得ます。例えば、「展開後のチェックサム」を含む形式の書庫の扱いで、「チェックサムが合わないから書庫が不正」と判断して一切展開を行わないのか、「チェックサムが合わないけど展開は出来た」のでユーザの利便性のためにファイルは残しておいてユーザの判断にゆだねるのかの食い違いとか。前者が責められるのは酷なので、この場合は後者に脆弱性有りとされるんでしょうね。
その手のアーカイバが「チェックサムが合わなかったから、ファイルは壊れているよ」と警告を出す事例も見たことがある気がしますが、 「ウィルスチェックされていない危険性があります」という意味も含意してしまうとまでは考えが及んでいませんでした。 まあ、大手のウィルスチェッカなら、その解凍されたファイルがディスクに書き込まれる段階でもチェックはしてくれるんでしょうけど。
やはりセキュリテソフト側の対応が必要 (スコア:2)
細工されたLHA書庫ファイルが通過することには変わりないんだから、
拡散するのが少なくなるにしても、完全に防ぎきることはできない。
だから、やはりセキュリテソフト側の対応は必要。
IPAが仕事しないなら、自分のところで使っているセキュリティソフトが対応してるのか
どうか、個別に問い合わせるしかないな。
Re:やはりセキュリテソフト側の対応が必要 (スコア:1)
LHAのファイルだけ先にヘッダ情報が適切かどうかを調べるといいのかな。
とか書いても、わたしゃそんなんようせんねんけど(in OSAKA SLANG)
Re:やはりセキュリテソフト側の対応が必要 (スコア:1)
でも、パスワードで保護された書庫は、おそらく現状どのアンチウイルスソフトでも中をチェックしてくれないですよね。（BitDefenderでは多分そう）
暗号化を自動解除というのも、そう簡単にはいかないでしょうし。
「アンチウイルスソフトが様々な書庫形式に対応する」だけではなく、「書庫展開ツールが、取り出したファイルに対してウイルスチェックを行う（APIを呼ぶ）」という対処も必要なんじゃないかと思います。
（展開ツール側にセキュリティホールがあると手遅れなので、こちらのみというわけにはいかないですが）
ウィルス対策ソフトの脆弱性: マイナーなソフトの脆弱性は放置される (スコア:2, すばらしい洞察)
マイナーな分野で脆弱性を持ったマイナーなソフトを流行らせる→その脆弱性をついたウィルスを作る
当然、例えば俺が作ったオレオレソフトウェアの脆弱性まで対応していられないのは明らかだし、そういうことがあるのは分かりきっていたことだけど、
LHA程度のマイナーさでもこれが通用するのなら、それなりの脅威になりうるのでは？
1を聞いて0を知れ!
Re:ウィルス対策ソフトの脆弱性: マイナーなソフトの脆弱性は放置される (スコア:2)
少し…頭冷やそうか…
普通の企業なら (スコア:2, おもしろおかしい)
パスワードのかかるzip形式が義務なんじゃないですかね。
ここ数年で義務化された企業が殆どだと思う。
全社共通パスワードとか、プロジェクト共通パスワードとかだから、
どの程度意味があるのかは疑問だけどね。
さらに言えば、パスワード付きzipの強度が、業務に耐えうるかというと。
Vectorとか (スコア:2)
LZHとかじゃなかったでしたっけ？
あれを全部zip化しなおすということになるんでしょうか。
話が良く見えない (スコア:1, 参考になる)
JPCERTが受付しないとMicco氏が開発やめるという
このお話のロジックがよくわからんです。
Re:話が良く見えない (スコア:5, 参考になる)
という感じかなぁ。
Re:話が良く見えない (スコア:3, 興味深い)
実際にLZH 形式がマルウェアの入れ物として使われることになりはじめれば、それを検出できないアンチウィルスソフトが信用を失うだけでは？
基本的には、「費用対効果」でしょう。
実際に LZH 形式で流通しているマルウェアが多ければ、もちろん自主的に対応するでしょう。ただ、もし、現実に流通量が少なければ、「日本の一部ユーザだけ」という事を理由に、後回しになることは十分に考えられます。
もちろん、LZH 形式にきちんと対応していない事によって実際にマルウェアを逃した場合、ある程度の信用低下はあると思いますが、昨今、爆発的に増加する亜種に対して、後手に回って取りこぼす事が、珍しいことでは無くなってきたので、「LZH に入った物を取りこぼす」ということで失われる信用は、限定的ではないかと思います。
逆に、「うちは LZH 形式にちゃんと対応してますよ！」というソフトが、商品としてどれだけのアドバンテージがあるか、ということにもなります。対応することで他社製品と差別化が出来て売上が伸びる、のであれば喜んでやるでしょうが、「LZH って何？」という人が大半だと思うので、市場に対するインパクトはほとんど無いと思います。まぁ、焦点になっているのはゲートウェイ型なので、デスクトップ向け商品よりは、LZH を知っている人が商品選択をする確率は高いと思いますが、それでも限定的でしょう。
ちょっと話はそれますが、オライリーから出た「セキュリティの神話」という本をちょうど読んでいたのですが、その中で、ウィルス対策ソフト側として、圧縮ファイルの扱いが非常に難しい、という話がありました。何重にも圧縮処理をされていて、それを展開してみないと判定が出来ない。「そんな何重に圧縮されているような物は、調べるまでも無くクロだろ」と思うと、実は、ウィルス対策ソフト自身が配布するファイルが、マルウェアの作者に解析されるのを防ぐために同様の事をやっている、なんて事が書かれていました。
ウィルス対策ソフトにとって、圧縮ファイルの取り扱い自体が、そもそも「面倒」なのに、日本の一部ユーザの為に対応するか、となると、他に優先順位が高いことが山ほどある、という気がします。IPA のようなところから「お墨付き」があれば、重い腰を上げて対応するかもしれませんが、それすら無い状態で、LZH 形式に積極的に対応するとしたら、その商品が日本のマーケットに特化しているか、他に優先すべき事象が無いか、のいずれかだと思います。
# 個人的には、自己解凍形式が一番怖いと思う。
Re:話が良く見えない (スコア:2)
＞かつてZIPのように有償の製品を販売する有力なベンダーが無かったため，
単にLzhが日本独自の形式で、世界的に見ればマイナーな形式だからかと。
(一時期のCompuServeではLzhもそれなりに使われたりしていたが……)
近年は海外ベンダーも最初から日本語版を含む各国語版も同時にアメリカ本社などで開発。当然、パッチなどはZipで配布。さらに日本国内に有力なソフトハウスがほとんどなくなった。そんな理由では。
＞インストーラもアマチュア作成のフリーのものを使ってるメーカーがあるんだけど，同じような脆弱性の問題が発覚したらどうするんだろうね？）
別のインストーラ生成ツールに乗り換えれば良いだけでは？ 有償製品を使っていても再配布する手間は変わらないでしょう。
有償製品であれば保守されるなどという保証はありません。多少、可能性が高いかも？ 程度のことでしょう。
Re:話が良く見えない (スコア:2, 参考になる)
だから、開発をやめてユーザーに使わないように呼びかける、という話になっているのだと思いますよ。
残念、消えてしまうんですか。 (スコア:1)
#とは読めないよな
個人で取れる対策としては (スコア:1, 参考になる)
といったところですかね。
まあアンチウイルスソフトが対策してくれれば一番いいんですが。
ASUS の BIOS (スコア:1, 参考になる)
(ユーザが 1703.BIN を解凍する必要はないけど)
言葉遊び…と言ったら当事者に失礼ですけど (スコア:1)
そもそもの話として IPA にとって、ウイルス対策ソフトメーカーにとって、
書庫を扱うソフト作成者にとっての脆弱性ってなんなんでしょうね?
あえてここの部分を触れずに話が進んでいるような気がするんですけど。
まあ安全方向に考えて使うのをやめるべきだという話は構わないと思いますが、
既にいろんなサイトで配布されている書庫 (特に今回の件が本当に問題だと
仮定すると通常書庫はともかくとして自己解凍書庫は更にタチが悪いわけで…) の
扱いをユーザーがどうするかですよねぇ。ウイルス対策ソフトが悪いと言うのなら
まだユーザーが別のメーカーのものに入れ替えるといった対策が取れますが…
# 以下オフトピ。
# 基本的にセキュリティ対策ソフトは何が出来て何が出来ないかをちゃんと把握した
# 上で使うべきものだよねぇ。クライアントにインストールするタイプなら最悪
# 解凍後にチェックがかかるし。書庫を扱うソフト自体の機能を使ってオンメモリで
# プレビューするような事をしないで解凍のみを行う分にはファイルになる時点で
# チェックされればあまり問題ないわけで。それに比べてゲートウエイ型は
# ある程度フィルタリングしてくれるぐらいの感覚で使ってないと怖いのは私だけ?
# 「仕様」としてチェック出来る書庫のサイズ制限があるものもあったし、
# そもそも暗号化したファイルなんかはチェックをすり抜ける場合もあるだろうし。
# メーカーの宣伝を鵜呑みにして「これだけあれば安全」なんて思うようじゃ
# 人間という究極の脆弱性に負けた (笑) だけの話にも思えるわけで。
## いやぁ、実際に前に勤めていた会社では ISP の提供するゲートウエイ型の
## ウイルス対策しかしなくてクライアントには何も入れてなかった (社長曰く
## 「金がもったいない」) 。他社とデータのやり取りをする事があったんだけど
## その際に「ある独自の暗号化をするソフトを用い、自己解凍形式にして mail に
## 添付して送る」という方法でやれと社長が説明してきた。受けるのも同じ。
## 当然ながら mail には電子署名 1 つつけてなかったりするとか…
## とはいえ mail でいきなり自己解凍ファイルが来てそれをローカルのウイルス対策
## ソフトを入れていない PC で実行なんてあまりにも怖い。なので社長に「万が一
## ウイルスだったらどうするんですか? ゲートウエイではチェック出来ないだろうし
## ローカルでもチェック出来ませんよ?」と言ったらなんと「だったら今ここで
## 実行してみろ。それでウイルスが起動したらお前の言ってる事が正しいと認めて
## やるがそうじゃなければ今まで通りで問題ない。今まで問題になった事なんて
## ないんだ。」と反論してきたのにはまいった。一応会社の業務内容に
## 「サーバー構築」なんて書いてる会社なのに大丈夫なのかねぇ…
## もちろんそれから 1 ヶ月もせずにその会社を辞めましたけど :-)
Re:いらない (スコア:1, 興味深い)
んなこと言われても、取引先がLZHでって指定してくるんだから仕方ないよ……。
Re:いらない (スコア:1)
自分もファイル受け渡しする相手もみんなLZH使えるなら、ZIPなんか使う理由だってひとつもないのです。
1を聞いて0を知れ!
Re:いらない (スコア:1, 参考になる)
某省庁での仕事では常時300人くらいへのメール配布を行っていましたが、
文書ファイルは一太郎で、ファイル圧縮形式はLZHでしたよ。
Re:いらない (スコア:1)
最近，zipも含めて，コンシューマ向けには別に圧縮はなくても良いんじゃないかと思うことも．
ストレージ容量もかなり増えてるし，通信環境もだいぶ良くなってるわけで，そんなに圧縮そのものはいらないんじゃないかなあと．
どうせ容量の大きいデータなんて動画とかそんなものぐらいだろうし，そういうのはすでに圧縮もかかっていますし．
#tarのようなアーカイバはあっても良いと思うけれども，圧縮ってそんなに要ります？
Re:いらない (スコア:3, 興味深い)
メモリやストレージは確かに増えていますが、メモリバスやストレージI/Oの速度は（CPUパワー向上に比べて）あまりアップしない傾向がありますから、圧縮がおいしく効いてくれる局面はまだまだあると思います。
もっとも、ユーザーの目に見える「圧縮アプリケーション」としての形態は、必ずしもとる必要はないかもしれません。たとえば…
- ファイルシステムや通信プロトコルなど、下のレイヤで勝手に圧縮（と重複排除）してくれるもの。
- 各種アプリケーションが吐き出すデータファイルの時点ですでに圧縮されているもの。（OOoやMS Office 2007以降のファイルなど）
この場合は、確かにユーザーとしては圧縮アプリは不要ですね。ユーザーとしては、こちらのほうがありがたいところです。
Re:いらない (スコア:2)
どこにぶら下げようか悩みましたがここに。
確かに、zipならWindowsで標準サポートされてるし、それ以前に圧縮しないでもストレージや通信環境も気にしないでいいレベルになってます。
でも、精神的にlzhが捨てられないです。
まだDOSコマンドが魔法の呪文に思えた頃。
圧縮すると
oooooooo.........
と表示されるのが面白かった頃。
arkでもlharcでもいいです。自分のフロッピーディスクの容量がどんどん空いていった。
その空き容量の分、自分の創作物が入るようになっていった。
大したプログラムではない、大した文章ではない。
今見ると恥ずかしくなって穴があったら入りたいくらいの創作物だけど、このプログラムがあったから今の自分がいるような気がする。
今、圧縮ファイルを作成するたびに、その頃の記憶がちょっと引っかかって、zipやrarで圧縮する時にlzhにすまない気分になる。
個人的に使う物はlzhで4GB超の物はrarで圧縮してますけどね。
Re:いらない (スコア:2, 興味深い)
メールにwordやExcelの素のファイルを5個も10個もつけて送る人が普通になった気がします。
ネットでソフトをダウンロードして、解凍して、、ということは普通にやっていても、
自分が圧縮するって発想自体がなくなって来ているのかも。
ウイルス対策ソフトがちゃんと仕事をしてくれているのは、喜んでいいのかなぁ。
Re:いらない (スコア:2)
オイラのお父ちゃんの悪口いうな！
Re:いらない (スコア:1)
東京・大阪間での資料やり取りとか割と時間掛かったりしませんかね～。
静止画でも圧縮かけてない生データをやり取りするときとか、MB単位のファイルだと早くても3分は掛かる気がが
// 修正差分のファイル一個だけもらう時とか圧縮かけないで送って貰ってました。
あと圧縮やパス付けしないと平文でやり取りすることになるので、安心感が違うんじゃないですかね～。
ソースを平文で送って覗き見されて脆弱性発覚！とかありそうな気がしなくもないかもしれない。
そんなもんノーガードで送るな、ですけどｗ；
// 実際の安全性云々はまた別の話で、あくまで精神的なお話ということでどうか(:>^
Re:世代交代はいつになるやら？ (スコア:2)
何故CAB (LZX21) にしないのですか？
Re:世代交代はいつになるやら？ (スコア:2, 興味深い)
Re:やっと滅んでくれるか(スコア:-1, 荒し) (スコア:1)
Re:やっと滅んでくれるか (スコア:1)
Re:やっと滅んでくれるか (スコア:1)
>個人が趣味で、しかもクローズドで開発しているガラパゴス規格を何故延命させようとするか理解出来ませんでした。
LHAってソース公開されてますよ？
ガラパゴスじゃないか？っと言われればそうかもしれないですが、少なくともクローズドではないでしょう。
Re:やっと滅んでくれるか (スコア:1, すばらしい洞察)
モデレートは正論かどうかとは全く関係ない。
言葉遣いや過激な表現などが対象になるのさ。
ZIP一択。 (スコア:1, 参考になる)
リンク先ぐらい読もうや (スコア:2, 参考になる)
http://www2.nsknet.or.jp/~micco/vul/2010/mhvi20100425.htm [nsknet.or.jp]
の下の方、
●UNLHA32.DLL
巨大なヘッダーによるバッファーオーバーフロー発生の脆弱性については対応が行われており， 次のような処理を行います：
* 4KB を超えるヘッダーを扱えない (当該メンバーを無視する) ウイルス対策ソフトが存在したことから， 構造に関わりなく全体が 4KB を超えるヘッダーについては， 破損ヘッダー (Exploit LHA) として扱われます。 ちなみに， 4KB というのはオリジナルの LHA が用意していたバッファーのサイズで， 比較的多くのソフトが， このサイズを， そのまま採用しています。
* ID 0x01， 0x02 等の拡張ヘッダーについては， 512 文字を超えた名前が記録されていた場合には， 破損ヘッダー (Exploit LHA) として扱われます。
* メンバー名の改竄や隠蔽を意図したと思われるヘッダーサイズとデーターサイズの不整合については， 破損ヘッダー (Exploit LHA) として扱われます。
まぁ十分とは限らんが、無対策と責められるほどではない。
Re:UNLHA32.DLLを使っていれば安心なんですか？ (スコア:2)
「良いはずです」と言われても……。 Micco さんとしては、この「すり抜け」の問題は本来ウイルス対策ソフト側が対処するべきであるところ、 UNLHA32.DLL 側で何とか問題を軽減しただけなわけです。「自分のできる範囲で手は打ったけれど、根本的な対処が期待できないから、早いところ LZH アーカイブの使用をやめた方が良いよ」と呼びかけるのは整合的だと思いますよ。