🌵 👎🏽 🧚🏿 पीवीएस-स्टूडियो में झूठी सकारात्मक: कैसे खरगोश छेद गहरा जाता है 🤹🏽 🆕 🧒

यूनिकॉर्न PVS-Studio और GetNamedSecurityInfo

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

हम पीवीएस-स्टूडियो द्वारा उत्पन्न झूठी सकारात्मक की संख्या को कम करने के लिए कड़ी मेहनत करते हैं। दुर्भाग्य से, स्थैतिक विश्लेषक अक्सर बग से सही कोड बताने में असमर्थ होते हैं क्योंकि उनके पास पर्याप्त जानकारी नहीं होती है। इसलिए, गलत सकारात्मकता अपरिहार्य हैं। हालाँकि, यह कोई समस्या नहीं है क्योंकि आप विश्लेषक को आसानी से अनुकूलित कर सकते हैं ताकि 10 में से 9 चेतावनी वास्तविक कीड़े की ओर इशारा करें।

हालांकि झूठी सकारात्मकता एक बड़ी बात नहीं हो सकती है, हम कभी भी अपने निदान में सुधार करके उन्हें लड़ना बंद नहीं करते हैं। कुछ ज़बरदस्त झूठी सकारात्मक हमारी टीम द्वारा पकड़े जाते हैं; दूसरों को हमारे ग्राहकों और मुफ्त संस्करण उपयोगकर्ताओं द्वारा सूचित किया जाता है।

हमारे ग्राहकों में से एक ने हाल ही में हमें कुछ इस तरह से पढ़ने के लिए एक ईमेल भेजा है:

किसी कारण से, विश्लेषक का कहना है कि एक निश्चित सूचक हमेशा शून्य होता है, जबकि ऐसा नहीं है। इसके अलावा, एक परीक्षण परियोजना पर इसका व्यवहार अजीब और अस्थिर है: कभी-कभी यह एक चेतावनी जारी करता है, और कभी-कभी ऐसा नहीं होता है। यहाँ एक सिंथेटिक उदाहरण है जो उस झूठे सकारात्मक को पुन: पेश कर रहा है:

#include <windows.h> #include <aclapi.h> #include <tchar.h> int main() { PACL pDACL = NULL; PSECURITY_DESCRIPTOR pSD = NULL; ::GetNamedSecurityInfo(_T("ObjectName"), SE_FILE_OBJECT, DACL_SECURITY_INFORMATION, NULL, NULL, &pDACL, NULL, &pSD); auto test = pDACL == NULL; // V547 Expression 'pDACL == 0' is always true. return 0; }

यह अनुमान लगाना कठिन नहीं है कि हमारे उपयोगकर्ता इस तरह झूठी सकारात्मकता कैसे देखते हैं। GetNamedSecurityInfo फ़ंक्शन स्पष्ट रूप से चर pDACL के मान को संशोधित करता है। क्या डेवलपर्स को इस तरह के सरल मामलों के लिए हैंडलर बनाने से रोका गया? और हर सत्र में चेतावनी क्यों जारी नहीं की गई है? शायद यह विश्लेषक में एक बग है, कहते हैं, एक uninitialized चर?

काश ... एक स्थिर कोड विश्लेषक के उपयोगकर्ताओं का समर्थन करना आसान काम नहीं है, लेकिन ऐसा करना मेरी अपनी पसंद थी। इसलिए, मैंने अपनी आस्तीन उतारी और समस्या की जांच करने के लिए नीचे उतर गया।

मैंने GetNamedSecurityInfo फ़ंक्शन के विवरण की जांच करके और यह सुनिश्चित करना शुरू कर दिया है कि इसकी कॉल वास्तव में pDACL चर के मूल्य को संशोधित करती है। यहाँ 6 वें तर्क का वर्णन है:

ppDacl

एक वैरिएबल का एक पॉइंटर जो लौटाए गए सुरक्षा डिस्क्रिप्टर या NULL में DACL को एक पॉइंटर प्राप्त करता है यदि सुरक्षा डिस्क्रिप्टर में कोई DACL नहीं है। यदि आप DACL_SECURITY_INFORMATION ध्वज सेट करते हैं, तो लौटा हुआ सूचक मान्य है। साथ ही, यह पैरामीटर NULL हो सकता है यदि आपको DACL की आवश्यकता नहीं है।

मुझे पता है कि पीवीएस-स्टूडियो को स्पष्ट चेतावनी उत्पन्न किए बिना स्पष्ट रूप से ऐसे सरल कोड को संभालने में सक्षम होना चाहिए। उस समय, मेरा अंतर्ज्ञान पहले से ही मुझे बता रहा था कि मामला एक तुच्छ नहीं था और इसे हल करने में काफी समय लगने वाला था।

