विंडोज 10 में डीएचसीपी सिक्योरिटी: क्रिटिकल वल्नरेबिलिटी CVE-2019-0726 की खोज

चित्र: Pexels

विंडोज के लिए जनवरी के अपडेट जारी होने के साथ, डीएचसीपी ग्राहकों में गंभीर रूप से खतरनाक भेद्यता CVE-2019-0547 की खबर से जनता में हड़कंप मच गया। उच्च सीवीएसएस रेटिंग और तथ्य यह है कि माइक्रोसॉफ्ट ने तुरंत एक प्रदर्शन मूल्यांकन प्रकाशित नहीं किया, जिससे उपयोगकर्ताओं के लिए एक तत्काल सिस्टम अपडेट पर निर्णय लेना मुश्किल हो गया, जिसने ब्याज को गर्म कर दिया। कुछ प्रकाशनों ने यह भी सुझाव दिया कि एक सूचकांक की कमी को सबूत के रूप में व्याख्या की जा सकती है कि निकट भविष्य में एक कार्यशील शोषण दिखाई देगा।

MaxPatrol 8 जैसे समाधान उन नेटवर्क पर कंप्यूटर की पहचान कर सकते हैं जो विशिष्ट हमलों की चपेट में हैं। अन्य समाधान, जैसे पीटी एनएडी, ऐसे हमलों का स्वयं पता लगाते हैं। इसे संभव बनाने के लिए, उत्पादों में कमजोरियों का पता लगाने के लिए और इन उत्पादों पर हमलों का पता लगाने के लिए नियमों का वर्णन करना आवश्यक है। बदले में, यह संभव हो सके इसके लिए, प्रत्येक व्यक्तिगत भेद्यता के लिए यह पता लगाना आवश्यक है कि वेक्टर, इसके संचालन की विधि और स्थितियां, अर्थात्, ऑपरेशन से जुड़े सभी विवरण और बारीकियां। आम तौर पर विक्रेता साइटों या सीवीई में विवरण से संकलित किए जाने की तुलना में बहुत अधिक पूर्ण और गहन समझ की आवश्यकता होती है, जैसे:

भेद्यता प्रकट होती है क्योंकि ऑपरेटिंग सिस्टम मेमोरी में वस्तुओं को गलत तरीके से संसाधित करता है।

इसलिए, कंपनी के उत्पादों को डीएचसीपी में एक नव-निर्मित भेद्यता पर हमलों का पता लगाने के नियमों के साथ-साथ इसके द्वारा प्रभावित उपकरणों की पहचान करने के नियम, आपको विवरण को समझना चाहिए। द्विआधारी भेद्यता के मामले में, पैच-डिफरेंस का उपयोग अक्सर अंतर्निहित त्रुटियों में अंतर्दृष्टि प्राप्त करने के लिए किया जाता है, अर्थात, किसी एप्लिकेशन, लाइब्रेरी या विशिष्ट पैच के साथ ऑपरेटिंग सिस्टम के कर्नेल में किए गए परिवर्तनों की तुलना, इस त्रुटि को ठीक करने वाला अपडेट। लेकिन पहला चरण हमेशा टोही होता है।

नोट : भेद्यता के वर्णन पर सीधे जाने के लिए, अंतर्निहित डीएचसीपी अवधारणाओं को दरकिनार करते हुए, आप पहले कुछ पृष्ठों को छोड़ सकते हैं और सीधे "DecodeDomainSearchListData फ़ंक्शन" अनुभाग पर जा सकते हैं।

पैमाइश

हम खोज इंजन की ओर मुड़ते हैं और वर्तमान में ज्ञात सभी भेद्यता विवरणों को देखते हैं। इस बार विवरण की एक न्यूनतम है, और उनमें से सभी MSRC वेबसाइट पर मूल प्रकाशन से एकत्रित जानकारी के मुक्त जुलूस हैं। आंतरिक ऑडिट के दौरान Microsoft द्वारा खोजी गई त्रुटियों के लिए यह स्थिति काफी विशिष्ट है।

