「ソースコードを自社開発することでOSS由来の脆弱性を排除した」というDNSサーバー 70
ストーリー by hylom
なにかあったときに地力が問われる 部門より
なにかあったときに地力が問われる 部門より
あるAnonymous Coward 曰く、
XACKが、独自に開発したDHCPサーバーやDNSサーバーを搭載するアプライアンスサーバーを販売開始している（IT Leaders、プレスリリース）。
昨今ではDNSサーバーの脆弱性が狙われるトラブルが多いが、同社はDNSサーバーを自社開発することで、「オープンソースのソースコードに由来する脆弱性問題とは無縁」と主張している。また、「細心の注意を払った設計と実装を行うことで、OSS製品を凌駕する、圧倒的な高速処理性能を誇ります」とのこと。
確かにOSS由来の脆弱性は排除されるが、脆弱性が無くなるわけではないと思うのだが……。
作りたいから作った気がする (スコア:2)
XACKってもともとRadius屋さんらしくて、スクラッチで高速Radiusサーバを作ったら、次はDNSサーバを作りたくなるのはまあ自然というか、気持ちはわかります。
まだDNSSEC未対応らしいんですけど。
ライセンスに縛られたくないから (スコア:1)
じゃないかなぁ...
新しく書き起こしたコードのほうがバグや性能に問題の多い場合がほとんどのだと思うけど
※絶対に無いとは言わないし、ライセンスが理由としても黙って流用するよりはずっと良い
Re: (スコア:0)
修正BSDライセンスで困ることってあるんでしょうか。
GPL排除したいというなら分かるんですけど。
Re: (スコア:0)
> ライセンスが理由としても黙って流用するよりはずっと良い
自社開発しましたと嘘をついて流用していた事例もあるんだよなあ。
脆弱性の排除法 (スコア:1)
「仕様です」
Re: (スコア:0)
しょ～うがないな
Re:脆弱性の排除法 (スコア:2)
損害が起きても、自社内で閉じてる分にはいいかと
/* なんだかんだと、すすむしかない */
普通はバカめな感じだが (スコア:1)
BINDだとそれもアリかもと思ってしまうぐらいにはBINDに憎しみを抱いている人も多いはず…
自己満足の極み (スコア:0)
脆弱性はOSSであるかどうかによって存在するのではなく、脆弱性が存在しないことが証明されない限り必ず存在するものである。脆弱性が存在しないことを証明するのは、悪魔の証明である。自己満足の世界でしかない。
Re:自己満足の極み (スコア:3, 興味深い)
どんなソフトウェアにも脆弱性はある、という前提で。
攻撃側からしたら、「脆弱性を探すコスト」をできるだけ下げつつ、「攻撃できるターゲットが多い」方が効果が望めるので。
つまりオープンソースかどうかではなく、単に「普及すればするほど狙われる」以上の話ではないし、だから「普及率が低い新製品」は、そういう意味では確かに有利ではある。
Re: (スコア:0)
近頃は標的型攻撃というのがありまして
Re:自己満足の極み (スコア:1)
近頃は標的型攻撃というのがありまして
で？
標的型であれば、使用しているソフトがプロプラだろうがオープンソースだろうが、普及率が高かろうが低かろうが、狙われる確率は大差ないし、この話題には関係ないと思うんだが。
Re: (スコア:0)
狙われる確率は大差ないかもしれないが、普及率が高いほうが脆弱性の情報は上がってきやすかろうよ
Re: (スコア:0)
上がる先がどちらになるかは不明ですけどね
# 普及している分高く売れそうだし、
# 重大な障害が見つかり修正版が公開されてもそれが適用されるのに何ヶ月かかることやら
Re:自己満足の極み (スコア:1)
プロプラつってもさー。最低単位がハードこみ約100万円（保守3年つき）とかいうアプライアンスなわけですよ、これ。
Windows（やIE）、Adobe製品等、量販店いけば誰でも買えるって代物なら兎も角、こんなもんを「検証して破綻させる一部のユーザー」って何者よ？
企業ユーザーとかで「購入して試験したら穴を見つけた」みたいなことは起き得るけど、それは普通にメーカーに保守として修正させるよね。
かといって一般人やらクラッカーグループがこんなもんわざわざ買って検証するとは思えない、個人が道楽で買う金額じゃないし、販売方式的に足がつく可能性も高いのに。
あと、DNSってプロトコルの仕様として、サーバー側のソフトウェア名称を取得するようなコマンドはなかった筈なので。
アプライアンスがよほどタコい設定をしてない限り、「そもそもそのDNSアプライアンスを使ってる」ことを外部が知れるかどうかが困難だし。
まあうん、たとえば「Bindでゼロデイ攻撃が多発」みたいな状況で、クラッカーグループが「こいつ攻撃してみたけどBindの脆弱性が通らない、何か別の使ってるな」ぐらいに観測される程度が関の山じゃないかなぁ。
# あまりに普及したらブラックボックス攻撃に晒されて穴が見つかることもあるかもしれないけど
# それは1年や2年で起きるようなことじゃないから、心配しなくていいと思うよ
Re:自己満足の極み (スコア:1)
> OSSは最低限のレビューが保証される
「修正されていないぞおおおお」
「誰か！バグを修正してええええ！」
「おかしい、オープンソースは多くの人間がレビューしている」
こう言っているOSS推進派も、コードの修正はしていないのである。
「えっ」
「それなのに修正されない・・・何か政治的な圧力があったに違いない」
「はやく、バグをなおして、でないと攻撃されちゃって……！」
泣き叫んでいるOSS利用のSIerですらも、メンテに人員を割いてはいないのである。
Re:自己満足の極み (スコア:1)
MTAであるQMail [wikipedia.org]の作者が開発した、djbdns [cr.yp.to]を思い出しましたよ。
まぁ、がんばってね…(´・ω・｀) としかいえないですが。
Re:自己満足の極み (スコア:1)
qmailですな。
qmailもdjbdnsも、今そのものを見ると「あんなキワモノ」という評価かも知れませんが、いずれも競合ソフトにセキュアであることの大切さを気付かせたものだったように思います。がんばったというより、結果を出したソフトたちですね。
Re:自己満足の極み (スコア:1)
qmailやdjbdnsも「柔軟性？協調性？なにそれおいしいの」というdjb氏の性格を体現したような偏屈なソフトではあったが、
脆弱性の低さという点ではみごと公約通りの実績を叩き出してくれたじゃないか。
Re: (スコア:0)
悪魔の証明かどうかはともかく、証明しようと思ったら脆弱性を数学的に定義しないといけないな。
Re: (スコア:0)
ハードウェアに起因する脆弱性は含めるか。
リンクしている標準ライブラリ等の脆弱性は含めるか。
DDoSアタック耐性が弱いのは脆弱性に含めるか。(リソースを占有しすぎて他のプロセスの穴を突かれるとか)
まあ色々ありそうですな。
Re: (スコア:0)
結局、モデルとはプログラムで、仕様はモデルを作るための曖昧模糊とした何かなんですよね。
仕様をモデルと同じ精細度で書いても意味ないので、曖昧模糊とは、それで良いそれ以外に有り得ない
精細度では有るのですが、
問題は、それを合意の正文書としてしまっていることで、
いくらでも、仕様バグの湧き出す策源地と化している以上、証明は原理的に無理。
何をやっても、虎を屏風から出すのは誰だの話しでおわってしまう！
Re: (スコア:0)
やはりここは「脆弱性ゼロ」を公約に新党をですね…
Re: (スコア:0)
どうせ「私はAIです」とかいいながら反故にするんでしょ
ぼくしかしらないから大丈夫です (スコア:0)
どうしてもシニカルな目線でコメントしたくなるけども、そもそもOSS全盛になる前はみんなそれぞれ独自開発してた訳だから、改めて考えたら特に斬新では無いけども…まぁ、この言い方は、単に時流を意識した営業トークだよね。
#Human-68Kの解説書がまだ家にある世代の私です。
Re: (スコア:0)
これが営業トークになってしまうことが問題なのでは…。とりあえずこの会社にはぜひdogfoodingしてもらいたい。
Re: (スコア:0)
営業トークってのはまさにそうだろうね。実のところOSSを使わない事が珍しいかと言えばそれほどのことではない。
本当に力のあるメンバーがコンパクトでカリカリにチューニングされたプログラムを書こうと思ったら、
OSSが…というか既存のプログラムが自然に落とされるのも不思議ではない。
「オープンソースのソースコードに由来する脆弱性問題とは無縁」は何とも趣深い言い回しだなあ。
ただ単純に当前の事を言っているだけでもあるし、OSSの信頼性のレベルを実際指摘しているものでもある。
OSSのソースコードは平均的なプログラマの出力するプログラムよりは遥かに優れているものが多いが、
新しい知識を持った最も優秀な開発者とテスターに報酬を支払って出力されたプログラムには劣るものも多いだろう。
脆弱性の見つけ方 (スコア:0)
ソースコード読んで探している人もいるかもしれないが、
とりあえず総当りで大きい値を入れてみよう、みたいな方法で探す人もいると思うんですよね。
Re: (スコア:0)
ものがDNSですしねえ、実環境で多々飛んでくるとんでもないクエリーにされされてバトルプルーフされてないとあまり信用がおけませんよね
まずXACK社は自社のドメイン運用をその製品でやってみてどうだったかを出すべきでしょうね
Re: (スコア:0)
そりゃあ静的解析もファジングもどっちだってアリでしょうよ。
技術力アピール (スコア:0)
OSSにタダ乗りするなんて誰でも出来る
フルスクラッチで開発できてこそ云々
Re: (スコア:0)
でもお高いんでしょう？
Re: (スコア:0)
（由来の）脆弱性がないとは言ってるけど、
バグがないとは言ってないし。
コードは、昔の捨てて書き直せば早くはなるだろ。
Re: (スコア:0)
プレスリリースはそうなんだけど、IT Leadersの記事は
って書いちゃってるんだよね。
Re: (スコア:0)
BIND10、昔のコード捨てて、速くなったかってそうでもなくて、結局廃棄されていまBIND9.12作ってるんですね。なんだったんでしょう、BIND10って。
OSS はバグだらけで使い物にならない (スコア:0)
Windows アップデートで来るバグ修正はいいバグ修正
Re: (スコア:0)
yum update
apt get update
で来るバグ修正はいいバグ修正
Re: (スコア:0)
どっちみちアップデートできないじゃないですかーやだー。
Re: (スコア:0)
そりゃオープンソースはメンテナがいることを意味しないからな
Re: (スコア:0)
メンテが保証されているのは改めて考えると凄いよね。やっぱOSSは駄目だわ。
マイナーなうちはいいかもね (スコア:0)
脆弱性探す手間が惜しいぐらいのシェアと場所でひっそりと使う分にはありかもよ。
そこまで自信があるなら脆弱性発見に懸賞を是非 (スコア:0)
そこまで自信があるなら是非、ハッキングコンテストなり、検証付き脆弱性募集なりをやってもらいたいです。
Re:そこまで自信があるなら脆弱性発見に懸賞を是非 (スコア:2, 興味深い)
それも開発形態がオープンになっていないと、何とでも言い訳して逃げられてしまうんですよね・・
ずっと昔のことなのですが、とある商用ソフトウェアで脆弱性に対して懸賞金をかけていたプロジェクトがあって、
きちんと再現手順までまとめて報告しても、
「それは弊社内で既知の問題として報告されているので無効」
「DOS(サービス拒否)攻撃は脆弱性ではない(??)ので無効」
「それは運用で回避可能なので無効(ただし実際にはサービスを停止する以外の回避策はなかった)」
などと言って懸賞金の支払いを渋りまくっていました。
何度もやりとりしていると、その会社の弁護士を名乗る方から「恐喝として通報する」と脅されてしまいましたので、
それ以降はやめておきましたが、オープンソースでないとしたら、こういった隠蔽に対する対策を公表していただきたいものです。
一般論としてはともかく (スコア:0)
比較対象があのBINDだと思うと、それよりは安全な可能性も十分にあると思わざるをえない
OSレベルから独自設計なのかな？ (スコア:0)
サーバプログラムは独自だがOSはLinuxカーネル使っているとかだったら意味ないような気もするが
Re:OSレベルから独自設計なのかな？ (スコア:1)
ハードウェアは、HPE ProLiant Thin Micro TM200 [hpe.com]で、サポートされているOSは、Windows Server、RHEL、VMware vSphereだってさ。
Windows Serverなら意味があるかな?
# さすがにVMwareってことはなかろう。
ソースコードを自社開発？ (スコア:0)
ソースコードを自社開発してもプログラムは動かない。
コンパイル（Python 等のインタプリタ言語なら実行）して初めて動作する。
第一、ソースコードに由来する脆弱性やbugがないソースコードを開発できるのか。
sendmailの置き換えを狙ったqmailみたいな物か。
BINDをいじくりまわすより新規に作成した方が楽かも？
考えられる事は、公開されたソースコードが無けりゃ、bugや脆弱性を研究される可能性は少ないだけ。
Re:ソースコードを自社開発？ (スコア:1)
IT Leadersの記事：「ソースコードのすべてを自社で開発」
スラド：「ソースコードを自社開発」
Re: (スコア:0)
俺も「ソースコードを自社開発」という言い回しに非常に強い違和感を覚えた。
まずは (スコア:0)
運用実績と稼働期間を聞いてからかな
脆弱性はないかもしれないけど、運用実績ないと導入の検討もできないんじゃないかな
実績ないのを導入するぐらいなら素直にAWSとかで借りるのを検討した方が
トータルコスト安そう