जीडीएममध्ये एक असुरक्षितता ओळखली गेली

एक सुरक्षा संशोधक GitHub द्वारे ते ज्ञात केले अलीकडे आपण एक असुरक्षितता ओळखली आहे (सीव्हीई -2020-16125) जीनोम डिस्प्ले मॅनेजर (जीडीएम) मध्ये, जी लॉगिन स्क्रीन प्रदर्शित करण्यासाठी जबाबदार आहे.

दुसर्या असुरक्षा सह एकत्रित खाते ट्रॅकिंग सेवेमध्ये (अकाउंट्स-डेमन), समस्या कोडला रूट म्हणून चालविण्यास परवानगी देते.  डीबसद्वारे खाते डेमन सेवेमध्ये प्रवेश करणे अशक्य असल्यास अशक्तपणा प्रारंभिक कॉन्फिगरेशन युटिलिटीच्या चुकीच्या लाँचशी संबंधित आहे.

असुरक्षा बद्दल

एक अनारक्षित वापरकर्ता खाते-डेमन प्रक्रियेस क्रॅश करू शकतो किंवा हँग अप, काय परिस्थिती निर्माण करेल जीडीएम वरून चालवण्यासाठी जीनोम-इनिशिअल-सेटअप युटिलिटीकरिता, ज्याद्वारे नवीन वापरकर्ता सुदो समूहाचा सदस्य म्हणून नोंदणी करू शकतो, म्हणजेच प्रोग्रामला रूट म्हणून चालविण्याची क्षमता आहे.

सामान्यतः प्रथम वापरकर्त्यास सेट करण्यासाठी जीडीएम जीनोम-इनिशियल-सेटअप कॉल करते सिस्टममध्ये कोणतीही खाती नसल्यास. खात्यांच्या अस्तित्वाची पडताळणी खाती-डिमनशी संपर्क साधून केली जाते. निर्दिष्ट प्रक्रिया अयशस्वी झाल्यास, जीडीएम खाती गहाळ असल्याचे गृहीत धरते आणि प्रारंभिक कॉन्फिगरेशन प्रक्रिया सुरू करते.

डेमन-अकाउंट्स प्रक्रियेत व्यत्यय आणण्याचे दोन मार्ग संशोधकांनी ओळखले- प्रथम (सीव्हीई -2020-16126) चुकीच्या विशेषाधिकार रीसेटमुळे आणि दुसर्‍या (सीव्हीई -2020-16127) ".pam_en पर्यावरण" फाईलवर प्रक्रिया करताना त्रुटीमुळे होते.

तसेच, डिमन खात्यांमध्ये आणखी एक असुरक्षितता आढळली (सीव्हीई -2018-14036) चुकीच्या फाईल पथ तपासणीमुळे आणि प्रणालीवर मनमानी फाइल सामग्री वाचण्याची परवानगी दिली.

अकाउंट्स-डिमन मधील असुरक्षा उबंटू विकसकांनी केलेल्या बदलांमुळे उद्भवली आहेत आणि फ्रीडेस्कटॉप प्रोजेक्टच्या मुख्य खाती-डेमन कोड आणि डेबियन पॅकेजमध्ये दिसत नाहीत.

सीबीई -2020-16127 अंक उबंटूमध्ये जोडलेल्या पॅचमध्ये उपस्थित आहे जो is_in_pam_en पर्यावरण कार्य करते, जो वापरकर्त्याच्या मुख्य निर्देशिकेतून .pam_en वातावरण फाईलमधील सामग्री वाचतो. आपण या फाईलऐवजी / देव / शून्यावर प्रतीकात्मक दुवा लावला तर खाते डेमन प्रक्रिया असीम वाचन ऑपरेशन्सवर टांगली जाते आणि डीबीसद्वारे विनंत्यांना प्रतिसाद देणे थांबवते.

आधुनिक ऑपरेटिंग सिस्टममध्ये असुरक्षिततेचे शोषण करणे इतके सोपे आहे. काही प्रसंगी मी असुरक्षिततेचे शोषण करण्यासाठी कोडच्या हजारो ओळी लिहिल्या आहेत. 

बर्‍याच आधुनिक शोषणात जटिल युक्त्या समाविष्ट असतात, जसे की ढीगमध्ये बनावट वस्तू खोडण्यासाठी मेमरी भ्रष्टाचाराची असुरक्षा वापरणे किंवा एखादी फाईल सिमलिंकने माइक्रोसेकंद अचूकतेत बदलून टच अगतिकतेचे शोषण करणे. 

म्हणून या दिवसात असुरक्षितता शोधणे फारच कमी आहे ज्याचा उपयोग करण्यासाठी कोडिंग कौशल्याची आवश्यकता नाही. मला असेही वाटते की उबंटू कार्य कसे करते याबद्दल किंवा सुरक्षा संशोधनातील अनुभव याबद्दल आपल्याला पूर्वीचे माहिती नसले तरीही असुरक्षा समजणे सोपे आहे.

सीव्हीई -2020-16126 असुरक्षा दुसर्‍या पॅचमुळे होते जे काही डीबीस कॉलवर प्रक्रिया करत असताना वर्तमान वापरकर्त्याच्या विशेषाधिकारांची पूर्तता करते (उदाहरणार्थ, org.freedesktop.Accounts.User.SetLanguage).

खाते डिमन प्रक्रिया सामान्यपणे मूळ म्हणून चालते, जी सामान्य वापरकर्त्यास सिग्नल पाठविण्यापासून प्रतिबंधित करते.

परंतु जोडलेल्या पॅचचे आभार, प्रक्रिया विशेषाधिकार रीसेट केले जाऊ शकतात आणि सिग्नल पाठवून ही प्रक्रिया समाप्त करू शकते. एखादा हल्ला करण्यासाठी, विशेषाधिकार (आरईयूडी) काढून टाकण्यासाठी अटी तयार करा आणि खाते डेमन प्रक्रियेस एक SIGSEGV किंवा SIGSTOP सिग्नल पाठवा.

वापरकर्ता ग्राफिकल सत्र समाप्त करतो आणि मजकूर कन्सोलवर जातो (Ctrl-Alt-F1)
ग्राफिकल सत्र संपल्यानंतर, जीडीएम लॉगिन स्क्रीन प्रदर्शित करण्याचा प्रयत्न करते, परंतु अकाउंट्स-डिमनकडून प्रतिसाद मिळविण्याचा प्रयत्न करताना लटकते.

SIGSEGV आणि SIGCONT सिग्नल कन्सोल वरून खाते डेमन प्रक्रियेस पाठविले जातात, ज्यामुळे ते स्तब्ध होते.

ग्राफिकल सत्रातून बाहेर पडण्यापूर्वी आपण सिग्नल देखील पाठवू शकता, परंतु सत्र समाप्त होण्यास विलंब करून आणि सिग्नल पाठविण्यापूर्वी जीडीएमला सुरू होण्यास वेळ मिळाला पाहिजे.

जीडीएम मधील खाती डिमनची विनंती अपयशी ठरते आणि जीडीएम युटिलिटीला जीनोम-इनिशिएल-सेटअप कॉल करते, ज्याच्या इंटरफेसमध्ये हे नवीन खाते तयार करण्यासाठी पुरेसे आहे.

असुरक्षा जीनोम 3.36.2.२ आणि 3.38.2.२ मध्ये निश्चित केली आहे. उबंटू आणि त्याच्या डेरिव्हेटिव्ह्जमध्ये असुरक्षिततेच्या शोषणाची पुष्टी केली गेली आहे.

स्त्रोत: https://securitylab.github.com