हमें प्रकाशन से पता चलता है कि हमें विंडोज 10 संस्करण 1803 के क्लाइंट और सर्वर सिस्टम में निहित प्रकार स्मृति भ्रष्टाचार की एक भेद्यता का सामना करना पड़ रहा है और उस समय खुद को प्रकट कर रहा है जब एक हमलावर एक डीएचसीपी ग्राहक को विशेष रूप से तैयार की गई प्रतिक्रिया भेजता है। पृष्ठ पर उस क्षण से कुछ दिनों के बाद, प्रदर्शन सूचकांक भी दिखाई देंगे:



जैसा कि आप देख सकते हैं, MSRC ने "2 - शोषण कम संभावना" का मूल्यांकन किया। इसका मतलब यह है कि उच्च संभावना के साथ एक गलती या तो बिल्कुल भी चालू नहीं होती है, या ऑपरेशन ऐसी कठिनाइयों से भरा होता है, जिस पर काबू पाने के लिए बहुत अधिक श्रम लागत की आवश्यकता होती है। माना जाता है कि Microsoft ऐसे अनुमानों को कम नहीं समझता है। यह आंशिक रूप से प्रतिष्ठा के नुकसान के जोखिम से प्रभावित होता है, और आंशिक रूप से कंपनी के भीतर प्रतिक्रिया केंद्र की कुछ स्वतंत्रता से प्रभावित होता है। इसलिए, मान लीजिए: चूंकि रिपोर्ट में शोषण के खतरे को इंगित नहीं किया गया है, इसलिए यह निश्चित रूप से है। वास्तव में, यह विश्लेषण पूरा कर सकता था, लेकिन यह डबल-चेक करने के लिए बहुत कम नहीं होगा और कम से कम यह पता लगाएगा कि भेद्यता क्या थी। अंततः, सभी निर्विवाद व्यक्तित्व के बावजूद, त्रुटियां खुद को दोहराती हैं और खुद को अन्य स्थानों पर प्रकट करती हैं।

उसी पृष्ठ से हम एक .msu संग्रह के रूप में दिए गए पैच (सुरक्षा अद्यतन) को डाउनलोड करते हैं, इसे अनपैक करते हैं और क्लाइंट पक्ष पर डीएचसीपी प्रतिक्रियाओं के प्रसंस्करण से संबंधित सबसे अधिक संभावना वाली फाइलों की तलाश करते हैं। हाल ही में, ऐसा करना और अधिक कठिन हो गया है, क्योंकि अपडेट अलग-अलग पैकेज के रूप में दिए जाने लगे हैं जो विशिष्ट त्रुटियों को ठीक करते हैं, लेकिन एकल संचयी पैकेज के रूप में जिसमें सभी मासिक सुधार शामिल हैं। इसने अतिरिक्त शोर को बढ़ा दिया, अर्थात, हमारे कार्य से संबंधित परिवर्तन नहीं।

फ़ाइलों के पूरे सेट के बीच, खोज में फ़िल्टर के लिए उपयुक्त कई पुस्तकालय मिलते हैं, जिनकी हम एक अप्रकाशित प्रणाली पर उनके संस्करणों के साथ तुलना करते हैं। Dhcpcore.dll लाइब्रेरी सबसे आशाजनक दिखती है। इस मामले में, BinDiff न्यूनतम परिवर्तन उत्पन्न करता है:



दरअसल, किसी एकल फ़ंक्शन में किए गए कॉस्मेटिक परिवर्तनों के अलावा - DecodeDomainSearchListData। यदि आप डीएचसीपी प्रोटोकॉल और इसके विकल्पों से अच्छी तरह से परिचित हैं जिनका उपयोग अक्सर नहीं किया जाता है, तो आप पहले से ही मान सकते हैं कि यह फ़ंक्शन सूची को संसाधित करता है। यदि नहीं, तो दूसरे चरण पर जाएं - प्रोटोकॉल का अध्ययन।

