Design: اشرح الأمن

أهلا!

لدي سؤال: هل من المنطقي توضيح ما يلي في هذا السياق:

"بخلاف ذلك ، يمكن تجميع البرامج التي تستدعي سلوكًا غير محدد على مستوى اللغة المصدر في برامج WebAssembly التي تقوم بأي شيء آخر ، بما في ذلك إتلاف محتويات كومة التطبيقات أو استدعاء واجهات برمجة التطبيقات باستخدام معلمات عشوائية أو التعليق أو الملاءمة أو استهلاك كميات عشوائية من الموارد (ضمن الحدود) ".
https://github.com/WebAssembly/design/blob/master/CAndC++.md#undefined-and-implementation-defined-behavior

ما أفكر فيه هو توفير سياق / مراجع قد تكون (ربما) مفيدة لمطوري الويب القادمين من خلفيات غير أصلية - من خلال تقديم أمثلة ومزيد من المناقشة.

على سبيل المثال ، CERT's MSC14-C. MSC15-CPP. سلوكية غير محددة لمجمعات الثغرات الأمنية قد تتجاهل بصمت بعض عمليات التحقق الشاملة ، والتي قد تكون جديرة بالملاحظة بشكل خاص في هذا السياق (يناقش روبرت سيكورد هذا بمزيد من التفصيل في " الحذف

المزيد من العلاجات المتعمقة:

• ما يجب على كل مبرمج سي معرفته عن السلوك غير المحدد # 1/3
• ما يجب على كل مبرمج سي معرفته عن السلوك غير المحدد # 2/3
• ما يجب أن يعرفه كل مبرمج سي عن السلوك غير المحدد # 3/3
• دليل للسلوك غير المحدد في C و C ++ ، الجزء 1
• دليل للسلوك غير المحدد في C و C ++ ، الجزء 2
• دليل للسلوك غير المحدد في C و C ++ ، الجزء 3

نصائح أخرى يحتمل أن تكون ذات صلة:

• INT02-CPP.
• INT08-CPP.
• INT10-CPP.
• INT18-C.
• INT32-ج.

هل سيساعد وجود رأس CSP فريد للتحكم في ملفات wasm؟ أشعر أن مالكي المواقع قد يرغبون في منع مصادر فرعية من تحميل wasm.

