क्या केन थॉम्पसन का कंपाइलर हैक अब भी खतरा है?

Question

केन थॉम्पसन हैक (1984)

केन थॉम्पसन ने 1984 में एक कंपाइलर बाइनरी (और एक * nix सिस्टम पर एक लॉगिन स्क्रिप्ट की तरह) को संकलित करने के लिए एक विधि की रूपरेखा दी। मुझे यह जानने की उत्सुकता थी कि क्या आधुनिक संकलन ने इस सुरक्षा दोष को संबोधित किया है या नहीं।

संक्षिप्त वर्णन:

2 खामियों को रोकने के लिए संकलक कोड को फिर से लिखें:

• अपने स्वयं के बाइनरी को संकलित करते समय, संकलक को इन दोषों को संकलित करना होगा
• जब कुछ अन्य छपे हुए कोड (लॉगिन फंक्शन) को संकलित करना होता है, तो कुछ मनमाने पिछले दरवाजे को संकलित करना होगा

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

प्रशन:

मुझे वेब पर इनका कोई उत्तर नहीं मिला:

• यह सिर्फ समय के संकलन से कैसे संबंधित है?
• जब वे चलाए जा रहे हैं, तो एक * nix सिस्टम पर लॉगिन को हैंडल करने वाले प्रोग्राम की तरह कार्य होते हैं?
• क्या यह अभी भी एक वैध खतरा है, या 1984 से संकलन की सुरक्षा में ऐसे विकास हुए हैं जो इसे एक महत्वपूर्ण मुद्दा बनने से रोकते हैं?
• क्या यह सभी भाषाओं को प्रभावित करता है?

मैं क्यों जानना चाहता हूं?

मैं कुछ होमवर्क करते समय इस पर आया था, और यह दिलचस्प लग रहा था, लेकिन मुझे पृष्ठभूमि को समझने की कमी है कि क्या यह एक मौजूदा मुद्दा है, या एक हल किया गया मुद्दा है।

संदर्भ सामग्री

• अवलोकन
• कुछ कोड

Comments

विविध डबल कंपाइलिंग रणनीति एक RoTT धांधली संकलक की उपस्थिति का पता लगाने का एक उचित विश्वसनीय तरीका है।

— dmckee

मुझे लगता है कि एनएसए ने इस तरह के हमले में बहुत काम किया है।

— पॉल एम

इसका उल्लेख रेडिट पर किया गया है । 2009 में, डेल्फी की स्थापना के लिए एक वायरस था और किसी भी नए निष्पादन योग्य में खुद को संकलित किया । हाल ही में, इसे पायरेटेड Xcode में वितरित एक मैलवेयर की खोज की गई है जो खुद को iOS ऐप में संकलित करता है ।

— डेनिल्सन सिया मिया

Answer 1

इस हैक को संदर्भ में समझना होगा। यह एक समय में और एक ऐसी संस्कृति में प्रकाशित हुआ था, जहाँ यूनिक्स सभी प्रकार के विभिन्न हार्डवेयरों पर चल रहा था।

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

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

Comments

या, चूंकि अधिकांश लोग स्रोत से कुछ भी संकलित नहीं करते हैं (कहते हैं, विंडोज पर) आपका औसत ट्रोजन पर्याप्त होगा :) (मैं सहमत हूं कि एक समझौता संकलक रास्ता खत्म हो गया है)

— एंड्रेस एफ।

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

— बरबाद

डेस्कटॉप को छोड़कर, यूनिक्स और इसके सभी प्रकार, अभी भी प्रमुख ऑपरेटिंग सिस्टम हैं।

— रॉब

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

— orithena

कल्पना कीजिए कि कोई व्यक्ति ubuntu बिल्ड सर्वर से समझौता करता है और किसी स्रोत को बदले बिना कंपाइलर को बदल देता है। यह पता लगाने में थोड़ा समय लग सकता है, और उस समय तक ऑबंटू छवियों को सभी लोगों के साथ समझौता किए गए कंपाइलर (उनमें समझौता लॉगिन विधानसभाओं या आपके पास क्या है) के साथ बाहर धकेल दिया जाएगा। मुझे लगता है कि यह अभी भी पूरी तरह से वैध चिंता है।

