यह लेख दिसंबर 2018 में 2.30 रिलीज के लिए GNU ld में जोड़े गए एक छोटे सुरक्षा फीचर पर ध्यान केंद्रित करेगा। रूसी में, इस सुधार का उल्लेख ओपननेट पर निम्नलिखित एनोटेशन के साथ किया गया था:

"-z अलग-कोड" मोड, जो आकार और स्मृति की खपत में थोड़ी वृद्धि की कीमत पर निष्पादन योग्य फ़ाइलों की सुरक्षा को बढ़ाता है

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

शोषण नियंत्रण प्रवाह मुद्दों

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

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

इस तरह के कारनामों के संचालन के इस आम क्षण को जाना जाता है, और यहां हमलावर के लिए बाधाओं को लंबे समय तक रखा गया है:

1. नियंत्रण से पहले बिंदुओं की अखंडता की जाँच: स्टैक कुकीज़, नियंत्रण प्रवाह गार्ड, सूचक प्रमाणीकरण
2. कोड और डेटा के साथ सेगमेंट एड्रेस का रैंडमाइजेशन: एड्रेस स्पेस लेआउट रैंडमाइजेशन
3. बाहरी कोड खंडों को निष्पादित करने से कोड को रोकें: निष्पादन योग्य स्थान सुरक्षा

अगला, हम बाद के प्रकार की सुरक्षा पर ध्यान केंद्रित करेंगे।

निष्पादन योग्य अंतरिक्ष संरक्षण

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

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

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

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

होल READ_IMPLIES_EXEC

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

लिस्टिंग /proc/$pid/maps :

 00008000-00009000 r-xp 00000000 08:01 10 /var/flash/dmt/nx_test/a.out 00010000-00011000 rwxp 00000000 08:01 10 /var/flash/dmt/nx_test/a.out 00011000-00032000 rwxp 00000000 00:00 0 [heap] 40000000-4001f000 r-xp 00000000 1f:02 429 /lib/ld-linux.so.2 4001f000-40022000 rwxp 00000000 00:00 0 40027000-40028000 r-xp 0001f000 1f:02 429 /lib/ld-linux.so.2 40028000-40029000 rwxp 00020000 1f:02 429 /lib/ld-linux.so.2 4002c000-40172000 r-xp 00000000 1f:02 430 /lib/libc.so.6 40172000-40179000 ---p 00146000 1f:02 430 /lib/libc.so.6 40179000-4017b000 r-xp 00145000 1f:02 430 /lib/libc.so.6 4017b000-4017c000 rwxp 00147000 1f:02 430 /lib/libc.so.6 4017c000-40b80000 rwxp 00000000 00:00 0 be8c2000-be8d7000 rwxp 00000000 00:00 0 [stack] 

यहां आपको परीक्षण उपयोगिता प्रक्रिया का मेमोरी कार्ड दिखाई देता है। एक मानचित्र में स्मृति क्षेत्र होते हैं - तालिका पंक्तियाँ। सबसे पहले, सही कॉलम पर ध्यान दें - यह क्षेत्र की सामग्री (कोड सेगमेंट, फ़ंक्शन लाइब्रेरी या प्रोग्राम का डेटा) या उसके प्रकार (ढेर, स्टैक) की व्याख्या करता है। बाईं ओर, क्रम में, उन पतों की श्रेणी है जो प्रत्येक मेमोरी क्षेत्र में रहते हैं और आगे, अधिकारों के झंडे तक पहुंचते हैं: r (पढ़ें), w (लिखना), x (निष्पादित)। ये झंडे सिस्टम के व्यवहार को निर्धारित करते हैं जब इन पतों पर स्मृति को पढ़ने, लिखने और निष्पादित करने की कोशिश की जाती है। यदि निर्दिष्ट एक्सेस मोड का उल्लंघन किया जाता है, तो एक अपवाद फेंक दिया जाता है।

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

एक आधुनिक डिवाइस पर ऐसी स्थिति क्यों उत्पन्न हुई जो हार्डवेयर के साथ डेटा पेजों पर कोड निष्पादन के निषेध का समर्थन करती है, क्या कॉर्पोरेट और औद्योगिक नेटवर्क की सुरक्षा डिवाइस पर निर्भर करती है, और ध्वनि समस्या और इसका समाधान बहुत लंबे समय से ज्ञात है?

यह चित्र प्रक्रिया के आरंभीकरण के दौरान कर्नेल के व्यवहार से निर्धारित होता है (एक ढेर, ढेर, मुख्य ईएलएफ को लोड करना आदि) और परमाणु प्रक्रिया कॉल के निष्पादन के दौरान। इसे प्रभावित करने वाली प्रमुख विशेषता व्यक्तित्व ध्वज READ_IMPLIES_EXEC । इस ध्वज का प्रभाव यह है कि कोई भी पठनीय मेमोरी भी निष्पादन योग्य हो जाती है। एक ध्वज को कई कारणों से आपकी प्रक्रिया में सेट किया जा सकता है:

1. एलईएफ हेडर में सॉफ़्टवेयर ध्वज द्वारा स्पष्ट रूप से विरासत का अनुरोध किया जा सकता है एक बहुत ही दिलचस्प तंत्र को लागू करने के लिए: स्टैक पर एक स्प्रिंगबोर्ड ( 1 , 2 , 3 )!
2. यह माता-पिता से बाल प्रक्रियाओं द्वारा विरासत में मिला जा सकता है।
3. इसे सभी प्रक्रियाओं के लिए कर्नेल द्वारा स्वतंत्र रूप से स्थापित किया जा सकता है! पहला, अगर आर्किटेक्चर गैर-निष्पादन योग्य मेमोरी का समर्थन नहीं करता है। दूसरे, बस मामले में, कुछ अन्य प्राचीन बैसाखी का समर्थन करने के लिए। यह कोड कर्नेल 2.6.32 (ARM) में है, जिसका जीवनकाल बहुत लंबा था। यह सिर्फ हमारा मामला था।

ELF छवि में गैजेट खोजने के लिए स्थान

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

 $ readelf -l /bin/ls Elf file type is EXEC (Executable file) Entry point 0x804bee9 There are 9 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x08048034 0x08048034 0x00120 0x00120 RE 0x4 INTERP 0x000154 0x08048154 0x08048154 0x00013 0x00013 R 0x1 [Requesting program interpreter: /lib/ld-linux.so.2] LOAD 0x000000 0x08048000 0x08048000 0x1e40c 0x1e40c RE 0x1000 LOAD 0x01ef00 0x08067f00 0x08067f00 0x00444 0x01078 RW 0x1000 DYNAMIC 0x01ef0c 0x08067f0c 0x08067f0c 0x000f0 0x000f0 RW 0x4 NOTE 0x000168 0x08048168 0x08048168 0x00044 0x00044 R 0x4 GNU_EH_FRAME 0x018b74 0x08060b74 0x08060b74 0x00814 0x00814 R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 GNU_RELRO 0x01ef00 0x08067f00 0x08067f00 0x00100 0x00100 R 0x1 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame 03 .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss 04 .dynamic 05 .note.ABI-tag .note.gnu.build-id 06 .eh_frame_hdr 07 08 .init_array .fini_array .jcr .dynamic .got 

यहां आपको ईएलएफ छवि में खंडों की मैपिंग दिखाई देती है।

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

खंड- तालिका की सामग्री के आधार पर ELF लोडर द्वारा एक इन-मेमोरी ELF छवि बनाई जाती है। विभाजन तालिका का उपयोग अब ELF को मेमोरी में लोड करने के लिए नहीं किया जाता है।

एक ईएलएफ खंड में झंडे होते हैं जो यह निर्धारित करते हैं कि खंड की स्मृति में क्या अनुमतियाँ होंगी। परंपरागत रूप से, GNU / Linux के लिए अधिकांश सॉफ्टवेयर इस तरह से बनाए गए थे कि दो PT_LOAD (मेमोरी लोडेड) सेगमेंट को टेबल तालिका में घोषित किया गया था - जैसा कि ऊपर दी गई सूची में है:

1. RE झंडे के साथ खंड

   
   

   1.1। ELF निष्पादन योग्य कोड: सेक्शन .init , .fini , .fini

   
   

   1.2। ELF में अपरिवर्तनीय डेटा: .symtab , .rodata

   
   

2. RW फ्लैग सेगमेंट

   
   

   2.1। ELF में चर डेटा: अनुभाग .got , .bss , .bss , .bss

   
   

यदि आप पहले खंड की संरचना और उसके उपयोग के झंडे पर ध्यान देते हैं, तो यह स्पष्ट हो जाता है कि इस तरह का लेआउट कोड पुन: उपयोग की तकनीकों के लिए गैजेट्स की खोज के लिए जगह का विस्तार करता है। बड़े ELF में जैसे कि libcrypto, सर्विस टेबल और अन्य अपरिवर्तनीय डेटा निष्पादन योग्य सेगमेंट के 40% तक हो सकते हैं। इस डेटा में कोड के टुकड़ों के समान कुछ की उपस्थिति खंड तालिका और प्रतीकों के बिना निष्पादन योग्य सेगमेंट में बड़ी मात्रा में डेटा के साथ ऐसी बाइनरी फ़ाइलों को इकट्ठा करने के प्रयासों से पुष्टि की जाती है। इस एकल निष्पादन योग्य खंड में बाइट्स के प्रत्येक क्रम को मशीन कोड और स्प्रिंगबोर्ड के हमलावर टुकड़े के लिए उपयोगी माना जा सकता है - प्रोग्राम से डिबगिंग संदेश की लाइन का कम से कम टुकड़ा के साथ बाइट्स का यह क्रम हो, प्रतीक तालिका में फ़ंक्शन नाम का हिस्सा या क्रिप्टोग्राफ़िक एल्गोरिथ्म की निरंतर संख्या ...

