Design: सुरक्षा की व्याख्या करें

नमस्ते!

मेरा एक प्रश्न है: क्या इस संदर्भ में निम्नलिखित के बारे में विस्तार से बताना उचित होगा:

"इसके अलावा, प्रोग्राम जो स्रोत भाषा के स्तर पर अपरिभाषित व्यवहार का आह्वान करते हैं, उन्हें WebAssembly प्रोग्राम में संकलित किया जा सकता है, जो कुछ और करते हैं, जिसमें एप्लिकेशन हीप की सामग्री को दूषित करना, एपीआई को मनमाने मापदंडों के साथ कॉल करना, हैंग करना, फंसाना या मनमाने ढंग से उपभोग करना शामिल है। संसाधन (सीमा के भीतर)।"
https://github.com/WebAssembly/design/blob/master/CAndC++.md#undefined-and-implementation-defined-behavior

मैं जो सोच रहा हूं वह संदर्भ/संदर्भ प्रदान कर रहा है जो गैर-देशी पृष्ठभूमि से आने वाले वेब डेवलपर्स के लिए (शायद) उपयोग का हो सकता है - उदाहरण और आगे की चर्चा प्रदान करके।

उदाहरण के लिए, CERT का MSC14-C. एमएससी15-सीपीपी। भेद्यता के लिए पर निर्भर न रहें सी कंपाइलर चुपचाप कुछ रैपराउंड चेक को छोड़ सकते हैं , जो इस संदर्भ में विशेष रूप से उल्लेखनीय हो सकते हैं (रॉबर्ट सीकॉर्ड "साइलेंट एलिमिनेशन ऑफ बाउंड चेक्स" में इस पर अधिक विस्तार से चर्चा करते हैं)।

अधिक गहन उपचार:

• प्रत्येक सी प्रोग्रामर को अपरिभाषित व्यवहार के बारे में क्या पता होना चाहिए #1/3
• प्रत्येक सी प्रोग्रामर को अपरिभाषित व्यवहार के बारे में क्या पता होना चाहिए #2/3
• प्रत्येक सी प्रोग्रामर को अपरिभाषित व्यवहार के बारे में क्या पता होना चाहिए #3/3
• सी और सी ++ में अपरिभाषित व्यवहार के लिए एक गाइड, भाग 1
• सी और सी ++ में अपरिभाषित व्यवहार के लिए एक गाइड, भाग 2
• सी और सी ++ में अपरिभाषित व्यवहार के लिए एक गाइड, भाग 3

अन्य संभावित प्रासंगिक सलाह:

• INT02-सीपीपी।
• INT08-सीपीपी।
• INT10-सीपीपी।
• INT18-सी।
• INT32-सी।

क्या wasm फ़ाइलों को नियंत्रित करने के लिए एक अद्वितीय CSP हेडर होने से मदद मिलेगी? मुझे ऐसा लगता है कि साइट के मालिक उप-संसाधनों को wasm लोड करने से रोकना चाहते हैं।

यह एक दिलचस्प सवाल है। निश्चित रूप से हमें साइटों को WebAssembly के गतिशील लोडिंग और मूल्यांकन को अस्वीकार करने की अनुमति देनी चाहिए, उन्हीं मामलों में वे eval और Function अस्वीकार करते हैं (यह सिर्फ ES6 मॉड्यूल एकीकरण और Loader पर CSP जांच से बाहर हो जाएगा)

डायनेमिक लिंकिंग के साथ कुछ सुरक्षा चिंताओं की चर्चा के लिए यह #53 पर इंगित करने योग्य है।

@jfbastien yup CORS और SRI जहां संभव हो वहां डेवलपर्स के लिए उपलब्ध होना चाहिए।

@lukewagner मुझे लगता है कि यह संसाधन के निम्न स्तर की पहुंच पर निर्भर करता है जो कि wasm सक्षम करेगा। जैसा कि आप बॉक्स से बाहर कहते हैं, यह सिर्फ जेएस है। हालांकि ऐसा लगता है कि wasm का व्यापक लक्ष्य मशीनों की धातु की सबसे नज़दीकी चीज है; विश्व स्तर पर नियंत्रण के लिए एक सीएसपी निर्देश एक अच्छा होगा।
समय के साथ अन्य सुविधाओं के लिए अधिक बारीक दृष्टिकोण भी बेहतर होगा।

अन्य तात्कालिक संभावनाएं अन्य निम्न स्तर की पहुंच के लिए अनुमति एपीआई का उपयोग कर रही हैं।

खैर, प्रदर्शन के लिहाज से धातु के करीब। सुरक्षा, अनुमतियों और सैंडबॉक्सिंग के दृष्टिकोण से, WebAssembly के JS से अलग होने की कोई चर्चा नहीं है।

एमवीपी और ब्रेंडन ईच दोनों घोषणाओं के बाद मुझे यह महसूस नहीं हुआ, लेकिन ठीक है: +1:

मुझे लगता है कि आप जिस बात का जिक्र कर रहे हैं, वह यह है कि हम इस बात पर सहमत हुए हैं कि, एमवीपी के बाद, वेबअसेंबली सेमेन्टिक्स को जेएस में कुशलतापूर्वक पॉलीफिल किया जा सकता है। यह विचलन कम्प्यूटेशनल सुविधाओं के आसपास होगा, सुरक्षा/अनुमतियों से कोई लेना-देना नहीं है। इसका मतलब यह है कि, जबकि उन्हें _कुशलतापूर्वक_पॉलीफ़िल नहीं किया जा सकता है, नई सुविधाओं _could_ को JS ( Emterpreter-style ) में लिखे गए WebAssembly दुभाषिया द्वारा सिम्युलेटेड किया जा सकता है। "जेएस से विचलन" से हमारा क्या मतलब है, इसे बाध्य करने के लिए इस आशय के लिए एक नोट जोड़ना शायद अच्छा होगा।

हाँ, यह निश्चित रूप से दस्तावेज़ में एक अच्छी वृद्धि होगी, हो सकता है कि मैंने दस्तावेज़ को बहुत तेज़ी से पढ़ा हो, लेकिन यह स्पष्ट नहीं हुआ।

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

"जेएस से सुरक्षा पीओवी से अलग नहीं" अब Web.md में है ।

मैं इसके बजाय भेद को बेहतर ढंग से समझाऊंगा। जेएस का जिक्र करना एक आत्मनिर्भर परिप्रेक्ष्य से बहुत अच्छा नहीं है, और मुझे लगता है कि हम वास्तव में जेएस के सुरक्षा सतह क्षेत्र को कम करना चाहते हैं (कहें, क्रॉस-ओरिजिनल स्क्रिप्ट और ऐसे)।

मैं इस पर पहुंचूंगा, अब जबकि मैंने इसके बारे में CppCon पर बात कर ली है :-)

उन लोगों के लिए जो क्रिप्टोग्राफिक कार्यान्वयन के लक्ष्य के रूप में WebAssembly का उपयोग करने में रुचि रखते हैं, निश्चित समय के कार्यान्वयन के लिए समर्थन के संदर्भ में JS/asm.js JIT और WebAssembly JIT के बीच के अंतरों पर विस्तार करना उपयोगी होगा। मैं विशेष रूप से बिटशिफ्ट जैसे संचालन के बारे में सोच रहा हूं, पोस्ट-जेआईटी द्वारा शुरू की गई शाखाएं, सशर्त कूद या लुकअप, या अन्य परिवर्तन जो जेआईटी कर सकते हैं जो समय लीक पेश कर सकते हैं।

यदि डेवलपर्स को निश्चित-समय के कार्यान्वयन का बेहतर समर्थन करने के लिए WebAssembly की कोई अपेक्षा नहीं होनी चाहिए, जो हमारे पास पहले से asm.js के साथ है, तो यह बताते हुए कि एप्लिकेशन डिज़ाइन के लिए WebAssembly के सुरक्षा निहितार्थों के बारे में विस्तार से बताने में मददगार होगा। यदि WebAssembly बेहतर सख्त अनुप्रयोगों के कुछ साधन प्रदान करेगा, जो वर्तमान में मौजूद है (अब या MVP के बाद, मैंने कल्पना को गहराई से नहीं पढ़ा है), यह भी विस्तृत करने के लिए बहुत अच्छा होगा। https://github.com/jedisct1/libsodium.js/issues/24#issuecomment -128002942 क्लाइंट-साइड जावास्क्रिप्ट क्रिप्टो के आसपास मौजूदा मुद्दों पर कुछ और है।

वैसे यह सब बहुत रोमांचक है। :डी

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

मेरा वर्तमान लेना यह है कि बाहरी एपीआई (जैसा कि वेब प्लेटफॉर्म जैसे एम्बेडर द्वारा पेश किया जाता है) इस तरह की गारंटी देने के लिए बेहतर स्थिति में हैं क्योंकि आपको उचित निरंतर-समय कोड लिखने के लिए अक्सर माइक्रो-आर्किटेक्चर की असेंबली और अच्छी समझ की आवश्यकता होती है। गतिशील बाइनरी अनुवाद करने वाले CPU के चरम उदाहरण पर विचार करें: WebAssembly गारंटी नहीं दे सकता कि CPU क्या कर सकता है/नहीं कर सकता है। मेरा विचार है कि WebAssembly वास्तविक स्थिर-समय कोड को व्यक्त करने के लिए अमूर्तता के उच्च स्तर पर है।

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

@jfbastien , क्या आपने wasm टाइमिंग गारंटी के बारे में जो कुछ भी कहा है वह आज भी लागू होता है?

मैं वर्तमान दस्तावेज़ों में देखता हूं कि दस्तावेजी किनारे के मामलों की एक छोटी सूची को छोड़कर नियतात्मक निष्पादन एक लक्ष्य है, जो निरंतर समय एल्गोरिदम के लिए संभावित रूप से सकारात्मक लगता है। हालांकि, webassembly । अभी तक" या "साइड चैनल कमजोरियों को पेश किया जा सकता है जो एक विशिष्ट सी कंपाइलर के साथ नहीं होगा"।

एक तरफ हार्ड गारंटी, कम से कम यह समझने में मददगार होगा कि हम "निरंतर समय एल्गोरिदम 100% निश्चित रूप से खराब हो जाएंगे" और "क्लैंग के मूल बाइनरी आउटपुट के बराबर समय की विशेषताओं की अपेक्षा न करने का कोई स्पष्ट कारण नहीं है"। @dconnolly की बात पर, कुछ भाषाएं जो विशेष रूप से asm.js से इसकी तुलना करती हैं, भी वास्तव में उपयोगी होंगी - विशेष रूप से फ़ायरफ़ॉक्स जैसे दोनों कार्यान्वयनों को ध्यान में रखते हुए जो 'use asm' कथनों का पूरी तरह से सम्मान करते हैं और क्रोम जैसे जो इसे थोड़ा कम करते हैं .

@ buu700 सभी ऑपोड के लिए समय की गारंटी है। क्लैंग निरंतर-समय निष्पादन की गारंटी नहीं देता है, और यदि आप इन्फोलीक-संवेदनशील कोड लिख रहे हैं तो आपको निरंतर-समय की आवश्यकता नहीं है।

अभी, WebAssembly इन्फोलीक्स के संबंध में कुछ भी गारंटी देने का कोई प्रयास नहीं करता है।

समझ गया, नियतत्ववाद @jfbastien पर अनुभाग को स्पष्ट करने के लिए धन्यवाद।

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

दूसरे शब्दों में, क्लैंग पर इन्फोलीक-सेंसिटिव कोड चलाने और आज के WebAssembly स्पेक के एक काल्पनिक सर्वोत्तम/सबसे परिपक्व/सबसे इन्फोलीक-कठोर संभावित कार्यान्वयन के बीच विकल्प को देखते हुए, क्या आपकी समझ के आधार पर पूर्व को अभी भी स्पष्ट रूप से पसंद किया जाएगा?

इस समय, मैं कोड के लिए न तो क्लैंग और न ही WebAssembly पर भरोसा करूंगा जो कि इन्फोलीक-सेंसिटिव है। जिस तरह से मैं वर्तमान में जानता हूं कि वास्तव में मैं जो गारंटी चाहता हूं उसे प्राप्त करने का एकमात्र तरीका असेंबली लिखना है जो विशिष्ट सीपीयू के लिए मैनुअल पढ़ रहा है, और कर्नेल से घनिष्ठ सहयोग के साथ। "x86" या "एआरएम 64" जानना पर्याप्त नहीं है यदि आप वास्तव में स्वतंत्र समय बनना चाहते हैं।

आप कुछ कंपाइलर्स/भाषाओं के साथ कुछ गारंटी प्राप्त कर सकते हैं, लेकिन यदि आपके कोड को हराने के लिए एक इन्फोलीक की आवश्यकता है तो "कुछ" गारंटी के लिए पर्याप्त नहीं है।

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

मुझे नहीं लगता कि "अधिक टपका हुआ" एक उपयोगी उपाय है। मीट्रिक है "क्या यह बिल्कुल लीक होता है?" WebAssembly, क्लैंग, C++ और C का उत्तर "हां" है।

खैर, विशेष रूप से, जो मेरे मन में था वह शुद्ध सी कार्यान्वयन के साथ कुछ साइड चैनल प्रतिरोध गुणों को प्राप्त करने के लिए डिज़ाइन किया गया एल्गोरिदम था, जैसे कि @dconnolly द्वारा लिंक किए गए libsodium/NaCl का उदाहरण। यह निश्चित रूप से आदर्श है यदि कोई चीज हर संभावित हमले के परिदृश्य से बचेगी, लेकिन यह दो चीजों के बीच डेल्टा को जानने के लिए भी उपयोगी है (भले ही वे दोनों चूसते हैं, चूसने के कुछ उपाय से), और इस मामले में क्या लिनक्स एबीआई के बजाय WebAssembly का उपयोग कर रहे हैं एक लक्ष्य लिबसोडियम के इच्छित खतरे के मॉडल को तोड़ने की संभावना है।

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

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

>

मुझे नहीं लगता कि "अधिक टपका हुआ" एक उपयोगी उपाय है।

@jfbastien , मात्रात्मक सुरक्षा एक ऐसा क्षेत्र है जो सिर्फ मापने से संबंधित है
वह। सामान्य मीट्रिक यह है कि a . द्वारा कितने बिट जानकारी प्रकट की जाती है
सफल हमला - 1 बिट बनाम 32 बिट, कहते हैं, एक बड़ा अंतर बनाता है (और in . में)
अभ्यास लगभग हर प्रणाली में छोटे संभावित रिसाव होते हैं
चैनल)। हालांकि अक्सर ऐसी मात्रा का ठहराव मुश्किल होता है।

>

मुझे नहीं लगता कि "अधिक टपका हुआ" एक उपयोगी उपाय है।

@jfbastien , मात्रात्मक सुरक्षा एक ऐसा क्षेत्र है जो सिर्फ मापने से संबंधित है
वह। सामान्य मीट्रिक यह है कि a . द्वारा कितने बिट जानकारी प्रकट की जाती है
सफल हमला - 1 बिट बनाम 32 बिट, कहते हैं, एक बड़ा अंतर बनाता है (और in . में)
अभ्यास लगभग हर प्रणाली में छोटे संभावित रिसाव होते हैं
चैनल)। हालांकि अक्सर ऐसी मात्रा का ठहराव मुश्किल होता है।

मुझे इसके बारे में पता है, और मुझे इसमें कोई दिलचस्पी नहीं है क्योंकि एक रिसाव एक रिसाव है। यदि यह डेवलपर्स के लिए मायने रखता है तो यह अंततः हमें (WebAssembly कार्यान्वयनकर्ता) काट देगा। मुझे नहीं लगता कि WebAssembly को हमारी अन्य प्राथमिकताओं को देखते हुए किसी भी समय इस समस्या से निपटने का प्रयास करना चाहिए, और यह कि WebCrypto पहले से ही एक प्रयास के रूप में मौजूद है (कमी के बावजूद यह अन्यथा हो सकता है, इस समस्या को इस समय WebAssembly की तुलना में बेहतर है। ) आप निश्चित रूप से अपने अवकाश पर इसका पता लगा सकते हैं।

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

सहमत हैं कि ... Wasm C . से अधिक टपका हुआ नहीं है

अच्छा, स्पष्ट रूप से इसकी पुष्टि करने के लिए धन्यवाद! मैं यहां बस इतना ही आया हूं: इस बात की एक सामान्य समझ कि मुझे इसकी तुलना किससे करनी चाहिए, इस बात की गारंटी नहीं कि यह "लीक नहीं होगा"।

@ रॉसबर्ग-क्रोमियम मुझे नहीं लगता कि मैं इस विचार से सहमत हूँ कि wasm C से अधिक टपका हुआ नहीं है। अंत में यह इस बात पर निर्भर करता है कि प्रत्येक इंजन सब कुछ कैसे लागू करता है। उदाहरण के लिए, JavaScriptCore कोड को टियर करता है और निष्पादन योग्य मेमोरी से बाहर होने पर कोड को टियर करना बंद कर देता है। यह एक लीक है जो सी कोड के साथ मौजूद नहीं है। मैं उम्मीद करता हूं, जैसे-जैसे wasm इंजन अधिक उन्नत होते जाएंगे, wasm JVM की तरह कुछ लीक होने की संभावना होगी। अंतत:, मुझे नहीं लगता कि युक्ति या कार्यान्वयनकर्ता सूचना लीक को रोकने के लिए प्रयास करने की संभावना रखते हैं, विशेष रूप से प्रदर्शन की कीमत पर नहीं।