— जिमी होफा

Answer 2

उस भाषण का उद्देश्य एक भेद्यता को उजागर करना नहीं था जिसे संबोधित करने की आवश्यकता है, या यहां तक ​​कि एक सैद्धांतिक भेद्यता का प्रस्ताव करने के लिए जिसे हमें जानने की आवश्यकता है।

उद्देश्य यह था कि जब सुरक्षा की बात आती है, तो हम किसी पर भी भरोसा नहीं करना चाहेंगे, लेकिन दुर्भाग्य से यह असंभव है। आपको हमेशा किसी पर भरोसा करना होगा (इसलिए शीर्षक: "ट्रस्टिंग ट्रस्ट पर भरोसा")

---

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

आप किसी पर भरोसा करने के साथ बस नहीं निकल सकते । यही वह बिंदु है जो वह पार पाने की कोशिश कर रहा था।

Comments

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

— सुपरकैट

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

— ब्लूराजा - डैनी पफ्लुगुफ्ट

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

— अंकित सोनी

@AnkitSoni: मेरा जवाब और अधिक विस्तार में चला जाता है। अलग-अलग संकलक के माध्यम से एक उपयुक्त-लिखित ओपन-सोर्स कंपाइलर / लिंकर को खिलाने से अलग-अलग निष्पादन योग्य परिणाम प्राप्त होने चाहिए जो पहचान योग्य व्यवहार करेंगे । यदि निष्पादन योग्य वास्तव में पहचान का व्यवहार करते हैं, तो वे उसी आउटपुट का उत्पादन करेंगे यदि ओपन-सोर्स कंपाइलर / लिंकर के लिए कोड उनके माध्यम से पारित किया जाता है। फ़ाइलों की तुलना करने के लिए, कोई उन्हें फ़्लॉपी डिस्क पर कॉपी कर सकता है और उनकी तुलना करने के लिए एक प्राचीन कंप्यूटर का उपयोग कर सकता है।

— सुपरकैट

क्या इस बातचीत में से कुछ का मतलब यह नहीं होगा कि आपके द्वारा परीक्षण की गई चीजों के लिए, बायनेरिज़ / हार्डवेयर ने अपेक्षा के अनुरूप व्यवहार किया है? इसमें अभी भी कुछ ऐसा हो सकता है जिसके लिए आपने परीक्षण नहीं किया है और इससे अनजान हैं।

— बार्ट सिल्वरस्ट्रिम 16

Answer 3

नहीं

जैसा कि मूल रूप से वर्णित है, हमला कभी भी खतरा नहीं था। जबकि एक संकलक सैद्धांतिक रूप से ऐसा कर सकता है, वास्तव में हमले को दूर करने के लिए संकलक को प्रोग्रामिंग की आवश्यकता होगी

• पहचानें जब स्रोत कोड संकलित किया जा रहा है एक संकलक का है, और
• इसमें हैक डालने के लिए मनमाने स्रोत कोड को संशोधित करने का तरीका जानें।

यह पता लगाता है कि संकलक अपने स्रोत कोड से कैसे काम करता है, ताकि वह बिना टूट-फूट के इसे संशोधित कर सके।

उदाहरण के लिए, कल्पना करें कि लिंकिंग प्रारूप डेटा लंबाई या संकलित मशीन कोड की ऑफसेट को निष्पादन योग्य में कहीं संग्रहीत करता है। कंपाइलर को अपने लिए यह पता लगाना होगा कि इनमें से कौन सा अपडेट किया जाना है, और कहां, शोषण पेलोड डालते समय। संकलक के बाद के संस्करण (अहानिकर संस्करण) मनमाने ढंग से इस प्रारूप को बदल सकते हैं, इसलिए शोषण कोड को प्रभावी ढंग से इन अवधारणाओं को समझने की आवश्यकता होगी।