هذا سؤال مثير للاهتمام. بالتأكيد يجب أن نسمح للمواقع بعدم السماح بالتحميل الديناميكي وتقييم WebAssembly في نفس الحالات التي لا تسمح فيها باستخدام eval و Function (قد يسقط هذا فقط من تكامل وحدة ES6 وفحص CSP على Loader مسار

يجدر الإشارة إلى رقم 53 لمناقشة بعض المخاوف الأمنية مع الارتباط الديناميكي.

jfbastien yup يجب أن يكون CORS و SRI متاحين للمطورين حيثما أمكن ذلك.

lukewagner أعتقد أن ذلك يعتمد على مستوى الوصول المنخفض إلى المورد الذي سيمكّن wasm. كما قلت خارج الصندوق ، إنه مجرد JS. ومع ذلك ، يبدو أن الهدف الشامل للنسيم هو أقرب شيء ممكن من الآلات المعدنية ؛ سيكون من الجيد الحصول على توجيه CSP للتحكم العالمي.
بمرور الوقت ، سيكون من الأفضل اتباع نهج أكثر دقة للميزات الأخرى.

الاحتمالات الفورية الأخرى تستخدم أذونات API للوصول إلى مستوى منخفض آخر.

حسنًا ، قريب من المعدن من حيث الأداء. من منظور الأمان والأذونات ووضع الحماية ، لا توجد مناقشة لوجود اختلاف في WebAssembly عن JS.

لم يكن هذا هو الشعور الذي شعرت به من إعلاني ما بعد MVP و Brendan Eichs ولكن حسنًا: +1:

أعتقد أن ما تشير إليه هو أننا اتفقنا على السماح لدلالات ما بعد MVP و WebAssembly بالابتعاد عما يمكن تعبئته بكفاءة في JS. سيكون هذا الاختلاف حول الميزات الحسابية ، وليس أي شيء يتعلق بالأمان / الأذونات. وهذا يعني أنه على الرغم من عدم إمكانية تعبئتها بكفاءة ، إلا أنه يمكن محاكاة الميزات الجديدة بواسطة مترجم WebAssembly المكتوب بلغة JS ( أسلوب Emterpreter ). قد يكون من الجيد إضافة ملاحظة إلى هذا المعنى لربط ما نعنيه بعبارة "تباعد عن JS".

نعم ، سيكون هذا تحسينًا جيدًا للمستند بالتأكيد ، ربما قرأت المستند بسرعة كبيرة ولكن لا يبدو أنه أوضح ذلك.

أعتقد أنه كان أحد محادثات Eichs حول إضافة المزيد من ميزات خيوط الذاكرة والذاكرة التي جعلتني أعتقد أن wasm سيحصل على ميزات جديدة. أظن أنه من المحتمل أن تتم إضافتها إلى JavaScript أيضًا وأن تخضع للتدقيق المعتاد للميزات الجديدة.

"لا يختلف عن POV للأمان عن JS" الآن في Web.md.

أفضل شرح التمييز بشكل أفضل. الإشارة إلى JS ليست لطيفة جدًا من منظور قائم بذاته ، وأعتقد أننا نريد بالفعل تقليل مساحة سطح الأمان التي يمتلكها JS (على سبيل المثال ، البرامج النصية ذات الأصل المتقاطع وما شابه).

سأصل إلى هذا ، الآن بعد أن تحدثت عنه في CppCon :-)

بالنسبة لأولئك الذين قد يكونون مهتمين باستخدام WebAssembly كهدف لعمليات التشفير ، سيكون من المفيد توضيح الاختلافات بين JS / asm.js JIT و WebAssembly JIT من حيث دعم عمليات التنفيذ في الوقت المحدد. أفكر على وجه التحديد في عمليات مثل عمليات النقل الصغيرة ، أو الفروع المقدمة بعد JIT ، أو القفزات أو عمليات البحث الشرطية ، أو التغييرات الأخرى التي قد يقوم بها JIT والتي قد تؤدي إلى تسرب التوقيت.

إذا لم يكن لدى المطورين توقعات بشأن WebAssembly لدعم عمليات التنفيذ ذات الوقت الثابت بشكل أفضل مما لدينا بالفعل مع asm.js ، فإن ذكر ذلك سيكون مفيدًا كجزء من توضيح الآثار الأمنية لـ WebAssembly لتصميم التطبيق. إذا كان WebAssembly سيوفر بعض الوسائل لتحسين تطبيقات التقوية مقارنة بما هو موجود حاليًا (الآن أو بعد MVP ، لم أقرأ المواصفات بعمق) ، فسيكون من الرائع توضيح ذلك أيضًا. يحتوي https://github.com/jedisct1/libsodium.js/issues/24#issuecomment -128002942 على المزيد حول المشكلات الحالية المتعلقة بتشفير JavaScript من جانب العميل.

بالمناسبة ، هذا كله مثير للغاية. :د

وافق على أنه يجب أن يكون لدينا بيان توضيحي كما اقترحهdconnolly. اعتبارًا من الآن ، كانت المناقشات التي أجريناها هي أنه بالنسبة إلى MVP ، لن تكون هناك ضمانات بشأن ما يمكن أو لا يمكن لـ JIT القيام به ، وأن خوارزميات الوقت الثابت ليست الاستخدام الصحيح لـ MVP على الأقل. هذا قد يتغير في المستقبل.