मेरी गलतफहमी की पुष्टि तब हुई जब मैं विश्लेषक के हमारे वर्तमान अल्फा संस्करण या उपयोगकर्ता के कंप्यूटर पर स्थापित संस्करण के साथ या तो झूठे सकारात्मक को पुन: पेश करने में विफल रहा। कोई फर्क नहीं पड़ता कि मैंने क्या किया, विश्लेषक चुप रहे।

मैंने क्लाइंट से मुझे उदाहरण कार्यक्रम के लिए उत्पन्न प्रीप्रोसेस आई-फाइल भेजने के लिए कहा। उसने ऐसा किया, और मैं अपनी जांच के साथ आगे बढ़ा।

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

यह भावना क्यों? आप देखते हैं, मुझे पूरी तरह से पता है कि दोनों विश्लेषक और V547 नैदानिक कार्य कैसे करते हैं। वहाँ बस कोई रास्ता नहीं है कि वे एक झूठी सकारात्मक उत्पन्न कर सकता है, कभी भी!

ठीक है, चलो कुछ चाय बनाते हैं और जारी रखते हैं।

GetNamedSecurityInfo फ़ंक्शन को कॉल निम्न कोड में फैलता है:

 ::GetNamedSecurityInfoW(L"ObjectName", SE_FILE_OBJECT, (0x00000004L), 0, 0, &pDACL, 0, &pSD);

यह कोड मेरे कंप्यूटर पर पहले से मौजूद आई-फाइल और उपयोगकर्ता द्वारा भेजी गई फाइल दोनों में समान है।

हम्म ... ठीक है, चलो इस फ़ंक्शन की घोषणा को देखें। यहाँ मैंने अपनी फ़ाइल में क्या पाया है:

 __declspec(dllimport) DWORD __stdcall GetNamedSecurityInfoW( LPCWSTR pObjectName, SE_OBJECT_TYPE ObjectType, SECURITY_INFORMATION SecurityInfo, PSID * ppsidOwner, PSID * ppsidGroup, PACL * ppDacl, PACL * ppSacl, PSECURITY_DESCRIPTOR * ppSecurityDescriptor );

सब तार्किक और स्पष्ट है। कुछ भी असामान्य नहीं है।

फिर मैं उपयोगकर्ता की फ़ाइल में जा रहा हूँ और ...

मैं जो देखता हूं वह हमारी वास्तविकता से संबंधित नहीं है:

 __declspec(dllimport) DWORD __stdcall GetNamedSecurityInfoW( LPCWSTR pObjectName, SE_OBJECT_TYPE ObjectType, SECURITY_INFORMATION SecurityInfo, const PSID * ppsidOwner, const PSID * ppsidGroup, const PACL * ppDacl, const PACL * ppSacl, PSECURITY_DESCRIPTOR * ppSecurityDescriptor );

ध्यान दें कि औपचारिक पैरामीटर pp Dacl को const के रूप में चिह्नित किया गया है।

WAT? WTF? WAT? WTF?

वह क्या है? यह यहाँ क्या कर रहा है?

ठीक है, कम से कम मुझे यह सुनिश्चित करने के लिए पता है कि विश्लेषक निर्दोष है और मैं इसके सम्मान की रक्षा कर सकता हूं।

तर्क एक स्थिर वस्तु का सूचक है। यह पता चला है कि, विश्लेषक के दृष्टिकोण से, GetNamedSecurityInfoW फ़ंक्शन पॉइंटर द्वारा संदर्भित ऑब्जेक्ट को संशोधित नहीं कर सकता है। इसलिए, निम्नलिखित कोड में:

 PACL pDACL = NULL; PSECURITY_DESCRIPTOR pSD = NULL; ::GetNamedSecurityInfo(_T("ObjectName"), SE_FILE_OBJECT, DACL_SECURITY_INFORMATION, NULL, NULL, &pDACL, NULL, &pSD); auto test = pDACL == NULL; // V547 Expression 'pDACL == 0' is always true.

pDACL वैरिएबल नहीं बदल सकता है, जो विश्लेषक सही तरीके से हमें चेतावनी देता है (अभिव्यक्ति 'pDACL == 0' हमेशा सच होता है।)

ठीक है, अब हम जानते हैं कि चेतावनी क्या ट्रिगर करती है। हम अभी भी नहीं जानते कि वह कॉन्स्टेबल कीवर्ड कहां से आया है। यह सिर्फ वहाँ नहीं हो सकता!

