headless 曰く、

NASAの小惑星専門家Paul Chodas氏は8月に発見された小惑星「2020 SO」が実際には小惑星ではなく、54年前にNASAが打ち上げたCentaurロケットの第2段ではないかと予想しているそうだ(APの記事、 SlashGearの記事、 The Vergeの記事)。

2020 SOの実体として予想されているCentaurロケットは1966年に月着陸機 Surveyor 2の打ち上げに使われたもの。打ち上げ自体は成功したが、Surveyor 2は3つのスラスターの1つが着火せず、コントロールを失って月面に墜落している。一方、Centaurロケット第2段は月を通過して太陽周回軌道に入り、地球に帰ってくることはないと考えられていた。

Chodas氏が注目しているのは2020 SOの軌道だ。その太陽周回軌道は地球と同様の真円に近い軌道であり、小惑星としては珍しい。また、軌道面は地球と同じであり、大きな軌道傾斜角を持つことが多い小惑星とは異なる。さらに、地球への接近速度が小惑星にしては遅く、時速約2,400kmだという。今後地球へ接近するにつれて詳細な観測が可能となり、太陽光の放射や熱による軌道への影響も確認できるとみられる。ロケットの残骸であれば空き缶のようなものであり、重い小惑星とは異なる動きが観測されることになる。

8月19日に初めて観測された2020 SOは10月13日0時(UTC)時点で地球から0.02天文単位(約300万km)の距離にあり(JPL Small-Body Database Browser)、10月～来年5月には地球の重力に捉えられて一時的に地球を周回する軌道に入ると予想されている。その明るさから長さ約8mと推定されており、エンジンノズルを含めて長さ10m弱、直径約3mのCentaurロケットに近い大きさだ。

headless 曰く、

小学館がGoogleに送った米デジタルミレニアム著作権法(DMCA)に基づく削除要請で、オンライン辞書サイトDictionary.comの見出し語「magi」のページがリストに含まれている(TorrentFreakの記事、 削除要請)。

このDMCA削除要請は小学館に代わってcomeso GmbHが送ったもので、小学館が刊行する複数の漫画作品について海賊版のURLをインデックスから削除するよう求めている。Dictionary.comのURLが含まれるのは漫画「マギ」に関連する海賊版URLのリストだ。

「magi」は古代ペルシャで世襲された聖職者の階級や、魔術師などを示す「magus」の複数形で、イエス・キリストの誕生を祝福した東方の三賢人という意味で使われる。漫画の「マギ」の語源にもなっているとみられるが、Dictionary.comのページは漫画と全く無関係だ。

TorrentFreakは他にもDictionary.comのページをリストに含むDMCA削除要請を2件見つけており、うち1件はcomeso GmbHが送ったものだ。いずれの場合もオンライン辞書サイトのURLはDictionary.comのものだけであり、他のメジャーなオンライン辞書は削除要請の対象になっていないようだ。この削除要請は小学館が直接送ったものでないとはいえ、小学館が辞書も刊行していることが削除要請を際立たせたとTorrentFreakは評している。

あるAnonymous Coward 曰く、

セキュリティ研究者の報告によれば、ここ2週間ほどの間に、インターネット上に保護されずに公開されている脆弱なデータベースに対して、ほぼ全てのデータが削除された上に「Meow (ニャー)」という猫の鳴き声だけが書き残される「Meow Attack (ニャー攻撃)」が相次いでいるという（GIGAZINE、Slashdot）。

最初に発見されたのは香港のVPN業者UFO VPNのDBへの犯行で、研究者がDBがインターネット上に公開されている旨を企業とやり取りしていたところ、7月21日にDBのデータが削除され、「meow」の文字が残されているのを発見したという。ニャー攻撃はその後も拡大を続けており、27日現在までに、ElasticsearchやMongoDB、Apache Cassandraも含めて4000件以上が被害を受けたとのこと。

当然ながら、インターネット上に保護なく公開されたDBは以前から攻撃を受けているが、だいたいの場合はランサムウェアで身代金を要求されるか、単純に削除されるかとのことで、わざわざ「ニャー」とメッセージを残していく動機は不明。一方で手段については、スクリプトでProtonVPNを経由して行われているとの分析がされている。発見した研究者は「簡単に攻撃可能なほど無防備なので、面白半分でやっているのでしょう」と語っている。