यह उच्च-स्तरीय स्व-निर्देशित प्रोग्रामिंग है, एक कठिन एआई समस्या (पिछली बार मैंने जांच की थी, कला की स्थिति कोड उत्पन्न कर रही थी जो व्यावहारिक रूप से इसके प्रकारों द्वारा निर्धारित होती है)। देखो: कुछ मनुष्य भी ऐसा कर सकते हैं; आपको प्रोग्रामिंग भाषा सीखनी होगी और पहले कोड-बेस को समझना होगा।

यहां तक ​​कि अगर एआई समस्या हल हो जाती है, तो लोग अपने छोटे संकलक के परिणाम को बाइनरी में संकलित करने के साथ-साथ एक विशाल एआई लाइब्रेरी से जुड़े होने पर नोटिस करेंगे।

अनुरूप हमला: बूटस्ट्रैपिंग ट्रस्ट

हालांकि, हमले का एक सामान्यीकरण प्रासंगिक है। मूल मुद्दा यह है कि आपके भरोसे की श्रृंखला कहीं से शुरू होनी है, और कई डोमेन में इसका मूल हार्ड-टू-डिटेक्ट तरीके से पूरी श्रृंखला को हटा सकता है।

एक उदाहरण जो आसानी से वास्तविक जीवन में खींच लिया जा सकता है

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

आपको साइनिंग कुंजी कहां से मिली? जब आपने पहली बार ऑपरेटिंग सिस्टम वितरण को डाउनलोड किया था।

आपको यह विश्वास करना होगा कि आपकी श्रृंखला का ट्रस्ट का स्रोत, यह हस्ताक्षर करने वाली कुंजी, बुराई नहीं है।

कोई भी जो आपके और उबंटू डाउनलोड सर्वर के बीच इंटरनेट कनेक्शन को MITM कर सकता है - यह आपका ISP हो सकता है, एक सरकार जो इंटरनेट एक्सेस को नियंत्रित करती है (जैसे चीन), या उबंटू के होस्टिंग प्रदाता- इस प्रक्रिया को हाईजैक कर सकते हैं:

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

थेंसफोर्थ, आपको अपने अपडेट्स को हमलावर के सर्वर से सुरक्षित रूप से मिल जाएगा। अपडेट रूट के रूप में चलते हैं, इसलिए हमलावर का पूर्ण नियंत्रण होता है।

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

Comments

यह गलत है। कंपाइलर को केवल यह निर्धारित करना होता है कि वह अपने स्वयं के स्रोत कोड से बहुत विशिष्ट सामग्री के साथ एक विशिष्ट स्रोत फ़ाइल को संकलित कर रहा है, न कि जब वह किसी भी कंपाइलर को संकलित कर रहा हो, तब !

— काज

@ काज - कुछ बिंदु पर, कंपाइलर या लॉगिन प्रोग्राम के ऊपर के संशोधन उस बिंदु तक पहुंच सकते हैं, जहां वे पिछले दरवाजे के कंपाइलर-पहचानकर्ता / लॉगिन-पहचानकर्ता को पराजित करते हैं, और बाद में पुनरावृत्तियों पिछले दरवाजे को खो देंगे। यह कुछ बीमारियों के लिए प्रतिरक्षा प्रदान करने वाले एक यादृच्छिक जैविक उत्परिवर्तन के अनुरूप है।

— रसेल बोरोगोव

आपके उत्तर के पहले भाग में वह समस्या है जो काज़ वर्णन करता है, लेकिन दूसरी छमाही इतनी अच्छी है कि मैं वैसे भी + 1'ing हूँ!

— बरखा

एक बुराई संकलक जो केवल यह पहचानता है कि यह बहुत ही स्रोत है, निर्माण करना आसान है, लेकिन व्यवहार में अपेक्षाकृत बेकार है - कुछ लोग जिनके पास पहले से ही इस संकलक का एक द्विआधारी है, वे इसे द्विआधारी को पुनः बनाने के लिए उपयोग करेंगे। हमले को एक लंबी अवधि के लिए सफल होने के लिए, संकलक को अपने स्वयं के स्रोत के नए फैसले को पैच करने के लिए अधिक बुद्धि की आवश्यकता होगी, इस प्रकार स्नैसर में वर्णित समस्याओं में चल रहा है।

— user281377

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

— Eamon Nerbonne

Answer 4