डीएचसीपी और इसके विकल्प

DHCP ( RFC 2131 | wiki ) एक एक्स्टेंसिबल प्रोटोकॉल है, जिसकी पुनःपूर्ति क्षमता विकल्प क्षेत्र द्वारा प्रदान की जाती है। प्रत्येक विकल्प को एक अद्वितीय टैग (संख्या, पहचानकर्ता), विकल्प में निहित डेटा द्वारा व्याप्त आकार और स्वयं डेटा द्वारा वर्णित किया जाता है। यह अभ्यास नेटवर्क प्रोटोकॉल के लिए विशिष्ट है, और प्रोटोकॉल में "प्रत्यारोपित" विकल्पों में से एक आरएफसी 3397 में वर्णित डोमेन खोज विकल्प है। यह डीएचसीपी सर्वर को क्लाइंट पर मानक डोमेन नाम अंत सेट करने की अनुमति देता है, जिसका उपयोग इस तरह से कॉन्फ़िगर किए गए कनेक्शन के लिए डीएनएस प्रत्यय के रूप में किया जाएगा।

उदाहरण के लिए, निम्नलिखित नाम अंत हमारे ग्राहक पर निर्धारित किए गए थे:

.microsoft.com .wikipedia.org 

फिर, डोमेन नाम से पता निर्धारित करने के किसी भी प्रयास में, DNS क्वेरीज़ इस सूची से बारी-बारी से तब तक प्रत्ययों को प्रतिस्थापित करेगी जब तक कि एक सफल प्रदर्शन नहीं मिलता है। उदाहरण के लिए, यदि उपयोगकर्ता ब्राउज़र के एड्रेस बार में आरयू में प्रवेश करता है, तो DNS क्वेश्चन सबसे पहले ru.microsoft.com के लिए उत्पन्न होंगे, फिर ru.wikipedia.org के लिए:



वास्तव में, आधुनिक ब्राउज़र बहुत स्मार्ट हैं, और इसलिए खोज इंजन को उन नामों के लिए पुनर्निर्देशित करते हैं जो FQDN के समान नहीं हैं। इसलिए, नीचे हम कम खराब उपयोगिताओं के निष्कर्ष को संलग्न करते हैं:



यह पाठक को लग सकता है कि यह भेद्यता है, क्योंकि DNS की जगह लेने की संभावना केवल एक डीएचसीपी सर्वर के साथ प्रत्यय है, जो नेटवर्क पर कोई भी उपकरण स्वयं के साथ की पहचान कर सकता है, डीएचसीपी के माध्यम से किसी भी नेटवर्क मापदंडों का अनुरोध करने वाले ग्राहकों के लिए खतरा है। । लेकिन नहीं: आरएफसी से निम्नानुसार, यह काफी वैध, प्रलेखित व्यवहार माना जाता है। वास्तव में, डीएचसीपी सर्वर स्वाभाविक रूप से उन विश्वसनीय घटकों में से एक है जो उन्हें एक्सेस करने वाले उपकरणों पर एक मजबूत प्रभाव डाल सकते हैं।

डोमेन खोज विकल्प

डोमेन खोज विकल्प की संख्या 0x77 (119) है। सभी विकल्पों की तरह, यह विकल्प संख्या के साथ एकल-बाइट टैग के साथ एन्कोडेड है। अधिकांश अन्य विकल्पों की तरह, टैग के तुरंत बाद आकार के बाद डेटा का एकल-बाइट आकार होता है। विकल्प उदाहरण डीएचसीपी संदेश में एक से अधिक बार मौजूद हो सकते हैं। इस स्थिति में, ऐसे सभी अनुभागों के डेटा को उस क्रम में संक्षिप्त किया जाता है जिसमें वे संदेश में दिखाई देते हैं।



प्रस्तुत उदाहरण में, RFC 3397 से लिया गया, डेटा को तीन खंडों में विभाजित किया गया है, प्रत्येक 9 बाइट्स। जैसा कि आप तस्वीर से देख सकते हैं, पूरी तरह से योग्य डोमेन नाम में उपडोमेन नाम, नाम की एकल-बाइट लंबाई के साथ एन्कोडेड हैं, तुरंत नाम के बाद। पूरी तरह से योग्य डोमेन नाम का एन्कोडिंग एक अशक्त बाइट (जो कि एक अशक्त आकार का उपडोमेन नाम है) के साथ समाप्त होता है।

इसके अलावा, विकल्प डेटा संपीड़न की सबसे सरल विधि का उपयोग करता है, या यों कहें, बस बिंदुओं को पीछे हटाता है। डोमेन नाम के आकार के बजाय, फ़ील्ड में मान 0xc0 हो सकता है। फिर अगला बाइट विकल्प डेटा की शुरुआत के सापेक्ष ऑफसेट सेट करता है, जिसका उपयोग डोमेन नाम के अंत की खोज के लिए किया जाना चाहिए।

इस प्रकार, इस उदाहरण में, दो डोमेन प्रत्ययों की एक सूची एन्कोडेड है:

 .eng.apple.com .marketing.apple.com 

DecodeDomainSearchListData फ़ंक्शन

इसलिए, डीएचसीपी विकल्प संख्या 0x77 (119) सर्वर क्लाइंट पर DNS प्रत्यय को कॉन्फ़िगर करने की अनुमति देता है। लेकिन विंडोज ऑपरेटिंग सिस्टम वाली मशीनों पर नहीं। Microsoft सिस्टम ने परंपरागत रूप से इस विकल्प को अनदेखा कर दिया है, इसलिए ऐतिहासिक रूप से DNS नामों का अंत, यदि आवश्यक हो, तो समूह नीतियों के माध्यम से लुढ़का हुआ था। यह हाल तक जारी रहा, जब विंडोज 10 की अगली रिलीज, संस्करण 1803, ने डोमेन खोज विकल्प के लिए प्रसंस्करण जोड़ा। Dhcpcore.dll में फ़ंक्शन के नाम को देखते हुए, जिसमें परिवर्तन किए गए थे, यह जोड़ा हैंडलर में है कि प्रश्न में त्रुटि निहित है।

काम पर लगना। हम कोड को थोड़ा कंघी करते हैं और निम्नलिखित का पता लगाते हैं। DecodeDomainSearchListData प्रक्रिया, नाम के अनुसार, सर्वर से प्राप्त संदेश के डोमेन खोज विकल्प से डेटा को डीकोड करता है। इनपुट में, यह पिछले पैराग्राफ में वर्णित तरीके से पैक किया गया डेटा सरणी प्राप्त करता है, और आउटपुट पर, यह एक शून्य-समाप्त स्ट्रिंग उत्पन्न करता है जिसमें अल्पविराम द्वारा अलग किए गए डोमेन नाम अंत की सूची होती है। उदाहरण के लिए, यह फ़ंक्शन एक स्ट्रिंग में ऊपर दिए गए उदाहरण से डेटा को परिवर्तित करता है:

  eng.apple.com,marketing.apple.com 

DecodeDomainSearchListData को UpdateDomainSearchOption प्रक्रिया से कहा जाता है, जो लौटी हुई सूची को रजिस्ट्री कुंजी के "DhcpDomainSearchList" मान पर सेट करती है:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{INTERFACE_GUID}\
एक विशिष्ट नेटवर्क इंटरफ़ेस के मुख्य मापदंडों को संग्रहीत करना।