情報元へのリンク

taraiok曰く、

人気の高いオープンソースプロジェクトの上位54本を分析した結果、セキュリティの脆弱性が1年で2倍に増えていたことが判明した。2018年に報告されたバグは421個であったのに対して、2019年には968個に倍増していたという。RiskSenseの「The Dark Reality of Open Source」レポートによれば、2015年から2020年3月の間で人気オープンソースプロジェクトで2,694個のバグが発見されたとしている（ZDNet、Slashdot）。

Linux、WordPress、Drupalといった超人気プロジェクトに関しては、セキュリティバグがニュースとして報じられるため、このレポート内には含まれていないという。RiskSenseのレポートには、Jenkins、MongoDB、Elasticsearch、Chef、GitLab、Spark、Puppetといった、一般的な知名度は高くないがテクノロジーおよびソフトウェアコミュニティで広く利用されているプロジェクトを対象としている。

今回の調査で同社は、多数のセキュリティバグが公開されてから数週間が経過した後で脆弱性データベースNational Vulnerability Database（NVD）に報告されたことを問題視している。54のプロジェクトで発見されたバグに関しては、NVDに報告されるまでに平均で約54日を必要とした。PostgreSQLではPostgreSQLでは8か月に及ぶ報告の遅れが見られたとしている。こうしたレポートの遅延により、企業が攻撃にさらされたままになっている状況が発生していたとしている。

WhiteSourceの年次報告書「The State of Open Source Security Vulnerabilities」によると、2019年に報告されたオープンソースソフトウェアの脆弱性は前年から50%近く増加していたそうだ(BetaNewsの記事、 The Registerの記事)。

データはWhiteSourceがNVD(National Vulnerability Database)のほか、セキュリティアドバイザリやピアレビュー型の脆弱性データベース、バグトラッカーから収集したもので、2019年のオープンソースソフトウェアの脆弱性は6,000件を超えているという。オープンソースソフトウェアの脆弱性は85%が公表時点で修正されている一方、NVDに掲載されるのは84%にとどまる。当初はNVDに報告されないものも45%にのぼり、29%はいずれNVDに掲載されるものの数か月のタイムラグがあるとのこと。

オープンソースソフトウェアの脆弱性で最も多いのはCで書かれたものだ。ただし、2009年～2018年のデータでは脆弱性の47%を占めていたのに対し、2019年は30%まで減少している。一方、PHPは15%から27%に増加した。脆弱性の種類ではC以外の言語(C++/Java/JavaScript/PHP/Python/Ruby)でXSS(CWE-79)が最多、不適切な入力確認(CWE-20)と情報漏洩(CWE-200)が続く(Rubyのみ逆順)のに対し、Cではバッファーエラー(CWE-119)・領域外読み込み(CWE-125)・NULLポインター参照(CWE-476)の順になっている。

VPN比較サイトTheBestVPNの集計によると、2019年に報告された脆弱性が最も多い製品はAndroidだったそうだ(リポート、 9to5Googleの記事)。

データは米国立標準技術研究所(NIST)のNational Vulnerability Database(NVD)から抽出したもので、2019年に報告されたAndroidの脆弱性は414件。Debian Linuxが360件、Windows Server 2016とWindows 10が357件で続く。1999年～2019年の通算ではDebian Linux(3,067件)が最も多く、Android(2,563件)とLinuxカーネル(2,357件)、Mac OS X(2,212件)が続いている。

一方、ベンダー別で2019年に最も多くの脆弱性が報告されたのはMicrosoft(668件)で、Google(609件)とOracle(489件)、Adobe(441件)が続く。1999年～2019年の通算でも1位はMicrosoft(6,814件)で、2位以下はOracle(6,115件)、IBM(4,679件)、Google(4,572件)の順となっている。1999年～2019年のデータでCVSSスコアの加重平均が最も高かったのはAdobe Flash Player(9.4)。以下、Adobe Acrobat(9.2)、Microsoft Office(9.1)、Adobe Acrobat Reader(8.9)の順になっている。

