過去数日間、 研究者グループがとった行動に関する事例 ミネソタ大学から、多くの観点から、Linuxカーネルの脆弱性の導入に関連するそのようなアクションには正当化がありません。
そして、グループにもかかわらず ミネソット大学の研究者公開謝罪の手紙を発行するには、 によってブロックされたLinuxカーネルへの変更の受け入れ グレッグクローハートマンが詳細を明らかにした カーネル開発者に提出されたパッチの数と、これらのパッチに関連するメンテナとのやり取り。
注目に値するのは 問題のあるパッチはすべて拒否されました メンテナの主導で、パッチはどれも承認されませんでした。 この事実は、パッチがメンテナによって承認された場合に研究者が何をしたかが不明であるため、グレッグクローハートマンがなぜそれほど厳しく行動したのかを明らかにしています。
振り返ってみると、 彼らはバグを報告するつもりであると主張した パッチをGitに送信することは許可されませんが、実際に何を実行するのか、どこまで移動できるのかは不明です。
合計で、2020年XNUMX月に、匿名アドレスacostag.ubuntu@gmail.comとjameslouisebond@gmail.com（James Bondからの手紙）からXNUMXつのパッチが送信されました。脆弱性。
各パッチには、1〜4行のコードしか含まれていませんでした。 悪いパッチの背後にある主な考えは、メモリリークを修正すると、ダブルフリーの脆弱性の条件が作成される可能性があるというものでした。
このプロジェクトは、OSSのパッチ適用プロセスのセキュリティを向上させることを目的としています。 プロジェクトの一環として、問題の原因や問題に対処するための提案など、OSSパッチ適用プロセスの潜在的な問題を調査します。
実際、この研究はいくつかの問題を明らかにしていますが、その目的は改善のための努力を呼びかけることです
パッチをテストおよび検証する手法を開発し、最終的にOSをより安全にするために、より多くの作業を動機付けるパッチ適用プロセス。これらのパッチに基づいて、パターンを要約し、バグ導入パッチをキャッチするのが難しい具体的な理由を調査し（定性分析と定量分析の両方で）、最も重要なこととして、問題に対処するための提案を提供します。
最初の問題のあるパッチは、kfree（）への呼び出しを追加することでメモリリークを修正しました エラーが発生した場合に制御を返す前ですが、解放された後（解放後使用）にメモリ領域にアクセスするための条件を作成します。
指定されたパッチはメンテナによって拒否されました、は問題を特定し、XNUMX年前に誰かがすでに同様の変更を提案しようとし、最初は受け入れられたが、脆弱性の状態を特定した後、同じ日に破棄したことを示しました。
XNUMX番目のパッチには、リリース後の摩耗の問題の条件も含まれていました。 指定されたパッチは、list_add_tailの別の問題のためにパッチを拒否したメンテナによって受け入れられませんでしたが、dev_errの呼び出しで次に使用されるput_device関数で「chdev」ポインタを解放できることに気づきませんでした（＆ chdev-> dev ..）。 ただし、脆弱性とは関係のない理由にもかかわらず、パッチは受け入れられませんでした。
不思議なことに、 当初、4つのパッチのうち5つに問題があると想定されていましたが、 しかし、研究者自身が間違いを犯し、問題のあるパッチで、彼らの意見では、起動後にメモリを使用するための想定される条件なしで、正しい解決策が提案されました。
この作品では、脆弱性の条件が欠けている「未熟な脆弱性」の概念を提示しますが、条件が暗黙的にある場合、それは実際のものになる可能性があります
別のバグのパッチによって導入されました。また、問題が発生する可能性のあるコードの場所を見つけるのに役立つツールも開発しています。
バグ導入パッチの一覧を表示し、これらのバグ導入パッチの検出を困難にする原因を提案します。XNUMX週間後、メモリリークの些細な修正を装って脆弱性を促進する可能性について議論する提案とともに、情報がカーネル開発者に送信されましたが、悪意のあるパッチを送信する以前の試みについては何も言われていませんでした。
XNUMX番目のパッチも、脆弱性のない別のバグ（pdevの二重アプリケーション）のためにメンテナによって拒否されました。