एक उत्पादन वातावरण में डिबग प्रतीकों (पीडीबी फ़ाइल) को तैनात करने का जोखिम क्या है?

Question

मेरे पास एक एप्लिकेशन है जो अपवाद स्टैक निशान को लॉग करता है और मैं चाहता था कि उन स्टैक के निशान को फ़ाइल नाम और लाइन नंबर शामिल करें जब उत्पादन में तैनात किया गया हो। मुझे पता चला कि डिबग प्रतीकों w / असेंबली को कैसे परिनियोजित किया जाए, लेकिन इस समस्या पर शोध करने की प्रक्रिया में मैं इस प्रश्न से परे चला गया , जिसका तात्पर्य यह है कि pdb फ़ाइलों को उत्पादन परिवेश में शामिल करना एक अच्छा विचार नहीं है। स्वीकृत उत्तर के लिए एक टिप्पणी कहती है, "... डिबगिंग जानकारी संवेदनशील डेटा को दूर कर सकती है और एक हमला वेक्टर हो सकती है। यह निर्भर करता है कि आपका ऐप क्या है।"

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

संपादित करें: अनुवर्ती प्रश्न / स्पष्टीकरण

इसलिए अब तक सभी के उत्तरों के आधार पर, ऐसा लगता है कि इस प्रश्न को .NET अनुप्रयोगों के लिए थोड़ा सरल बनाया जा सकता है। माइकल मैडॉक्स के उत्तर में मुझ पर लीक किए गए जॉन रॉबिंस ब्लॉग से यह बिट :

एक .NET PDB में केवल जानकारी के दो टुकड़े होते हैं, स्रोत फ़ाइल नाम और उनकी लाइनें और स्थानीय चर नाम। अन्य सभी जानकारी पहले से ही .NET मेटाडेटा में है, इसलिए PDB फ़ाइल में समान जानकारी को डुप्लिकेट करने की आवश्यकता नहीं है।

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

Comments

@ मैट: यह एक डेस्कटॉप अनुप्रयोग है, वेब, कॉम्पैक्ट या ...?

— Kb

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

— मैट

Answer 1

यहाँ एक और सवाल है:

क्या कोई सुरक्षा समस्याएँ हैं जो PDB डीबग फ़ाइलों को लाइव सर्वर पर छोड़ रही हैं?

और पीडीबी फाइलों पर अधिक जानकारी:

पीडीबी फाइलें: हर डेवलपर को क्या पता होना चाहिए

सामान्य तौर पर, मैं हमेशा अपनी तैनाती में pdb फाइलों को शामिल करता हूं, लाभ को अनदेखा करना बहुत बड़ा है।

यदि आप कभी भी अपने उपयोगकर्ताओं (और आमतौर पर आपको ऐसा नहीं करना चाहिए) के स्टैक ट्रेस को उजागर नहीं करते हैं, तो पीडीबी फ़ाइलों को तैनात करने का कोई अतिरिक्त सुरक्षा जोखिम नहीं है।

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

एक बड़ा सुरक्षा खतरा परावर्तक की तरह कुछ है जो आपके DLL पर उपयोग किए जाने पर उन्हें आपके स्रोत कोड को देखने के लिए, pdb फ़ाइलों के साथ या उसके बिना अनुमति देगा।

Comments

लिंक के लिए धन्यवाद। तो ऐसा लगता है कि समीकरण का कम से कम हिस्सा है, जहां एप्लिकेशन तैनात है (यानी डेस्कटॉप वी। वेब सर्वर)।

— मैट

Answer 2

यदि आप अपने संगठन में एक उत्पादन एनवायरनमेंट के लिए तैनात कर रहे हैं, तो यह एक सुरक्षा समस्या नहीं है।

यदि आप अपना सॉफ़्टवेयर अन्य संस्थाओं को बेच रहे हैं, तो .pdb फ़ाइल रिवर्स इंजीनियरिंग में रुचि रखने वाले व्यक्ति को एक पैर दे सकती है - जो आपके लिए समस्या हो सकती है या नहीं।

हालाँकि (स्पष्ट होने के लिए), आप नहीं चाहते कि आपके स्टैक के निशान क्लाइंट को प्रदर्शित हों - चाहे .pdbs उपलब्ध हों या नहीं। लेकिन अगर आप केवल निशान लॉग कर रहे हैं और ग्राहक को एक 'सुंदर' त्रुटि पृष्ठ पेश कर रहे हैं, तो यह कोई समस्या नहीं है।

Comments

मैं। मैट के बारे में बात कर रहा हूँ। एक पीडीबी से ऐसी कौन सी अतिरिक्त जानकारी मिल सकती है जो लुट्ज़ रिफ्लेक्टर जैसे उपकरण के माध्यम से पहले से उपलब्ध नहीं है?

— लार्स ट्रूजेंस

स्रोत और लाइन की जानकारी तुरंत मन में कूद जाती है। मुझे विश्वास नहीं होता कि मेटाडेटा में स्थानीय चर नाम मौजूद हैं।

— माइकल

@ लार्स - मैंने कभी नहीं कहा कि यह मदद करेगा :) मुझे लगता है कि पीडीबी और रिवर्स इंजीनियरिंग के आसपास यह पूरा डर बहुत गलत है। जो व्यक्ति PDB के रिवर्स इंजीनियर का उपयोग कर सकता है, वह एक सभ्य डिस्समेंबलर का उपयोग कर सकता है जो एनोटेशन का समर्थन करता है।

— माइकल