सबसे पहले, इस हैक के मेरे पसंदीदा राइटअप को स्ट्रेंज लूप्स कहा जाता है ।

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

बेशक, इसी तरह के हमले आसानी से (या अधिक आसानी से) उनके मालिकों द्वारा जावा, आईओएस एसडीके, विंडोज या किसी अन्य सिस्टम में इंजेक्ट किए जा सकते हैं। कुछ प्रकार की सुरक्षा खामियों को भी हार्डवेयर में इंजीनियर किया जा सकता है (विशेष रूप से यादृच्छिक संख्या पीढ़ी को कमजोर करना)।

(*) लेकिन "निश्चित रूप से" मेरा मतलब है "pricinciple में।" क्या आपको उम्मीद करनी चाहिए कि किसी विशेष प्रणाली में इस तरह का छेद मौजूद है? नहीं, मैं इसे विभिन्न व्यावहारिक कारणों के लिए काफी संभावना नहीं मानूंगा। समय के साथ, जैसे-जैसे कोड बदलता है और बदलता है, इस तरह की हैक के कारण अजीब कीड़े बढ़ जाते हैं। और यह संभावना है कि यह खोज की जाएगी उठाता है। कम सरल बैकसाइड को बनाए रखने के लिए साजिशों की आवश्यकता होगी। निश्चित रूप से हम इस तथ्य के लिए जानते हैं कि विभिन्न दूरसंचार और नेटवर्किंग प्रणालियों में "वैध इंटरसेप्ट" बैकस्ट स्थापित किया गया है, इसलिए कई मामलों में इस तरह की विस्तृत हैक अनावश्यक है। हैक को अधिकता से स्थापित किया गया है।

तो हमेशा, गहराई में रक्षा।

(**) केन के हमले का वास्तव में अस्तित्व है। उन्होंने सिर्फ चर्चा की कि यह कैसे किया जा सकता है। उसने यह नहीं कहा कि वह वास्तव में जहाँ तक मुझे पता है, उसने किया।

Comments

अपने दूसरे फुटनोट के बारे में, केन ने कहा "निर्माण और वितरित नहीं।"

— 8bittree

Answer 5

क्या यह सभी भाषाओं को प्रभावित करता है?

यह हमला मुख्य रूप से उन भाषाओं को प्रभावित करता है जो स्व-होस्टिंग हैं। वह भाषाएं हैं जहां कंपाइलर भाषा में ही लिखा जाता है। C, स्क्वीक स्मॉलटॉक और PyPy Python दुभाषिया इससे प्रभावित होंगे। पर्ल, जावास्क्रिप्ट और सीपीथॉन पायथन दुभाषिया नहीं होगा।

यह सिर्फ समय के संकलन से कैसे संबंधित है?

बहुत ज्यादा नहीं। यह संकलक की स्व-होस्टिंग प्रकृति है जो हैक को छिपाने की अनुमति देती है। मैं किसी भी स्व-होस्टिंग जेआईटी संकलक के बारे में नहीं जानता। (शायद एलएलवीएम?)

जब वे चलाए जा रहे हैं, तो एक * nix सिस्टम पर लॉगिन को हैंडल करने वाले प्रोग्राम की तरह कार्य होते हैं?

आमतौर पर नहीं। लेकिन सवाल यह नहीं है कि यह कब संकलित है, बल्कि किस संकलक द्वारा । यदि लॉगिन कार्यक्रम एक दागी संकलक द्वारा संकलित किया जाता है, तो इसे दागी जाएगा। यदि यह एक स्वच्छ संकलक द्वारा संकलित किया जाता है, तो यह साफ होगा।

क्या यह अभी भी एक वैध खतरा है, या 1984 से संकलन की सुरक्षा में ऐसे विकास हुए हैं जो इसे एक महत्वपूर्ण मुद्दा बनने से रोकते हैं?

यह अभी भी एक सैद्धांतिक खतरा है, लेकिन बहुत संभावना नहीं है।

एक बात आप इसे कम करने के लिए कर सकते हैं यह कई संकलक का उपयोग करना है। उदाहरण के लिए, एक LLVM कंपाइलर, जो स्वयं GCC द्वारा संकलित है, एक पिछले दरवाजे से नहीं गुजरेगा। इसी तरह, एलएलवीएम द्वारा संकलित एक जीसीसी पिछले दरवाजे से नहीं गुजरेगा। इसलिए, यदि आप इस प्रकार के हमले से चिंतित हैं, तो आप अपने संकलक को दूसरी नस्ल के संकलक के साथ संकलित कर सकते हैं। इसका मतलब है कि दुष्ट हैकर (आपके ओएस विक्रेता पर?) को एक दूसरे को पहचानने के लिए दोनों कंपाइलरों को दागना होगा; एक बहुत अधिक कठिन समस्या।

Comments

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

— स्टीवन बर्नैप

निष्पक्ष बिंदु। सब के बाद, हैक लॉगिन के लिए एक पिछले दरवाजे के साथ किया जाता है, और कंपाइलर के लिए एक मॉड, इसलिए यह एक अन्य बॉयलर के लिए भी मॉड ले सकता है। लेकिन इसकी संभावना न के बराबर हो जाती है।

— सीन मैकमिलन

बस समय संकलन में एक इलाज हो सकता है। यदि किसी कोड में कुछ भेद्यता है, जब एक विशेष टुकड़ा JITcompiled है तो यह किसी का ध्यान नहीं जा सकता है। (सिर्फ शुद्ध थॉयरी)

— GameDeveloper

Answer 6

ऐसा होने के लिए एक सैद्धांतिक मौका है। हालांकि, डेविड ए। व्हीलर की डाइवर्स डबल-संकलन के माध्यम से एक विशिष्ट संकलक (उपलब्ध स्रोत कोड के साथ) की जाँच करने का एक तरीका है ।

मूल रूप से, संदिग्ध संकलक के स्रोत को संकलित करने के लिए दोनों संदिग्ध संकलक और एक अन्य स्वतंत्र रूप से विकसित संकलक का उपयोग करें। यह आपको SC _sc और SC _{T देता है} । अब, इन दोनों बायनेरिज़ का उपयोग करके संदिग्ध स्रोत को संकलित करें। यदि परिणामी बायनेरिज़ समान हैं (विभिन्न प्रकार की चीजों के अपवाद के साथ जो वैध रूप से भिन्न हो सकते हैं, मिश्रित टाइमस्टैम्प की तरह), संदिग्ध संकलक वास्तव में विश्वास का दुरुपयोग नहीं कर रहा था।

Comments

या तो वह या विश्वसनीय संकलक उतना विश्वसनीय नहीं है जितना कि उपयोगकर्ता ने सोचा था। लेकिन एक भाषा के दो स्वतंत्र कार्यान्वयन के लिए, उनके पास एक ही पिछले दरवाजे होने की संभावना नगण्य है।

— डेमियन यरिक

या उनकी तुलना करने के लिए आपके द्वारा उपयोग किए जा रहे अलग-अलग उपकरण से भी समझौता किया गया था;)

— iCodeSometime

@kennycoc, हालांकि, "ये दो फाइलें समान हैं" तुलना उपकरण नहीं है, सभी चीजों पर विचार किया जाता है, यह मुश्किल है (जैसा कि, एक syscall संदर्भ दिया गया है, बाइनरी मशीन कोड में 2-16 घंटे में यह संभव होना चाहिए)।

— वैटाइन

Answer 7

एक विशिष्ट हमले के रूप में, यह कभी भी एक खतरे के रूप में है, जो कभी भी बहुत ज्यादा खतरा नहीं है।

यह सिर्फ समय के संकलन से कैसे संबंधित है?

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

जब वे चलाए जा रहे हैं, तो एक * nix सिस्टम पर लॉगिन को हैंडल करने वाले प्रोग्राम की तरह कार्य होते हैं?

यह वास्तव में प्रासंगिक नहीं है।

क्या यह अभी भी एक वैध खतरा है, या 1984 से संकलन की सुरक्षा में ऐसे विकास हुए हैं जो इसे एक महत्वपूर्ण मुद्दा बनने से रोकते हैं?

संकलन की कोई वास्तविक सुरक्षा नहीं है, और न ही हो सकती है। यह वास्तव में उनकी बात का बिंदु था, कि किसी बिंदु पर आपको किसी पर भरोसा करना होगा।

क्या यह सभी भाषाओं को प्रभावित करता है?

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

Answer 8

डेविड व्हीलर का एक अच्छा लेख है: http://www.dwheeler.com/trusting-trust/

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

Comments

-1, आपके उत्तर का थोक प्रश्न का समाधान करने में विफल रहता है।

Answer 9

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

Comments

आपका उत्तर प्रश्न की सतह पर खरोंच करता है, लेकिन वास्तव में पता नहीं है कि क्या पूछा जा रहा है।

Answer 10

यदि किसी के पास कंपाइलर / बिल्ड सिस्टम के लिए सोर्स कोड है, जिसका आउटपुट सप्लाई किए गए सोर्स फाइल्स के कंटेंट के अलावा किसी और चीज पर निर्भर नहीं होना चाहिए, और अगर किसी के पास कई अन्य कंपाइलर हैं और जानता है कि वे सभी एक ही कंपाइलर हैक नहीं करते हैं, तो कोई भी कर सकता है। सुनिश्चित करें कि एक निष्पादन योग्य हो जाता है जो स्रोत कोड के अलावा और कुछ पर निर्भर करता है।

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

सौभाग्य से, ऐसा प्रमाण आवश्यक नहीं होगा यदि कोई केवल एक ही उद्देश्य के लिए परिणामी निष्पादनों का उपयोग करता है: ग्रूचो सूट को फिर से संकलित करना। यदि कोई जी-हार्पो (जीजी-हार्पो की पैदावार), जी-चिको (जीजी-चिको) और जी-ज़प्पो (जीजी-ज़ेपो) का उपयोग करके ग्रूचो सूट का संकलन करता है, तो सभी तीन फाइलें, जीजी-हार्पो, जीजी-चिको , और GG-Zeppo, सभी बाइट के लिए बाइट समान होना चाहिए। यदि फाइलें मेल खाती हैं, तो इसका मतलब यह है कि उनमें से किसी में भी मौजूद "कंपाइलर वायरस" उन सभी में समान रूप से मौजूद होना चाहिए (क्योंकि सभी तीन फाइलें बाइट-फॉर-बाइट समान हैं, कोई भी तरीका नहीं है कि उनका व्यवहार किसी भी तरह से अलग हो सकता है। मार्ग)।

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

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

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

Comments

-1। मैं यह नहीं देखता कि आपका उत्तर प्रश्न के मुख्य पहलुओं को कैसे संबोधित करता है।

@ GlenH7: कई पुराने संकलन उपकरण बिट-समरूप इनपुट [ TIME जैसी बाहरी चीज़ों को देखते हुए लगातार समान-समान आउटपुट का उत्पादन करेंगे , जिसे "आधिकारिक" संकलन समय की रिपोर्ट करने के लिए ट्विक किया जा सकता है]। इस तरह के औजारों का उपयोग करके, कंपाइलर वायरस से बहुत अच्छी तरह से रक्षा की जा सकती है। तथ्य यह है कि कुछ लोकप्रिय विकास ढांचे "नियतात्मक रूप से" संकलित कोड का कोई तरीका प्रदान नहीं करते हैं, इसका मतलब है कि पुराने साधनों में वायरस के खिलाफ रक्षा कर सकने वाली तकनीकों को नए लोगों के साथ प्रभावी ढंग से उपयोग नहीं किया जा सकता है।

— सुपरकैट

क्या आपने यह कोशिश की है? 1. अपने थीसिस के साथ लीड करें। 2. छोटे पैराग्राफ का उपयोग करें। 3. "कार्यात्मक रूप से समान" (पहले चरण का परिणाम) और "बिट समान" (दूसरे का परिणाम) के बीच अंतर के बारे में अधिक स्पष्ट हो, संभवतः उत्पादित सभी संकलक बायनेरिज़ की सूची और उनके रिश्ते एक-दूसरे के साथ। 4. डेविड ए। व्हीलर का डीडीसी पेपर उद्धृत करें।

— दामियन येरिक