رأيي الحالي هو أن واجهات برمجة التطبيقات الخارجية (على النحو الذي يقدمه برنامج التضمين مثل منصة الويب) هي في وضع أفضل لتقديم مثل هذه الضمانات لأنك غالبًا ما تحتاج إلى تجميع وفهم جيد للهندسة المعمارية الدقيقة لكتابة كود مناسب ثابت الوقت. ضع في اعتبارك المثال المتطرف لوحدة المعالجة المركزية التي تقوم بترجمة ثنائية ديناميكية: لا يمكن لـ WebAssembly ما يمكن أو لا تستطيع وحدة المعالجة المركزية القيام به. وجهة نظري هي أن WebAssembly في مستوى عالٍ جدًا من التجريد للتعبير عن رمز الوقت الثابت الحقيقي.

رائع ، شكرا لك على التوضيح. متفقًا على أن واجهات برمجة التطبيقات لمنصة الويب هي أفضل مكان لهذا النوع من الأشياء ، خاصةً الأساسيات ( للإضافات المستقبلية مثل المنحنيات البيضاوية الجديدة عبر الملاحظات ). بالتطلع إلى تلك اللغة الإضافية المتعلقة بالأمان ، ستساعد أي شخص آخر قد يسيء تفسير الآثار المترتبة على WebAssembly. : +1:

jfbastien ، هل كل ما قلته عن ضمانات توقيت wasm لا يزال ساريًا حتى اليوم؟

أرى في المستندات الحالية أن التنفيذ الحتمي هو هدف باستثناء قائمة صغيرة من حالات الحافة الموثقة ، والتي قد تبدو إيجابية لخوارزميات الوقت الثابت. ومع ذلك ، يقر موقع webassembly.org/docs/security بأن هجمات التوقيت ممكنة ويسرد بعض عمليات التخفيف المحتملة في المستقبل ، ولكن ليس من الواضح ما إذا كان المقصود الضمني هو أن "رمز C للعربة لن يتم إصلاحه بطريقة سحرية ... حتى الآن "أو" ثغرات القناة الجانبية قد يتم تقديمها والتي لن تحدث مع مترجم سي نموذجي ".

وبغض النظر عن الضمانات الصعبة ، سيكون من المفيد على الأقل التعرف على المكان الذي نقف فيه بين "خوارزميات الوقت الثابت ستفشل بالتأكيد بنسبة 100٪" و "لا يوجد سبب واضح لعدم توقع خصائص التوقيت المماثلة دائمًا لمخرجات clang الثنائية الأصلية". بالنسبة إلى dconnolly ، فإن بعض اللغات التي تقارن هذا على وجه التحديد مع asm.js ستكون مفيدة حقًا أيضًا - لا سيما مع الأخذ في الاعتبار كل من التطبيقات مثل Firefox التي تحترم تمامًا عبارات 'use asm' وتلك التي تشبه Chrome التي تشغلها بشكل أكثر مرونة .

@ buu700 النتيجة الحتمية لجميع أكواد التشغيل لا تعني أن التوقيت مضمون لأي كود تشغيل. لا تضمن Clang التنفيذ في الوقت الثابت أيضًا ، والوقت الثابت ليس كل ما تحتاجه إذا كنت تكتب رمزًا حساسًا للتسرب.

في الوقت الحالي ، لا يبذل WebAssembly أي محاولة لضمان أي شيء فيما يتعلق بالتعريفات.

حسنًا ، شكرًا لتوضيح قسم الحتميةjfbastien.

فيما يتعلق بالتوقيت / القنوات الجانبية (وتجاهل الضمانات أو عدم وجودها) ، يبدو أنه لا يوجد شيء ذي صلة في المواصفات المتعلقة بها في هذا الوقت ولا توجد بيانات مفيدة حتى الآن حول كيفية مقارنة التطبيقات الفعلية بالرنجة؟ ما كنت أتوصل إليه حقًا ، بعد قراءة تعليقك السابق ، هو ما إذا كان هناك سبب ملازم لأن تكون تطبيقات wasm بالضرورة دائمًا _ أسوأ من دول مجلس التعاون الخليجي / clang في هذا المجال. لقد ذكرت مستوى التجريد كمصدر قلق ، لكن لم يكن من الواضح ما الذي كنت تستخدمه كمقارنة أساسية للتوقيت الثابت "الجيد بدرجة كافية" (C الأصلي ، التجميع ، الأجهزة ، إلخ).