なお、英消費者保護団体Which?によると、Androidで2019年にセキュリティ更新が提供されたのはAndroid 7.0 Nougat以降のみだったという。昨年5月にGoogleが発表したAndroidプラットフォームバージョン別データでAndroid 2.3.x Gingerbread～Android 6.0 Marshmallowが合計42.10%を占めていることから、10億台以上の脆弱性が放置されたままだと指摘している(Which?の記事)。

Microsoftは22日、内部でカスタマーサポートのケースアナリティックスに使用するデータベースが昨年12月5日から31日まで誤設定により公開状態になっていたことを明らかにした(Microsoft Security Response Centerのブログ記事、 Comparitech Blogの記事、 Bob Diachenko氏のツイート、 Windows Centralの記事)。

Microsoftによれば、12月5日にデータベースのネットワークセキュリティグループを変更した際、誤って設定されたセキュリティ規則が含まれていたのが原因だという。発見者のBob Diachenko氏から通知を受け、12月31日には設定を修正して承認されていないアクセスを防ぐ措置をとったとのこと。Microsoftは影響を受けたレコードの件数を示していないが、Diachenko氏によればデータは2005年から2019年12月にわたる2億5千万件近いもので、Webブラウザーから認証なしでアクセスできる状態だったという。

Diachenko氏が問題を発見後すぐにMicrosoftへ知らせたところ、24時間以内に修正が行われたとのことで、大みそかにも関わらず迅速な対応を行ったMicrosoftのサポートチームをDiachenko氏は称賛している。なお、データのほとんどは匿名化されているが、Microsoftによれば「@」の前後にスペースの入った電子メールアドレスなど、標準的な形式で表記されていないデータは匿名化されていなかった可能性もあるとのことだ。

taraiok曰く、

大手DNA検査会社の「23andMe」と「DNA Ancestry」は、ユーザーから集めた遺伝情報を非公開にすることを長い間誓約してきた。また、DNA情報を元にした家系図作成サービス「GEDmatch」も、以前は警察に協力したこともあったものの、現在では警察によるアクセスを制限する方針に転換している。しかしフロリダ警察はGEDmatchの持つ100万人近いユーザーデータベースを検索するために裁判所から令状を取得したと発表した（The New York Times、Slashdot）。

ニューヨーク大学の法学教授であるエリン・マーフィー氏は、「これは大きなゲームチェンジャーとなる」と語った。GEDmatchは、法執行機関を排除する決定を下したにも関わらず、裁判所によって覆された。今回の裁判所の決定により、1000万人のユーザーを持つ「23andMe」や、1500万人のユーザーを持つ「Ancestry.com」に対しても、裁判所が同様の決定を下す可能性が高まったという。

23andMeの広報担当者は、「捜査令状や裁判所命令といった法的に有効なリクエストを受け取った場合を除き、法執行機関と顧客データを共有することはありません。お客様のプライバシーを保護するための努力を続けます」と述べている。

headless曰く、

シンバイオティクスサプリメントを販売する米Seed Healthが腸の健康診断AI「auggi」に学習させるためとして、便（大便）の写真を募集している（The Verge、特設サイト、利用規約、プライバシーポリシー）。

便の状態は健康状態を知るのに重要な役割を果たすが、医師や研究者が自力で調べるには退屈で時間がかかるだけでなく、不愉快でもある。Seedの目的は、多数の便の写真を用いて便の健康状態を学習させ、症状の追跡や分析を自動化することだという。auggiは既に粘土で作成した便のモデル30,000個を学習しており、ブリストル便性状スケールによる便のタイプ1～7に区分することが可能となっているそうだ。提供された写真を使用することで、識別能力をさらに向上させていくとのこと。

応募は特設サイトにモバイルブラウザーでアクセスした場合のみ可能となっており、「I accept the DARE」または「WILL YOU #GIVEASHIT FOR SCIENCE?」をタップすると応募フォームが表示される。写真はその場で撮影するほか、撮影済みのものを使用することも可能だ。実際に応募するには電子メールアドレスの入力と、普段の排便時刻の選択も必要となる。写真は匿名化して保存され、電子メールアドレスと結び付けられる心配はないとのことだ。

Anonymous Coward曰く、

新エネルギー・産業技術総合開発機構（NEDO）が、新たなリレーショナルデータベース開発プロジェクトを進めているという（日経xTECH）。

