🖐🏼 🛍️ 👲🏽 अस्थिर कीवर्ड और समय हमला करता है 🏯 🚘 🏦

ऐसी घड़ियाँ समय के हमलों के लिए खराब अनुकूल हैं

OpenSSL लाइब्रेरी का एक दिलचस्प काम है जिसका नाम है होनहार नाम CRYPTO_memcmp () । इस पर टिप्पणियां बताती हैं कि साधारण मेम्कंप () में एक घातक दोष है - इसका काम करने का समय न केवल तुलनात्मक ब्लॉकों के आकार पर निर्भर करता है, बल्कि उनकी सामग्री पर भी निर्भर करता है, और इससे हमलावर को तथाकथित समय के हमले को अंजाम देने में मदद मिल सकती है।

कई अन्य परियोजनाओं में समान कार्य हैं - निरंतर समय के लिए एक खोज मेमकैंप कई हजार परिणामों का उत्पादन करता है।

हम CRYPTO_memcmp () फ़ंक्शन का उपयोग करने की आवश्यकता पर सवाल नहीं उठाएंगे , बल्कि इस पर विचार करेंगे कि क्या यह इसके लिए किए गए कार्य को हल करता है।

सबसे पहले, मेमॉम्प () के "सामान्य" और "सुरक्षित" कार्यान्वयनों की तुलना करें ।

"सामान्य" इस तरह व्यवस्थित है:

int memcmp( const void* f, const void* s, size_t length ) { const unsigned char* first = f; const unsigned char* second = s; while( length != 0 ) { if( *first > *second ) return 2; if( *first < *second ) return -5; length--; first++; second++; } return 0; }

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

तुलना के लिए, यहाँ CRYPTO_memcmp () कैसे काम करता है :

 int CRYPTO_memcmp( const void* f, const void* s, size_t length ) { size_t i; const unsigned char* first = f; const unsigned char* second = s; unsigned char magic = 0; for( i = 0; i < length; i++ ) { magic |= (first[i] ^ second[i]); } return magic; }

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

दूसरा अंतर यह है कि पूरे डेटा ब्लॉक से गुजरने के बाद लूप से बाहर निकलने का कोई रास्ता नहीं है। इस अंतर के लिए, फ़ंक्शन किया जाता है।

ALAS।

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

अब फिर से CRYPTO_memcmp () के कार्यान्वयन को देखें । वहीं, स्टैंडर्ड C99 को देखें। इसमें C ++ 03 मानक के 1.9 / 6 में "देखे गए व्यवहार" की ऐसी परिभाषा नहीं है, लेकिन 5.1.2.3/3 में यह कहा गया है कि संकलक उस कोड को हटा सकता है जिससे "आवश्यक दुष्प्रभाव" नहीं होते हैं। इसके अलावा, 5.1.2.3/6 में, न्यूनतम आवश्यकताओं को सूचीबद्ध किया गया है, जिसमें "उत्तराधिकार के बिंदुओं पर अस्थिर वस्तुओं की स्थिरता की आवश्यकताएं शामिल हैं, इस अर्थ में कि उत्तराधिकार के बिंदु पर पिछले एक्सेस ऑपरेशन पूरे हो गए हैं और बाद वाले शुरू नहीं हुए हैं"। वास्तव में, यह आवश्यकता सी ++ 03 की 1.9 / 6 की आवश्यकताओं के समान है - उन वस्तुओं तक पहुंच के बारे में कुछ नहीं कहा जाता है, जिनमें एक स्वैच्छिक योग्यता नहीं है।

हम इस अद्भुत चक्र को करीब से देखते हैं:

 /* i variable value not used after the loop */ for( i = 0; i < length; i++ ) { magic |= (first[i] ^ second[i]); }

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

 /* i variable value not used after the loop */ for( i = 0; i < length; i++ ) { magic |= (first[i] ^ second[i]); if( magic == UCHAR_MAX ) break; }

कंपाइलर के पास इस तरह के अनुकूलन के लिए पर्याप्त डेटा है। जाहिर है, ऑपरेशन | = या तो जादू चर के बिट्स को अपरिवर्तित छोड़ सकते हैं, या उन्हें 1 पर रख सकते हैं। यह उन्हें 0 पर नहीं डाल सकता है। एक बार सभी अंक निर्धारित हो जाने के बाद, मैजिक चर के मान में और परिवर्तन संभव नहीं है।

क्या कंपाइलर इस तरह के अनुकूलन का निर्णय ले सकता है? कोड का दूसरा संस्करण उन मामलों में धीमा हो सकता है जहां तुलनात्मक ब्लॉकों में डेटा समान हैं या पहला अंतर शुरुआत से बहुत दूर है। और हम जांचते हैं - हम विजुअल C ++ 9 कंपाइलर के साथ कोड के दोनों संस्करणों को संकलित करते हैं और पहले यह सुनिश्चित कर लेते हैं कि मशीन कोड हमारी अपेक्षा के अनुरूप है।