بعبارة أخرى ، نظرًا للاختيار بين تشغيل التعليمات البرمجية الحساسة للتسرب على clang والتطبيق الافتراضي الأفضل / الأكثر نضجًا / الأكثر تشددًا من حيث عدم التسرب لمواصفات WebAssembly الحالية ، هل من الواضح أن الأول سيظل مفضلاً بناءً على فهمك؟

في هذه المرحلة من الزمن ، لن أعتمد على clang أو WebAssembly للحصول على تعليمات برمجية حساسة للتسرب. الطريقة الوحيدة التي أعرفها حاليًا للحصول على الضمانات التي أرغب فيها هي كتابة التجميع الذي يقرأ الدليل الخاص بوحدة المعالجة المركزية المحددة التي أستهدفها ، وبالتعاون الوثيق من النواة. إن معرفة "x86" أو "ARM 64" لا يكفي حتى إذا كنت تريد حقًا أن تكون مستقلاً عن التوقيت.

يمكنك الحصول على بعض الضمانات مع بعض المجمعين / اللغات ، ولكن إذا كان هناك تسريب معلومات واحد هو كل ما هو مطلوب للتغلب على الكود الخاص بك ، فإن "بعض" ليست كافية كضمان.

ممتاز ، شكرًا ، أعتقد أن هذا يجيب على سؤالي. وافق على جميع النقاط المتعلقة بنمذجة تهديد التسلل العام ؛ أردت فقط الحصول على فكرة عما إذا كان ينبغي اعتبار الوسم أكثر تسريبًا من أي هدف تجميع C آخر (خالٍ من ASM) ، والذي يبدو كما لو كنت تقول أنه ليس هو الحال بالضرورة؟

لا أعتقد أن "المزيد من التسرب" هو إجراء مفيد. المقياس هو "هل يتسرب على الإطلاق؟" إجابة WebAssembly و clang و C ++ و C هي "نعم".

حسنًا ، على وجه التحديد ، ما كان يدور في ذهني هو الخوارزميات المصممة لتحقيق خصائص مقاومة قناة جانبية معينة بتطبيقات C نقية ، مثل مثال libsodium / NaCl المرتبط بـ dconnolly. من المؤكد أنه مثالي إذا كان هناك شيء ما سينجو من كل سيناريو هجوم محتمل ، ولكن من المفيد أيضًا معرفة الدلتا بين شيئين (حتى لو كان كلاهما سيئًا ، إلى حد ما من الامتصاص) ، وفي هذه الحالة ما إذا كان استخدام WebAssembly بدلاً من Linux ABI مثل من المحتمل أن يكسر الهدف نموذج التهديد المقصود من libsodium.

يعد التعليق المرتبط على مؤشر ترابط مشكلة libsodium مفيدًا للغاية حول كيفية تفاعل المكتبة مع asm.js ، ولكن بصفتي شخصًا غير خبير ، فليس من الواضح بالنسبة لي ما سيبدو عليه هذا التحليل المحدد لإعادة كتابته من أجل WebAssembly (بصرف النظر عن دعم i64 والمتصفحات أكثر اتساقًا في التعامل مع الوسم من asm.js).

لكن على أي حال ، أنا أفهم ما كانت وجهة نظرك الأصلية منذ عام مضى الآن ، وكل ما كنت مهتمًا به حقًا هو ما إذا كنت تدلي ببيان أقوى مما كنت عليه في الواقع (كان من المعروف أن المواصفات تقدم نقاط ضعف جديدة محددة في القناة الجانبية غير موجود في المعيار C / clang ، على عكس ذلك لا يناسب أي منهما بشكل عام لهذا الغرض) ، لذا نشكرك على توضيح ذلك.

>

لا أعتقد أن "المزيد من التسرب" هو إجراء مفيد.

jfbastien ، الأمن الكمي هو مجال معني بالقياس فقط
الذي - التي. المقياس المشترك هو عدد أجزاء المعلومات التي يتم الكشف عنها بواسطة a
هجوم ناجح - 1 بت مقابل 32 بت ، على سبيل المثال ، تحدث فرقًا كبيرًا (وفي
ممارسة كل نظام تقريبًا لديه احتمالية صغيرة للتسريبات من خلال الجانب
القنوات). غالبًا ما يكون هذا التحديد الكمي صعبًا إلى حد ما.

>

لا أعتقد أن "المزيد من التسرب" هو إجراء مفيد.

jfbastien ، الأمن الكمي هو مجال معني بالقياس فقط
الذي - التي. المقياس المشترك هو عدد أجزاء المعلومات التي يتم الكشف عنها بواسطة a
هجوم ناجح - 1 بت مقابل 32 بت ، على سبيل المثال ، تحدث فرقًا كبيرًا (وفي
ممارسة كل نظام تقريبًا لديه احتمالية صغيرة للتسريبات من خلال الجانب
القنوات). غالبًا ما يكون هذا التحديد الكمي صعبًا إلى حد ما.

أنا على علم بذلك ، وأنا غير مهتم تمامًا لأن التسرب هو تسرب. إذا كان الأمر مهمًا للمطورين ، فسوف يعضنا في النهاية (منفذي WebAssembly). لا أعتقد أن WebAssembly يجب أن يحاول معالجة هذه المشكلة في أي وقت قريبًا نظرًا لأولوياتنا الأخرى ، وأن WebCrypto موجود بالفعل كجهد (على الرغم من النقص الذي قد يحدث بخلاف ذلك ، فإن معالجة هذه المشكلة أفضل من مكان WebAssembly في الوقت الحالي ). يمكنك بالطبع استكشاف هذا في وقت فراغك.

jfbastien ، وافق على أن هذا الموضوع ليس له الأولوية في الوقت الحالي ، هذا
Wasm ليس أكثر تسريبًا من C ، وأننا لا نعرف طرقًا جيدة لمعالجته
هو - هي. لكن المبالغة في التبسيط مثل "التسريب هو تسرب" ليست مفيدة في ذلك
يهم - كل نظام يتسرب إلى حد ما ، وبالتالي فإن الكمية هي في الواقع كل شيء
أن المسائل. ومجرد الانتظار حتى "يزعجنا" ليست إستراتيجية
ستلهم الكثير من الثقة بين الضحايا الحقيقيين المحتملين ، وبالتحديد
مستخدمي المتصفح.

وافق على أن ... Wasm ليس أكثر تسريبًا من C

جميل ، شكرا لتأكيد ذلك صراحة! هذا كل ما جئت إلى هنا من أجله: إحساس عام بما يجب أن أقارنه به ، وليس ضمانًا لما إذا كان "لن يتسرب".

@ rossberg-chromium لا أعتقد أنني أتفق مع فكرة أن wasm ليس أكثر تسريبًا من C. في النهاية ، يعتمد ذلك على كيفية تنفيذ كل محرك لكل شيء. على سبيل المثال ، يقوم JavaScriptCore بترتيب التعليمات البرمجية وإيقاف الترميز عند نفاد الذاكرة القابلة للتنفيذ. هذا تسريب غير موجود برمز C. أتوقع ، نظرًا لأن محركات wasm أصبحت أكثر تقدمًا ، فمن المحتمل أن يكون wasm متسربًا مثل شيء مثل JVM. في النهاية ، لا أجد المواصفات أو من المحتمل أن يسعى المنفذون جاهدين لاستيعاب منع تسرب المعلومات ، لا سيما على حساب الأداء.