DecodeDomainSearchListData दो पासों में पूरा होता है। पहली पास पर, यह आउटपुट बफर को लिखने के अलावा सभी क्रिया करता है। इस प्रकार, पहला पास लौटे डेटा को समायोजित करने के लिए आवश्यक मेमोरी के आकार की गणना करने के लिए समर्पित है। दूसरे पास पर, इस डेटा के लिए मेमोरी पहले से ही आबंटित है और आवंटित मेमोरी भरी हुई है। फ़ंक्शन छोटा है, लगभग 250 निर्देश हैं, और इसका मुख्य काम इनपुट स्ट्रीम में प्रस्तुत चरित्र के लिए तीन संभावित विकल्पों में से प्रत्येक को संसाधित करना है: 1) 0x00, 2) 0xc0, या 3) अन्य सभी मान। डीएचसीपी-संबंधित त्रुटि के लिए काल्पनिक फिक्स मूल रूप से दूसरे पास की शुरुआत में परिणामी बफर के आकार पर एक चेक जोड़ने के लिए नीचे आता है। यदि यह आकार शून्य है, तो मेमोरी को बफर के लिए आवंटित नहीं किया गया है और फ़ंक्शन तुरंत निष्पादन समाप्त करता है और एक त्रुटि देता है:



यह पता चलता है कि भेद्यता स्वयं उन मामलों में प्रकट होती है जहां लक्ष्य बफर का आकार शून्य है। उसी समय, निष्पादन की शुरुआत में, फ़ंक्शन इनपुट डेटा की जांच करता है, जिसका आकार दो बाइट्स से कम नहीं हो सकता है। इसलिए, ऑपरेशन के लिए डोमेन प्रत्ययों के गैर-खाली विकल्प का चयन इस तरह से करना आवश्यक है कि आउटपुट बफर का आकार शून्य हो।

शोषण

पहली बात जो दिमाग में आती है, वह यह है कि आप पहले बताए गए रिस्पर्स पॉइंट का उपयोग कर सकते हैं ताकि गैर-खाली इनपुट डेटा एक खाली आउटपुट उत्पन्न कर सके:



प्रतिक्रिया में इस तरह की सामग्री के साथ एक विकल्प भेजने के लिए कॉन्फ़िगर किया गया सर्वर वास्तव में गैर-अपडेट किए गए ग्राहकों पर पहुंच उल्लंघन का कारण होगा। यह निम्न कारणों से होता है। प्रत्येक चरण में, जब फ़ंक्शन पूरी तरह से योग्य डोमेन नाम का हिस्सा पार्स करता है, तो वह इसे लक्ष्य बफर में कॉपी करता है और इसके बाद एक डॉट डालता है। RFC से लिए गए उदाहरण में, डेटा को निम्नलिखित क्रम में बफर में कॉपी किया जाएगा:

 1). eng. 2). eng.apple. 3). eng.apple.com. 

फिर, जब डोमेन में शून्य डोमेन आकार होता है, तो फ़ंक्शन गंतव्य बफर के पिछले चरित्र को अल्पविराम से बदल देता है:

 4). eng.apple.com, 

और जारी रहता है:

 5). eng.apple.com,marketing. 6). eng.apple.com,marketing.apple. 7). eng.apple.com,marketing.apple.com. 8). eng.apple.com,marketing.apple.com, 

इनपुट के अंत में, यह केवल अंतिम कॉमा को एक शून्य चरित्र के साथ बदलने के लिए रहता है और आपको रजिस्ट्री को लिखने के लिए तैयार लाइन मिलती है:

 9). eng.apple.com,marketing.apple.com 

जब कोई हमलावर बताए गए तरीके से गठित बफर भेजता है तो क्या होता है? यदि आप उदाहरण देखते हैं, तो आप देख सकते हैं कि इसमें निहित सूची में एक तत्व शामिल है - एक खाली स्ट्रिंग। पहले पास पर, फ़ंक्शन आउटपुट डेटा के आकार की गणना करता है। चूंकि डेटा में एक भी गैर-शून्य डोमेन नाम नहीं है, इसलिए आकार शून्य है।