निर्णय

• ऊपर वर्णित समस्या लंबे समय से ज्ञात है।
• फिक्स्ड 12 जनवरी, 2018 : कुंजी `ld -z अलग-कोड:" ऑब्जेक्ट में अलग कोड "PT_LOAD" सेगमेंट हेडर जोड़ा गया है। यह एक मेमोरी सेगमेंट को निर्दिष्ट करता है जिसमें केवल निर्देश शामिल होने चाहिए और किसी भी अन्य डेटा के लिए पूरी तरह से असम्बद्ध पृष्ठों में होना चाहिए। यदि अलग-अलग कोड "PT_LOAD" खंड नहीं बनाते हैं, तो नाकपर-कोड का उपयोग किया जाता है।))। फीचर को रिलीज़ 2.30 में जारी किया गया था ।
• इसके अलावा, यह सुविधा डिफ़ॉल्ट रूप से अगली रिलीज़ 2.31 में शामिल की गई थी।
• उदाहरण के लिए, उबंटू 18.10 रिपॉजिटरी में, ताजा binutils पैकेज में मौजूद हैं। कई पैकेज पहले से ही इस नई सुविधा के साथ इकट्ठे किए गए हैं, जिसे एल्फमास्टर शोधकर्ता ने सामना किया और दस्तावेज किया

लेआउट एल्गोरिथ्म में परिवर्तन के परिणामस्वरूप, एक नया ईएलएफ चित्र प्राप्त होता है:

 $ readelf -l ls Elf file type is DYN (Shared object file) Entry point 0x41aa There are 11 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x00000034 0x00000034 0x00160 0x00160 R 0x4 INTERP 0x000194 0x00000194 0x00000194 0x00013 0x00013 R 0x1 [Requesting program interpreter: /lib/ld-linux.so.2] LOAD 0x000000 0x00000000 0x00000000 0x01e6c 0x01e6c R 0x1000 LOAD 0x002000 0x00002000 0x00002000 0x14bd8 0x14bd8 RE 0x1000 LOAD 0x017000 0x00017000 0x00017000 0x0bf80 0x0bf80 R 0x1000 LOAD 0x0237f8 0x000247f8 0x000247f8 0x0096c 0x01afc RW 0x1000 DYNAMIC 0x023cec 0x00024cec 0x00024cec 0x00100 0x00100 RW 0x4 NOTE 0x0001a8 0x000001a8 0x000001a8 0x00044 0x00044 R 0x4 GNU_EH_FRAME 0x01c3f8 0x0001c3f8 0x0001c3f8 0x0092c 0x0092c R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 GNU_RELRO 0x0237f8 0x000247f8 0x000247f8 0x00808 0x00808 R 0x1 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt 03 .init .plt .plt.got .text .fini 04 .rodata .eh_frame_hdr .eh_frame 05 .init_array .fini_array .data.rel.ro .dynamic .got .data .bss 06 .dynamic 07 .note.ABI-tag .note.gnu.build-id 08 .eh_frame_hdr 09 10 .init_array .fini_array .data.rel.ro .dynamic .got 

कोड और डेटा के बीच की सीमा अब अधिक सटीक है। एकमात्र निष्पादन योग्य खंड में वास्तव में केवल कोड अनुभाग होते हैं: .init, .plt, .plt.got, .text, .fini

 $ ld --verbose GNU ld (GNU Binutils for Ubuntu) 2.26.1 * * * using internal linker script: ================================================== /* Script for -z combreloc: combine and sort reloc sections */ /* Copyright (C) 2014-2015 Free Software Foundation, Inc. * * * 

 $ diff elf_x86_64.x elf_x86_64.xe 1c1 < /* Default linker script, for normal executables */ --- > /* Script for -z separate-code: generate normal executables with separate code segment */ 46a47 > . = ALIGN(CONSTANT (MAXPAGESIZE)); 70a72,75 > . = ALIGN(CONSTANT (MAXPAGESIZE)); > /* Adjust the address for the rodata segment. We want to adjust up to > the same address within the page on the next page up. */ > . = SEGMENT_START("rodata-segment", ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1))); 

निष्कर्ष

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