मैं देख सकता हूं कि बहुत लंबी विधियों में स्थानीय चर नाम कैसे रिवर्स इंजीनियरिंग में मदद कर सकते हैं, लेकिन स्रोत फ़ाइल नाम और लाइन जानकारी? अगर आप मुझसे पूछें तो रिफ्लेक्टर जैसे उपकरणों की तुलना में वास्तविक जोखिम नहीं है :)

— लार्स ट्रूजेंस

@ लार्स - मुझे लगता है कि माइकल मैडॉक्स और जो मैं कह रहा हूं, उसे व्यक्त करने का एक और तरीका है। जो किसी के पास असेंबली है, उसे .pdbs देना वास्तव में सुरक्षा जोखिम नहीं है। एक स्टैक ट्रेस उपलब्ध कराने के लिए जो assmeblies नहीं है उपलब्ध हो सकता है।

— माइकल बूर

Answer 3

डिबगिंग प्रतीकों के होने से, एक हमलावर ब्याज के वैश्विक चर, फ़ंक्शन ऑफ़सेट आदि का निर्धारण कर सकता है।

तो वह देख सकता है कि आपके सिस्टम में एक फ़ंक्शन है:

AddAdminUser(string name, string password);

और इसकी भरपाई जानते हैं। यदि आपके कार्यक्रम से छेड़छाड़ की जाती है, तो वह खुद को विशेषाधिकारी देने के लिए इस समारोह को बुला सकता है।

या ऐसा कुछ:

typedef enum {Basic, NTLM} AuthenticationMode;
AuthenticationMode g_authenticationMode;

और जानता है कि अपने एप्लिकेशन को असुरक्षित मोड में स्विच करने के लिए किस बिट को फ्लिप करना है।

वैकल्पिक रूप से, यह पता लगाने के लिए इंजीनियरिंग का थोड़ा सा समय लगेगा। हालांकि, समय की एक दुर्गम राशि नहीं है।

परंतु । । । इसका अर्थ है कि आपका हमलावर पहले से ही ऐसी स्थिति में है जहां वह आपके कार्यक्रम से समझौता कर सकता है। अगर ऐसा है, तो आप पहले ही हार गए।

यदि आपके पास पीडीबी प्रतीकों को तैनात करने का एक अच्छा व्यावसायिक कारण है, तो आगे बढ़ें। PDB की तैनाती आपको असुरक्षित नहीं बनाएगी। यदि आपके पास तैनात करने का एक अच्छा कारण नहीं है, तो आपको ऐसा नहीं करना चाहिए क्योंकि यह हमलों को थोड़ा आसान बना देगा।

आप सार्वजनिक पीडीबी फाइलें भी बना सकते हैं - ये स्ट्रिप कुछ जानकारी के टुकड़े हैं, लेकिन स्टैक ट्रेस उत्पन्न करने और बुनियादी डिबगिंग करने के लिए आपको पर्याप्त प्रतीक देते हैं। विवरण यहाँ हैं । Microsoft सभी के उपयोग के लिए अपने प्रतीक सर्वर पर सार्वजनिक पीडीबी को तैनात करता है।

संपादित करें: मैंने जो कहा है, उनमें से अधिकांश पीडीबी को देशी कोड के लिए तैनात करने के आस-पास की चिंताओं पर लागू होता है - मुझे लगता है कि इन चिंताओं को बहुत से लोग .NET पर भी ले जाते हैं, हालांकि विधानसभा मेटाडेटा इस बारे में पहले से ही काफी कुछ बताता है।

Comments

मेरा मानना ​​है कि मैट .Net के बारे में बात कर रहा है। आप पहले से ही एक पीडीबी के बिना भी लुट्ज़ रिफ्लेक्टर जैसे उपकरण से सभी स्रोत प्राप्त कर सकते हैं।

— लार्स ट्रूजेंस

@ लार्स - मेरी टिप्पणी को कॉल करने के लिए अद्यतित करें कि इसमें से अधिकांश मूल कोड है। मुझे लगता है कि बहुत से लोगों को बस एक तर्कहीन डर है कि पीडीबी रिवर्स इंजीनियरिंग को संभव बनाता है, और मानता है कि हमलावरों को पता नहीं है कि आईडीए प्रो जैसे डिसबेंबलर्स का उपयोग कैसे किया जाए। मेरा मानना ​​है कि इन आशंकाओं को गलत तरीके से प्रबंधित कोड में भी लाया जाता है।

— माइकल

Answer 4

कोई आपके एप्लिकेशन के पूर्ण स्रोत कोड को "पुनर्स्थापित" कर सकता है। अगर यह ओपन सोर्स है तो आपको चिंता करने की जरूरत नहीं है। यदि इसमें कुछ आईपी (एल्गोरिदम, सुरक्षा, लाइसेंस) हैं, तो यह शायद एक अच्छा विचार नहीं है।

यह सही है कि रिफ्लेक्टर जैसे उपकरण पीडीबी फाइलों के बिना भी आपके कोड के कुछ हिस्सों को फिर से बना सकते हैं, लेकिन ऑबफ्यूजन मदद कर सकते हैं (ठीक है, बस थोड़ा सा)।

Comments

मेरा मानना ​​है कि मैट .Net के बारे में बात कर रहा है। आप पहले से ही एक पीडीबी के बिना भी लुट्ज़ रिफ्लेक्टर जैसे उपकरण से सभी स्रोत प्राप्त कर सकते हैं।

— लार्स ट्रूजेंस

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

— db_