दूसरे पास पर, डायनामिक मेमोरी का एक ब्लॉक इसमें डेटा रखने और खुद डेटा कॉपी करने के लिए आवंटित किया जाता है। लेकिन पार्सिंग फ़ंक्शन तुरंत एक अशक्त चरित्र का सामना करता है, जो डोमेन नाम के अंत को दर्शाता है, और इसलिए, जैसा कि कहा गया था, पिछले चरित्र को एक बिंदु से एक अल्पविराम में बदल देता है। और यहाँ हम एक समस्या का सामना कर रहे हैं। लक्ष्य बफर पुनरावृत्ति स्थिति शून्य पर है। कोई पिछला चरित्र नहीं है। पिछला चरित्र डायनेमिक मेमोरी ब्लॉक के हेडर का है। और इसी वर्ण को 0x2c के साथ प्रतिस्थापित किया जाएगा, अर्थात् अल्पविराम के साथ।

हालाँकि, यह केवल 32-बिट सिस्टम पर होता है। लक्ष्य बफर की वर्तमान स्थिति को संग्रहीत करने के लिए अहस्ताक्षरित int का उपयोग x64 सिस्टम पर प्रसंस्करण के लिए समायोजन का परिचय देता है। आइए बफर पर अल्पविराम लिखने के लिए जिम्मेदार कोड के टुकड़े पर करीब से ध्यान दें:



यूनिट को 32-बिट ईएक्स रजिस्टर का उपयोग करके वर्तमान स्थिति से घटाया जाता है, जबकि बफर को संबोधित करते समय, कोड पूरे 64-बिट रक्स रजिस्टर तक पहुंचता है। AMD64 आर्किटेक्चर में, 32-बिट रजिस्टर के साथ कोई भी ऑपरेशन रजिस्टर के ऊपरी भाग को शून्य करता है। इसका मतलब यह है कि रक्स रजिस्टर में, जिसमें पहले शून्य था, घटाव के बाद, मान -1 नहीं, बल्कि 0xffffff संग्रहीत किया जाएगा। इसलिए, 64-बिट सिस्टम पर, 0x2c का मान पता buf [0xffffffff] को लिखा जाएगा, अर्थात्, बफर के लिए आवंटित मेमोरी की सीमाओं से परे।

प्राप्त डेटा Microsoft के प्रदर्शन मूल्यांकन के साथ अच्छे समझौते में है, क्योंकि इस भेद्यता का फायदा उठाने के लिए, एक हमलावर को सीखने की आवश्यकता है कि डीएचसीपी क्लाइंट पर दूरस्थ रूप से स्प्रे छिड़काव कैसे किया जाए और साथ ही पूर्वनिर्धारित मूल्यों को रिकॉर्ड करने के लिए गतिशील मेमोरी के आवंटन पर पर्याप्त नियंत्रण है, जैसे कि अल्पविराम। और शून्य बाइट, तैयार पते में उत्पादित और नियंत्रित नकारात्मक परिणामों के लिए नेतृत्व किया। अन्यथा, एक असत्यापित पते पर डेटा लिखने से svchost.exe प्रक्रिया में गिरावट आएगी, साथ ही वर्तमान में होस्ट की गई सभी सेवाओं के साथ, और ऑपरेटिंग सिस्टम द्वारा इन सेवाओं को फिर से शुरू किया जाएगा। एक तथ्य जो कुछ स्थितियों में हमलावर अपने लाभ के लिए उपयोग कर सकता है।

यह सब ऐसा लगता है कि जांच के तहत त्रुटि के बारे में कहा जा सकता है। केवल भावना यह रहती है कि यह अंत से दूर है। जैसे कि हमने सभी विकल्पों पर विचार नहीं किया। इन पंक्तियों में कुछ और छिपा होना चाहिए।

CVE-2019-0726