このプロジェクトはNECおよびノーチラス・テクノロジーズ、東京工業大学、大阪大学、名古屋大学、慶應義塾大学、パスコによって進められているもの。インターフェイスはPostgreSQL互換で、OLTPとOLAPの両方をサポートする。

ノーチラス・テクノロジーズによる日本PostgreSQLユーザー会での発表概要によると、「Project Tsurugi」という名前だそうだ。2019年時点での成果報告書も出ている。

中国・阿里巴巴（Alibaba）グループ傘下の螞蟻金融服務（Ant Financial）が開発した分散型リレーショナルデータベース「OceanBase」を用いたクラスタが、TPC-Cベンチマークで世界一を達成したという（AFP、Slashdot、TPC-Cのベンチマーク結果リスト）。

結果を見ると、AntFinancalの「Alibaba Cloud Elastic Compute Service Cluster」（データベースはOceanBase v2.2）のスコアは60,880,800で、2位の「SPARC SuperCluster with T3-4 Servers」（データベースはOracle Database 11g R2）のスコア（30,249,688）を大きく上回っている。

とはいえ、2位のシステムのスコア登録日は2010年12月2日であり、さらに2位以下で上位に入っているシステムのほぼ全てが最新の状況を表していない「歴史的な記録」とされているので、これだけで単純に性能を比較はできないと思われる。

Amazon.comが、同社の業務システムで使われていたOracleデータベースをAmazon Web Service（AWS）で提供されているデータベースサービスに移行する作業を行ったそうだ。Amazonの各種業務システムではOracleのデータベースが多用されていたそうだが、これによってほぼ「脱Oracle」ができたという（AWSの発表、TechCrunch、ZDNet Japan）。

同社は7500近くのOracleデータベースを使用していたが、それらのほとんどをAmazon DynamoDBやAmazon Aurora、Amazon Relational Database Service（RDS）、Amazon RedshiftといったAWSのサービスに移行したとのこと。移行したデータは75ペタバイトにも上るという。これによってデータベースに関連するコストは60％以上削減され、レイテンシも40％削減、管理コストは70％削減できたという。

Anonymous Coward曰く、

Amazon Web ServicesがSQLと互換性のあるデータクエリ言語「PartiQL」を発表した（Publickey）。

KVSやJSONでも使えるというのは便利そうである。SQL界隈の地殻変動となるか？

構文はSQLをベースにしているが、さまざまなデータソースに対応し、JSONのような構造化データも扱えるのが特徴。仕様はGitHubで公開されている。

Slackは18日、2015年3月に発生したセキュリティインシデントに関連して新たな情報が得られたとして、全アカウントの約1％でパスワードをリセットすることを発表した(The Official Slack Blogの記事、 HackReadの記事、 The Registerの記事、 ZDNetの記事)。

2015年3月のインシデントは、ハッシュされたパスワードを含むSlackユーザーの情報を格納したデータベースが不正にアクセスされ、攻撃者はSlackのWebサイトでログインする際に入力したパスワードを平文で取得するコードを挿入(当時の発表には記載なし)していたというものだ。

今回、報奨金プログラムを通じてSlackの認証情報侵害の可能性が指摘されたが、当初はマルウェア攻撃やパスワードの再利用によるものだと考えられていた。しかし調査を進めた結果、侵害された認証情報の多くが2015年のインシデント発生中にSlackにログインしたアカウントのものだと判明したという。

パスワードリセットの対象となるのは、2015年3月以前に作成されたアカウントであり、それ以来パスワードを変更しておらず、シングルサインオンの使用が必須になっていないアカウントとのこと。ただし、1%といってもSlackのユーザー数は1,000万人にのぼることから、10万人程度が影響を受けるとみられている。

6月7日に大阪市のシステムで障害が発生するトラブルがあったが（過去記事）、このトラブルの発端は同システムが採用していたOracle Databaseのシステムファイル破損だったと日経xTECHが報じている。

データベースはOracleのデータベースクラスタ技術「Oracle Real Application Clusters」を使って2重化されていたが、2ノードが稼働していたデータベースサーバーがほぼ同時に停止。調査を行ったところ、同じシステムファイルが破損していたことが分かったという。システムファイルを復旧させたところ、データベースは復旧したそうだ。

同じシステムファイルがなぜほぼ同時に破損したかは不明だという。