
दो Linux page-cache-corruption LPEs (DirtyClone CVE-2026-43503, pedit COW CVE-2026-46331) के लिए शैक्षिक, रक्षात्मक किट: hardening, detection, verification, seccomp + validation harness. केवल detection और prevention — कोई exploit कोड नहीं। TLP:CLEAR।
दो लिनक्स पेज-कैश-भ्रष्टाचार स्थानीय विशेषाधिकार वृद्धियों — DirtyClone (CVE-2026-43503) और pedit COW (CVE-2026-46331) — के विरुद्ध होस्ट और कंटेनर पर बचाव का पता लगाएं, रोकथाम करें और सत्यापित करें।
यह एक शैक्षिक, रक्षात्मक सुरक्षा किट है। यह बताती है कि दोनों भेद्यताएँ syscall स्तर पर कैसे काम करती हैं और इसमें hardening, detection, verification तथा seccomp टूलिंग — साथ ही एक वैलिडेशन हार्नेस शामिल है जो सिद्ध करता है कि यह टूलिंग वास्तविक कर्नेल पर काम करती है। डिज़ाइन के अनुसार इसमें कोई exploit, shellcode या target offsets नहीं हैं।
दोनों CVE एक अविशेषाधिकारित स्थानीय उपयोक्ता को /usr/bin/su जैसे setuid-root बाइनरी के पेज-कैश (RAM
प्रति) को भ्रष्ट करके रूट बनने देते हैं — बिना डिस्क पर फ़ाइल को कभी छुए। यही इन्हें गुप्त बनाता है: फ़ाइल-अखंडता
निगरानी हरी रहती है, डिस्क फोरेंसिक में कुछ नहीं मिलता, और भ्रष्टाचार रिबूट पर साफ़ हो जाता है।
कर्नेल को पैच करना ही वास्तविक समाधान है। लेकिन रोलआउट विंडो के दौरान — और बाद में defense-in-depth के रूप में — आपको हमले के मार्ग बंद करने, हमले की श्रृंखला पर नज़र रखने और अपनी सुरक्षा-स्थिति सत्यापित करने की आवश्यकता है। यही यह किट प्रदान करती है, जिसमें हर नियंत्रण exploit श्रृंखला के एक प्रलेखित चरण से जुड़ा है ताकि आप देख सकें क्यों यह काम करता है।
दोनों बग एक ही दोष-वर्ग के हैं: कर्नेल एक ऐसे बफ़र में लिखता है जिसे वह निजी मानता है, जबकि वह बफ़र अभी भी साझा, फ़ाइल-समर्थित पेज-कैश मेमोरी द्वारा समर्थित है। दो संरचनात्मक द्वार दोनों श्रृंखलाओं के हर रूप को नियंत्रित करते हैं:
इसे upstream में स्थिर पॉइंट-रिलीज़ (DirtyClone ≥ 6.12.91 / 7.0.10; pedit COW 6.12.94 / 7.0.13) तथा विक्रेता
बैकपोर्ट में ठीक किया गया; mainline 7.1 अंतिम है। अपने कर्नेल की अपने डिस्ट्रो के ट्रैकर से पुष्टि करें — देखें
docs/analysis.md §8।
केवल Linux होस्ट। ये स्क्रिप्ट वास्तविक कर्नेल अवस्था पढ़ती और लिखती हैं। Hardening को अपने नियंत्रण वाले होस्ट पर चलाएँ; विनाशकारी वैलिडेशन हार्नेस को डिस्पोज़ेबल VM पर चलाएँ। देखें आवश्यकताएँ।
# 1. Preview the host containment changes (writes nothing)
sudo ./kit/harden-pagecache-lpe.sh --dry-run
# 2. Apply userns restrictions + vulnerable-module blocks
sudo ./kit/harden-pagecache-lpe.sh
# 3. Verify posture — run the functional probe as an UNPRIVILEGED user
sudo -u nobody ./kit/verify-pagecache-lpe.sh # exit: 0=PASS 1=WARN 2=FAIL
# 4. (Optional) Watch the attack chain live with eBPF
sudo bpftrace ./kit/detect-pagecache-lpe.bt
कंटेनरों के लिए, seccomp ओवरले (kit/seccomp-pagecache-lpe.json) लागू करें:
docker run --security-opt seccomp=kit/seccomp-pagecache-lpe.json <image>
नए हैं? START-HERE.md पढ़ें — मूल कारण से लेकर पूर्ण वैलिडेशन रन तक की एक निर्देशित,
व्याख्यान-शैली वॉकथ्रू।
.
├── START-HERE.md Guided walkthrough — the recommended entry point
├── docs/ The "why": analysis and operator guidance
│ ├── analysis.md Root-cause analysis, attack chains, detection engineering
│ ├── HARDENING-GUIDE.md Operator containment guide (host → systemd → Docker → Kubernetes)
│ └── plain-language-summary.md Gentler, plain-English overview of both bugs
├── kit/ The "what you run": four self-contained artifacts
│ ├── harden-pagecache-lpe.sh Apply host containment (sysctl + module blocks)
│ ├── verify-pagecache-lpe.sh Read-only posture check (PASS/WARN/FAIL)
│ ├── detect-pagecache-lpe.bt bpftrace/eBPF telemetry for the staging chain
│ └── seccomp-pagecache-lpe.json Container seccomp overlay denying the chain's syscalls
└── testkit/ The "proof": validation harness + SHOWCASE.md writeup
harden, verify): bash, sysctl, modprobe और unshare वाला एक
Linux होस्ट। Hardening के लिए root; verify प्रोब को गैर-root उपयोक्ता के रूप में चलाएँ।detect-pagecache-lpe.bt): root, bpftrace ≥ 0.16, और कर्नेल BTF
(/sys/kernel/btf/vmlinux)। किसी दिए गए कर्नेल पर कुछ kprobes इनलाइन हो सकते हैं — स्क्रिप्ट का हेडर
बताता है कि कैसे अनुकूलित करें।testkit/): एक डिस्पोज़ेबल Linux VM — यह वास्तविक कॉन्फ़िग लिखता है और कर्नेल मॉड्यूल
अनलोड करता है। EC2 लॉन्चर को AWS CLI v2 और jq चाहिए; किसी SSH का उपयोग नहीं होता (परिवहन AWS
SSM है)। macOS उपयोक्ता स्थानीय Docker स्मोक टेस्ट चला सकते हैं, लेकिन पूर्ण वैलिडेशन के लिए Linux आवश्यक है।TLP:CLEAR — सार्वजनिक, अप्रतिबंधित वितरण। यह रिपॉज़िटरी केवल detection और prevention के लिए है। इसमें जानबूझकर शामिल हैं:
…और जानबूझकर बाहर रखती है:
इस दृष्टिकोण की ईमानदार सीमाएँ — वैलिडेशन क्या सिद्ध करता है और क्या नहीं — testkit/SHOWCASE.md
§8 में प्रलेखित हैं। केवल उन्हीं सिस्टमों पर उपयोग करें जिनके आप स्वामी हैं या जिनके परीक्षण के लिए आप अधिकृत हैं।
Hardening रोकथाम है, इलाज नहीं: अपने कर्नेल को पैच करें।
START-HERE.md — निर्देशित वॉकथ्रू (यहीं से शुरू करें)docs/analysis.md — पूर्ण तकनीकी विश्लेषणdocs/plain-language-summary.md — दोनों बगों का एक सरल, सादे-अंग्रेज़ी अवलोकनIssues और pull requests का स्वागत है — देखें CONTRIBUTING.md। चूँकि नियंत्रण कई फ़ाइलों में
प्रतिबिंबित होते हैं (मॉड्यूल सूची, userns नॉब्स, detection बिटमैप), कृपया हमले की सतह बदलने से पहले उस गाइड में
sync invariants पढ़ें।
इसे Apache License 2.0 के अंतर्गत लाइसेंस प्राप्त है।
| द्वार | यह क्या है | नियंत्रण के रूप में मजबूती |
|---|
| 1. क्षमता मार्ग | CAP_NET_ADMIN अविशेषाधिकारित यूज़र नेमस्पेस (unshare(CLONE_NEWUSER|CLONE_NEWNET)) के माध्यम से प्राप्त किया गया | मज़बूत चोकपॉइंट — हर रूप, ज्ञात और अज्ञात, को यहाँ से गुज़रना होगा। इसे पहले बंद करें। |
| 2. मॉड्यूल सतह | कमजोर मॉड्यूल: act_pedit, esp4/esp6, rxrpc, xt_TEE, nf_dup_ipv4/nf_dup_ipv6 | Defense-in-depth — केवल ज्ञात प्रिमिटिव हटाता है; कोई नया sink इसे बायपास कर सकता है। |
| घटक | भूमिका |
|---|
docs/analysis.md | सत्य का स्रोत: मूल कारण, व्यवहारिक हमला श्रृंखलाएँ, detection engineering, hardening, तुलनात्मक तालिका। |
docs/HARDENING-GUIDE.md | होस्ट, systemd यूनिट, Docker/Podman और Kubernetes के लिए स्तरित रोकथाम। |
kit/ | चार प्रमुख उत्पाद। किसी होस्ट की सुरक्षा के लिए इस निर्देशिका को वहाँ कॉपी करें। |
testkit/ | वास्तविक कर्नेल पर पुनरुत्पादन-योग्य वैलिडेशन (स्थानीय Docker + डिस्पोज़ेबल EC2), और SHOWCASE.md — परीक्षण क्या सिद्ध करते हैं और क्या नहीं, इसका एक ईमानदार मूल्यांकन। |