शायद यह जिस तरह से है। यदि आप त्रुटि के कारण डेटा के प्रकार को करीब से देखते हैं और इसकी तुलना करते हैं कि यह त्रुटि कैसे होती है, तो आप ध्यान देंगे कि डोमेन नामों की सूची को इस तरह से बदला जा सकता है कि परिणामस्वरूप बफर गैर-शून्य आकार होगा, लेकिन इसके बाहर लिखने का प्रयास वही किया जाएगा। ऐसा करने के लिए, सूची में पहला तत्व खाली स्ट्रिंग होना चाहिए, और अन्य सभी में सामान्य डोमेन अंत हो सकते हैं। उदाहरण के लिए:



प्रस्तुत विकल्प में दो तत्व शामिल हैं। पहला डोमेन प्रत्यय खाली है, यह तुरंत एक शून्य बाइट के साथ समाप्त होता है। दूसरा प्रत्यय है। आउटपुट पर गणना की गई रेखा का आकार तीन बाइट्स के बराबर होगा, जो लक्ष्य बफर की शून्यता पर जनवरी अद्यतन द्वारा लगाए गए चेक को दूर करने की अनुमति देगा। उसी समय, डेटा की बहुत शुरुआत में शून्य परिणामी स्ट्रिंग में पिछले वर्ण के साथ एक अल्पविराम लिखने के लिए फ़ंक्शन को बाध्य करेगा, लेकिन चूंकि स्ट्रिंग में इटरेटर की वर्तमान स्थिति शून्य है, जैसा कि ऊपर माना गया है, रिकॉर्डिंग फिर से आवंटित बफर के बाहर होगी।

अब अभ्यास में प्राप्त सैद्धांतिक परिणामों की पुष्टि करना आवश्यक है। हम ऐसी स्थिति का अनुकरण करते हैं जिसमें डीएचसीपी सर्वर क्लाइंट से अनुरोध के जवाब में प्रस्तुत विकल्प के साथ एक संदेश भेजता है, और परिणामी बफर लाइन के तहत आवंटित 0xffffffff स्थिति में अल्पविराम लिखने की कोशिश करते समय तुरंत एक अपवाद को पकड़ता है:



यहां, r8 रजिस्टर में आने वाले विकल्पों के लिए एक संकेतक होता है, rdi चयनित लक्ष्य बफर का पता है, और rax इस बफर में स्थिति है जहां चरित्र लिखा जाना है। हमें पूरी तरह से अपडेटेड सिस्टम (जनवरी 2019 तक) पर ऐसे परिणाम मिले।

हम Microsoft में खोजी गई समस्या के बारे में लिखते हैं और ... वे अक्षर खो देते हैं। हाँ, यह कभी-कभी सम्मानित विक्रेताओं के साथ भी होता है। कोई भी प्रणाली सही नहीं है, और इस मामले में आपको संचार के अन्य तरीकों की तलाश करनी होगी। इसलिए, एक हफ्ते बाद, इस समय के दौरान भी कोई स्वचालित प्रतिक्रिया प्राप्त किए बिना, हम सीधे ट्विटर के माध्यम से प्रबंधक से संपर्क करते हैं और आवेदन का विश्लेषण करने के कई दिनों के परिणामों के अनुसार, हमें पता चलता है कि भेजे गए विवरण का CVE-2019-0547 से कोई लेना-देना नहीं है और इसके लिए एक स्वतंत्र भेद्यता का प्रतिनिधित्व करते हैं। नया सीवीई पहचानकर्ता। एक महीने बाद, मार्च में, संबंधित सुधार सामने आता है, और त्रुटि संख्या CVE-2019-0726 प्राप्त करता है।

यह है कि आप कभी-कभी 1-दिन की भेद्यता के विवरण को गलती से अपने अंतर्ज्ञान पर भरोसा करके 0-दिन की खोज कर सकते हैं।

मिखाइल Tsvetkov, सकारात्मक टेक्नोलॉजीज अनुप्रयोग विश्लेषण विशेषज्ञ द्वारा पोस्ट किया गया ।