खैर, मेरे पास एक अनुमान है, और यह पुष्टि करता है कि मुझे इंटरनेट पर क्या मिल रहा है। यह गलत फ़ंक्शन विवरण के साथ फ़ाइल aclapi.h का पुराना संस्करण है। मैंने कुछ दिलचस्प लिंक भी चलाए हैं:

इसलिए, एक बार, aclapi.h फ़ाइल में एक फ़ंक्शन विवरण था (6.0.6002.18005-Windows DV):

 WINADVAPI DWORD WINAPI GetNamedSecurityInfoW( __in LPWSTR pObjectName, __in SE_OBJECT_TYPE ObjectType, __in SECURITY_INFORMATION SecurityInfo, __out_opt PSID * ppsidOwner, __out_opt PSID * ppsidGroup, __out_opt PACL * ppDacl, __out_opt PACL * ppSacl, __out_opt PSECURITY_DESCRIPTOR * ppSecurityDescriptor );

तब किसी ने pObjectName पैरामीटर के प्रकार को बदल दिया, लेकिन कॉन्स्टेबल कीवर्ड जोड़कर रास्ते के प्रकार को गड़बड़ कर दिया। और aclapi.h फ़ाइल (6.1.7601.23418-Windows 7.0) इस प्रकार समाप्त हुई:

 WINADVAPI DWORD WINAPI GetNamedSecurityInfoW( __in LPCWSTR pObjectName, __in SE_OBJECT_TYPE ObjectType, __in SECURITY_INFORMATION SecurityInfo, __out_opt const PSID * ppsidOwner, __out_opt const PSID * ppsidGroup, __out_opt const PACL * ppDacl, __out_opt const PACL * ppSacl, __out PSECURITY_DESCRIPTOR * ppSecurityDescriptor );

अब यह स्पष्ट था कि हमारे उपयोगकर्ता aclapi.h के उस गलत संस्करण के साथ काम कर रहे थे, जिसकी पुष्टि उन्होंने अपने ईमेल में की थी। मैं बग को पुन: उत्पन्न नहीं कर सका क्योंकि मैं हाल ही के संस्करण का उपयोग कर रहा था।

यह वही है जो निश्चित फ़ंक्शन विवरण नवीनतम aclapi.h फ़ाइल (6.3.9600.17415-Windows_8.1) में दिखता है।

 WINADVAPI DWORD WINAPI GetNamedSecurityInfoW( _In_ LPCWSTR pObjectName, _In_ SE_OBJECT_TYPE ObjectType, _In_ SECURITY_INFORMATION SecurityInfo, _Out_opt_ PSID * ppsidOwner, _Out_opt_ PSID * ppsidGroup, _Out_opt_ PACL * ppDacl, _Out_opt_ PACL * ppSacl, _Out_ PSECURITY_DESCRIPTOR * ppSecurityDescriptor );

PObjectName तर्क का प्रकार अभी भी वही है, लेकिन अतिरिक्त कास्ट चले गए हैं। सब फिर से अच्छा है, लेकिन वहाँ अभी भी कहीं बाहर उपयोग में टूट हेडर हैं।

मैं ग्राहक को वह सब समझाता हूं, और वह समस्या को हल करते हुए देखकर खुश होता है। इसके अलावा, उन्होंने पाया कि झूठे सकारात्मक नियमित रूप से क्यों नहीं हुए:

मुझे अब कुछ समय पहले इस परीक्षण परियोजना पर टूलसेट के साथ प्रयोग करना याद है। डीबग कॉन्फ़िगरेशन दृश्य स्टूडियो 2017 के लिए डिफ़ॉल्ट रूप से प्लेटफ़ॉर्म टूलसेट पर सेट किया गया था - "विज़ुअल स्टूडियो 2017 (v141)", जबकि रिलीज़ कॉन्फ़िगरेशन "विज़ुअल स्टूडियो 2015 - विंडोज एक्सपी (v140_xp)" पर सेट था। मैं कल ही कॉन्फ़िगरेशन के बीच स्विच कर रहा था, और चेतावनी दिखाई देगी और तदनुसार गायब हो जाएगी।

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

निष्कर्ष

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

हमारे ग्राहक बनें, और आपको मुझसे और मेरे साथियों से शीघ्र पेशेवर समर्थन प्राप्त करने की गारंटी है।

पीवीएस-स्टूडियो में झूठी सकारात्मक: कैसे खरगोश छेद गहरा जाता है

More articles: