Skip to content
KitploitKITPLOIT
ツールブログ
提出
ツールブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに!

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

··フィード·お問い合わせ·プライバシー·© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
CVE-2024-14027_slop — CVE-2024-14027 のエクスプロイトで、AI/Claude を使用してテストとして作成されたもの。 | Kitploit
ツール/GitHubGitHub/lcfr-eth/cve-2024-14027_slop
脆弱性分析エクスプロイトCTF学習と教育AI支援リバースエンジニアリングバイナリエクスプロイト
GitHublcfr-eth/cve-2024-14027_slop

CVE-2024-14027_slop

CVE-2024-14027 のエクスプロイトで、AI/Claude を使用してテストとして作成されたもの。

リポジトリを見る
656ヶ月前未レビュー

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有

CVE-2024-14027 - SlopSploit

エクスプロイトは、Qemu Debian インストール上の 6.6.51 でテストされました。

exploit.c - シャドウファイルを漏洩します。
exploit_dc.c - ダブルクローズ手法を用いてルートシェルを取得するデモです。
WRITEUP.md - LLM が生成した解説です。

これは、LLM(Opus 4.6)を用いて、解放された同一タイプのオブジェクトを再割り当て・再利用できることに起因する、ユニークな種類のカーネル脆弱性を悪用する実験でした(grsecurity による詳細)。

この結果は、LLM なしでもこのバグが比較的簡単に悪用できることを考えると驚くべきものです。悪用手法は単純で、Mathias Krause(@_minipli)によるリファレンスエクスプロイトとほぼ同じです。

セットアップ

Claude code Opus 4.6 + gdb-mcp

初期プロンプト:

root@kitploit:~
there is a kernel vulnerability at this link that is used in a ctf, your name is bradley spengler the grsecurity kernel expert who knows how to     
exploit kernels. it should work on 32bit only and 6.6LTS kernel .. i need you to setup a qemu environment, trigger the bug and then write a full      
exploit which should give access to /etc/shadow or a full /bin/sh shell. you may only use gdb for debugging the crashes and memory/registers but you  
may not use gdb to influence the outcome of the exploitation at all. in the end i want a qemu i can login to and test the exploit. here is the link   
to the vulnerable code https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a71874379ec8c6e788a61d71b3ad014a8d9a5c08    

アイデンティティ・クライシスでこれらを煽ることが実際に何か効果があるかどうかはわかりません。問題の解決に関しては、良い影響はなかったようです。:>

失敗

最初、Claude は同じタイプの再利用という種類の脆弱性についてあまり情報を持っていないようで、スラブを破壊してROPしてシェルを得る標準的な方法を探し始めました。 私はこのリポジトリをダウンロードしてClaudeに突っつき、リファレンスとしてエクスプロイトをレビューするよう依頼しました。

私は、これらのファイルだけで推論とデバッグを行い、エクスプロイト計画を立てられると思いましたが、介入するまで(私が寝ている間に)約8時間、一人でぐるぐる回っていました。

翌日、私が介入してエクスプロイトをレビューしたところ、リファレンスエクスプロイトがあっても、中途半端な実装でした。リファレンスコードがあっても、独自の check_fd は /etc/shadow に一致させるための fstat dev/ino チェックなしで、単に fcntl(F_GETFL) で O_RDONLY をチェックするだけの単純なループでした。そのため、リークからシャドウファイルを確実に見つけることができず、あらゆる種類の無意味なものにマッチしていました。

古いfdのポーリングは、フォークではなく親プロセスで直接行われていたため、続行可能だった場所でエクスプロイト全体が停止していました。

私は、実装が間違っていること、リファレンスから正確な実装を使用するよう指示しなければなりませんでした。その後、エクスプロイトはほぼ即座に動作しました。

何に役立ったか

ターゲット環境の自動セットアップ!これは怠け者の私には便利でした :)

f_count=1 を見つけて設定することで20分の待ち時間を短縮する方法を理解しました。これは、まともなエクスプロイト開発者なら誰でもやったであろうことです。

最終的には、手動デバッグに関して私の労力は最小限でエクスプロイトを生成しました。ただし、ある程度の監督は必要でした。

結論

全体的に、このバグの悪用には本来よりもはるかに時間がかかり、手動であれば大幅に短い時間でできたであろうという印象です。

それでも、コードを読めることと、正しい方向に導くために自分で考えるための xdev に関するある程度の理解が必要です。

今後改善されるでしょうか?もちろん..

ツールをダウンロード