यह ब्रेक के बिना लूप का मशीन कोड है:

 00AF10D3 mov bl,byte ptr [eax+edi] 00AF10D6 xor bl,byte ptr [eax] 00AF10D8 inc eax 00AF10D9 or dl,bl 00AF10DB sub ebp,1 00AF10DE jne wmain+0D3h (0AF10D3h)

तो - ब्रेक के साथ एक लूप के मामले में:

 00AF1116 mov edx,dword ptr [esp+1Ch] 00AF111A mov dl,byte ptr [eax+edx] 00AF111D xor dl,byte ptr [eax] 00AF111F or bl,dl 00AF1121 cmp bl,0FFh 00AF1124 je wmain+12Ch (0AF112Ch) 00AF1126 inc ecx 00AF1127 inc eax 00AF1128 cmp ecx,esi 00AF112A jl wmain+116h (0AF1116h)

दूसरे मामले में, 6 के बजाय 10 निर्देशों और ईमानदारी से तुलना ( सीएमपी निर्देश) और सशर्त कूद ( सीएमपी अनुदेश के बाद जेई सेमी ) को जोड़ा गया है।

यह प्रतिशत प्रतिशत धीमा होना चाहिए और कोई भी ऐसा नहीं करेगा, है ना?

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

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

कंपाइलर में कोड प्रोफाइलिंग तकनीक (विजुअल C ++ में पीजीओ जैसी कुछ) भी हो सकती है जो आपको टेस्ट पैकेज पर कोड निष्पादित करने की अनुमति देती है और फिर इसे सबसे विशिष्ट परिदृश्यों के लिए अनुकूलित करती है। इस स्थिति में, कंपाइलर के पास वस्तुनिष्ठ डेटा होगा जो मूल्यांकन कर सकता है कि कोड रूपांतरण से कोई लाभ है या नहीं।

हमें यह भी याद है कि इंटेल कोर i5 के लिए कोड ऊपर दिखाया गया है, और इसकी वास्तुकला दुनिया में केवल एक ही नहीं है, किसी अन्य प्रोसेसर पर निर्देश हो सकते हैं, उदाहरण के लिए, संयोजन = = , तुलना और संक्रमण, शून्य ओवरहेड के साथ तुलना में। with | = । इस तरह की वास्तुकला के लिए अच्छी तरह से संकलित एक कंपाइलर निश्चित रूप से इस तरह के एक निर्देश का उपयोग करेगा और दूसरे के रूप में कोड के पहले संस्करण को संकलित करेगा।

ऊपर, कोड का अनुकूलन करने के तीन स्पष्ट तरीके पर विचार किया जाता है, केवल कोड का उपयोग करके।

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

 if( CRYPTO_memcmp( first, second, size ) != 0 ) { /* blahblhablah */ }

और यहाँ यह स्पष्ट है कि एक फ़ंक्शन में एक चक्र इसके बराबर है:

 for( i = 0; i < length; i++ ) { if( first[i] != second[i]) return 3; }

इस ज्ञान के साथ, कंपाइलर के लिए उपरोक्त तीन अनुकूलन को लागू करना बहुत आसान है।

CRYPTO_memcmp () जैसा कोड पोर्टेबल नहीं है। यह विशिष्ट बिल्ड मापदंडों के साथ विशिष्ट संकलक पर अपेक्षित रूप से काम करता है।

हमेशा की तरह, आपको अस्थिर कीवर्ड का उपयोग करने की आवश्यकता है।

एक पूरी तरह से अनुपालन विधि जादुई चर को जादुई चर में जोड़ना है। इस मामले में, कंपाइलर कोड उत्पन्न करने के लिए बाध्य होगा जो लूप के पुनरावृत्तियों की प्रत्येक संख्या पर = = संचालन को सुनिश्चित करता है। कंपाइलर को जादुई चर को स्वचालित मेमोरी में रखने और प्रत्येक पुनरावृत्ति के लिए चर मान के लिए एक अपडेट कोड उत्पन्न करने के लिए मजबूर किया जाता है। इस से Intel Core i5 660 पर, लूप कोड लगभग आधा रह जाता है। बाकी कोड के लिए यह कितना आवश्यक है, यह पूरी तरह से रूपरेखा के बिना नहीं कहा जा सकता है।

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

 int CRYPTO_memcmp( const void* f, const void* s, size_t length ) { size_t i; const volatile unsigned char* first = f; const volatile unsigned char* second = s; unsigned char magic = 0; for( i = 0; i < length; i++ ) { magic |= (first[i] ^ second[i]); } return magic; }

अगर कांस्टेबल अस्थिर हो जाता है तो आप व्यर्थ हो जाते हैं - व्यर्थ। const इंगित करता है कि डेटा आपके कोड से नहीं बदला जा सकता है, और वाष्पशील इंगित करता है कि, सिद्धांत रूप में, वे आपके कोड के बिना बदल सकते हैं, इसलिए रीडिंग को अनुकूलित नहीं किया जा सकता है।

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

इस मामले में अस्थिरता का उपयोग करने से कोड थोड़ा अधिक पोर्टेबल हो जाता है।

दिमित्री मेश्चेरीकोव,

डेवलपर उत्पाद विभाग

अस्थिर कीवर्ड और समय हमला करता है

More articles: